I have a motherboad with an integrated 82574L and 82579LM NICs and when I use either of these with Hyper-V (Server 2012) and add a VLAN to the VM or VIrtual switch the packets (as shown by wireshark) are having the VLAN ID tagged under an ISL header and NOT an 802.1Q header. Does anyone have any idea how to solve this? It seems to be an Intel driver issue as my cheap PCIe Realtek chipset card works as expected.
Below is a quick description of my network;
Server with Server 2012 running Hyper-V
The 82574L has no VLAN configurations directly under it (default settings) and is using the latest driver direct from Intel (17.4, although device manager shows 126.96.36.199?)
A virtual switch is bound to the 82574L port and is not shared with the host (I have tried sharing with the host and have the same issue)
1 VM running with a VLAN ID of 10 under its settings
1 VM running with a VLAN ID of 20 under its settings
Both VMs connected to a CISCO switched network (I don't think the switch has anything to do with this as it doesn't work if I connect the server directly to another PC)
Should anyone require any further information please do ask and I'll try and provide it (I'm fairly new to networking at the packet level!)
Thanks for the report.
Where are you running Wireshark? Are you watching from a mirrored port on the switch or is it running on the server? You might not see the 802.1q tagging if you are running on the server because of VLAN tagging offload. See http://www.intel.com/support/network/sb/cs-005897.htm http://www.intel.com/support/network/sb/cs-005897.htm.
We will also test the taggine here at Intel. I will let you know what we find.
Thanks for the link, but as it turns out this is what has been causing my issues! Or at least a combination of the that and a layer 8 issue. I have found the NICs work as expected with the VLAN ID tagged in the 802.1Q header, but only when the 'monitorMode' is DISABLED on the sending NIC. If you enable the monitor mode on the sending NIC then they seem to get tagged under the ISL header rather than the 802.1Q header. This can easily be observed by connecting the two ports on the server via a crossover cable and sending out a packet through a VM in hyper-v. I'm not sure if this is intended, but it got me confused for a few days.
I know what people are thinking, why the hell would anyone enable the monitor mode on the sending NIC? Answer, I had been doing some monitoring previously on that port and that setting was still enabled. So the moral of the story is make sure everything is set to default, including settings in the registry, before creating a report.