RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1854416 - virtio-win network driver wrongly discards VLAN tagging info
Summary: virtio-win network driver wrongly discards VLAN tagging info
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: virtio-win
Version: 8.2
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: 8.0
Assignee: Meirav Dean
QA Contact: Yu Wang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-07-07 12:58 UTC by g.danti
Modified: 2021-01-28 14:20 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-01-27 11:50:20 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description g.danti 2020-07-07 12:58:12 UTC 
Description of problem:
When using the virtio-net windows driver (the recommended approach whenever possible), any VLAN-tagged packet arriving at the virtual machine is stripped by its VLAN tagging - effectively delivering the packet to listening connections. It seems that when the "Vlan ID" parameters found in the network device advanced property is 0 (the default value), any packets arriving at the interface is processed and stripped by the VLAN tag. Switching off VLAN processing in "Priority and VLAN tagging" avoid the issue described above, with packets logged with the correct VLAN tag.

Please note that this behavior is only observed on the Windows virtio-net driver: the same virtio-net running on Linux guest correctly reports the packets as tagged, and an e1000 Windows driver correctly discard incoming tagged packets (ie: Wireshark reports nothing).


Version-Release number of selected component (if applicable):
Stable virtio-win Windows network driver (vers. 100.82.104.17800)
qemu-kvm-2.12.0-99.module_el8.2.0+320+13f867d7.x86_64

How reproducible:
Consider a very simple setup with a single KVM host and a "lanbr" bridging together a physical interface and a vnet0 virtual interface, attached to a Windows 10/2016/2019 VM. If, from another machine on the same physical network, a VLAN interface is created (ie: vconfig add eth0 10) and a DHCP requests is done from the tagged interface, the Windows machines see the DHCP requests *without* any tagging information. If running a DHCP on the Windows machine, you can also see the DHCP OFFER for the to-be-leased IP.


Steps to Reproduce:
1. create an untagged host bridge
2. launch a Windows VM on that bridge, installing virtio-net
3. install and launch Wireshark, listening for DHCP packets (udp.port eq 67 or udp.port eq 68)
4. on another physical machine, add a tagged interface (vconfig add eth0 10) and issue a DHCP client request via dhclient -d eth0.10
5. on the Windows VM, you can see that Wireshark logged many packets having no VLAN tag
6. try switching off the VLAN processing, or change interface to an e1000, and retry the DHCP request to see the correct behaviors (ie: dropping or tagging packets)


Actual results:
Windows virtual machines on the untagged bridge can receive tagged packets, seeing them an untagged ones.


Expected results:
Windows virtual machines on the untagged bridge should see tagged packets, discarding them.


Additional info:
Comment 1 Yvugenfi@redhat.com 2020-07-08 08:42:49 UTC 
The striping of the tag is the expected result in Windows:
*PriorityVLANTag (standard Window keyword for NICs) documentation states (https://docs.microsoft.com/en-us/windows-hardware/drivers/network/enumeration-keywords):

> The miniport driver should remove the 802.1Q header from all receive packets regardless of the *PriorityVLANTag setting. If the 802.1Q header is left in a packet, other drivers might not be able to parse the packet correctly.
> If the Rx flag is enabled on the receive path, the miniport driver should copy the removed 802.1Q header into OOB.
> Otherwise, if the Rx flag is disabled, the miniport driver should not copy the removed 802.1Q header into OOB.

Therefore we are removing the tag and setting VLAN ID in the metadata passed to the upper layers.

Also, VLAN ID 0 means pass all packets.

So if you want the driver to receive\send packets for specific VLAN, set VLAN ID in the advanced tab.
Comment 2 g.danti 2020-07-08 10:47:33 UTC 
> The striping of the tag is the expected result in Windows:
> *PriorityVLANTag (standard Window keyword for NICs) documentation states (https://docs.microsoft.com/en-us/windows-hardware/drivers/network/enumeration-keywords):

Well, this is very surprising, thanks for sharing.

If I correctly read it, Microsoft's documentation states that the VLAN ID should be put in a out-of-band data buffer to further processing (including being dropped) from the upper layers; however, the packet is never dropped because a running DHCP server tries to offer an IP address to the rouge client. I am not a Windows driver developer, but this sounds bad: a rouge packet arriving with an unknown VLAN ID should *not* be passed to listening sockets/ports.

It's telling that the Intel e1000 driver (virtualizing a real server-grade adapter) will *not* pass unauthorized tagged packets to user applications.
On the other hand, an e1000e (notice che final 'e'), providing a client-like Intel gigabit adapter, behaves as virtio-net (stripping the VLAN ID).

> Also, VLAN ID 0 means pass all packets.

All *untagged* packets - yes.
All packets (including ones tagged with unknow VLAN) - I am not sure, especially considering that the VLAN tag is stripped and the packet can be received by processes it was never intended for.

> So if you want the driver to receive\send packets for specific VLAN, set VLAN ID in the advanced tab.

Sure, but it needs to be done on each Windows guests, which can be tedious.
Regards.
Comment 3 Yvugenfi@redhat.com 2020-07-09 09:05:05 UTC 
I will take an additional look.


For now, you can script the changes for the guest with PowerShell (set-netadapter):
https://docs.microsoft.com/en-us/powershell/module/netadapter/set-netadapter?view=win10-ps

And driver setting change can be scripted with a tool we supply with the installation: https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/NetKVM/CoInstaller/readme.doc
Comment 5 ybendito 2021-01-26 06:02:09 UTC 
Which Windows version you're using?
Comment 6 ybendito 2021-01-26 06:04:28 UTC 
It looks like there the VLAN is explained better:
http://woshub.com/configure-multiple-vlan-on-windows/
Comment 7 g.danti 2021-01-26 07:04:26 UTC 
(In reply to ybendito from comment #5)
> Which Windows version you're using?

I tried it on both Windows Server 2019 and Windows 10 20.04
Comment 8 ybendito 2021-01-26 09:00:49 UTC 
Then the comment #6 will be useful for Server 2019. According to the link client OS does not have built-in support for VLAN splitting above the miniport.
Comment 9 Yvugenfi@redhat.com 2021-01-27 11:50:20 UTC 
Closing based on comment #6 and comment #8.
Comment 10 g.danti 2021-01-27 15:19:38 UTC 
Sorry, but I fail to understand how comment #6 explains the issue described here (which is thoroughly described in comment #1 and comment #2)
Am I missing something?
Comment 11 Yvugenfi@redhat.com 2021-01-28 09:57:37 UTC 
(In reply to g.danti from comment #10)
> Sorry, but I fail to understand how comment #6 explains the issue described
> here (which is thoroughly described in comment #1 and comment #2)
> Am I missing something?

Hello,

1. In the link provided in comment #6 paragraph "How to Configure Multiple VLANs in Windows Server 2016" you can see that VLAN ID 0 in the configuration is used to receive all packers in order to later redirect them to a specific adapter.

2. Also nowhere in other documentation, it is said that the configuration of VLAN 0 should drop other VLAN tags.
What is say at best is: "The reserved value 0x000 indicates that the frame does not carry a VLAN ID; in this case, the 802.1Q tag specifies only a priority (in PCP and DEI fields) and is referred to as a priority tag.", but this is for the data in the packet."

3. e1000 can hardly be related as a reference, because this is a very old device (not sure if it is even supported on newer Windows versions).

4. Another point - our behavior passes MS WHQL tests that are testing vlan\priority tagging.

Best regards.
Yan.
Comment 12 g.danti 2021-01-28 11:38:58 UTC 
(In reply to Yan Vugenfirer from comment #11) 
> 1. In the link provided in comment #6 paragraph "How to Configure Multiple
> VLANs in Windows Server 2016" you can see that VLAN ID 0 in the
> configuration is used to receive all packers in order to later redirect them
> to a specific adapter.

First, thank you for taking the time to reply.
You are right, I missed how the VLAN tag was specified to on team interface.

> 2. Also nowhere in other documentation, it is said that the configuration of
> VLAN 0 should drop other VLAN tags.
> What is say at best is: "The reserved value 0x000 indicates that the frame
> does not carry a VLAN ID; in this case, the 802.1Q tag specifies only a
> priority (in PCP and DEI fields) and is referred to as a priority tag.", but
> this is for the data in the packet."

Ok, but I find strange (if possible) that the packet is accepted being stripped of the VLAN tag *only*
Both virtio-net on Linux and e1000 on Windows do not drop the packet, but at the same time do not drop the VLAN tag neither. In this manner, no higher-level application can see the packet unless it put the interface in promiscuous mode.

The current virtio-net Windows driver, instead, accept the packet (as I expected) but remove its VLAN tag. This means that other application listening on broadcast (eg: DHCP client) actually see (and consume) the packet. For example, a DHCP client can respond to a DHCP offer of a server whose packets are tagged with another VLAN ID.

Note that I am not saying you are wrong, quite the opposite. But I find this behavior quite confusing.

> 3. e1000 can hardly be related as a reference, because this is a very old
> device (not sure if it is even supported on newer Windows versions).

As far I can see, e1000 is supported and WHQL certified on Windows 2019/2016

> 4. Another point - our behavior passes MS WHQL tests that are testing
> vlan\priority tagging.

True, but the same is for e1000 - which show a different behavior.

Regards.
Comment 13 Yvugenfi@redhat.com 2021-01-28 13:27:30 UTC 
(In reply to g.danti from comment #12)
> (In reply to Yan Vugenfirer from comment #11) 
> > 1. In the link provided in comment #6 paragraph "How to Configure Multiple
> > VLANs in Windows Server 2016" you can see that VLAN ID 0 in the
> > configuration is used to receive all packers in order to later redirect them
> > to a specific adapter.
> 
> First, thank you for taking the time to reply.
> You are right, I missed how the VLAN tag was specified to on team interface.
> 
> > 2. Also nowhere in other documentation, it is said that the configuration of
> > VLAN 0 should drop other VLAN tags.
> > What is say at best is: "The reserved value 0x000 indicates that the frame
> > does not carry a VLAN ID; in this case, the 802.1Q tag specifies only a
> > priority (in PCP and DEI fields) and is referred to as a priority tag.", but
> > this is for the data in the packet."
> 
> Ok, but I find strange (if possible) that the packet is accepted being
> stripped of the VLAN tag *only*
> Both virtio-net on Linux and e1000 on Windows do not drop the packet, but at
> the same time do not drop the VLAN tag neither. In this manner, no
> higher-level application can see the packet unless it put the interface in
> promiscuous mode.

As I mentioned previously, this is from MS documentation: 
"The miniport driver should remove the 802.1Q header from all receive packets regardless of the *PriorityVLANTag setting. If the 802.1Q header is left in a packet, other drivers might not be able to parse the packet correctly."
https://docs.microsoft.com/en-us/windows-hardware/drivers/network/enumeration-keywords

So we don't have a choice but to remove the tag and put it into meta data.

> 
> The current virtio-net Windows driver, instead, accept the packet (as I
> expected) but remove its VLAN tag. This means that other application
> listening on broadcast (eg: DHCP client) actually see (and consume) the
> packet. For example, a DHCP client can respond to a DHCP offer of a server
> whose packets are tagged with another VLAN ID.
> 
> Note that I am not saying you are wrong, quite the opposite. But I find this
> behavior quite confusing.
> 
> > 3. e1000 can hardly be related as a reference, because this is a very old
> > device (not sure if it is even supported on newer Windows versions).
> 
> As far I can see, e1000 is supported and WHQL certified on Windows 2019/2016
> 
> > 4. Another point - our behavior passes MS WHQL tests that are testing
> > vlan\priority tagging.
> 
> True, but the same is for e1000 - which show a different behavior.
> 
> Regards.

Best regards,
Yan.
Comment 14 ybendito 2021-01-28 14:20:02 UTC 
How to Configure Multiple VLANs in Windows Server 2016(In reply to g.danti from comment #10)
> Sorry, but I fail to understand how comment #6 explains the issue described
> here (which is thoroughly described in comment #1 and comment #2)
> Am I missing something?
I suggest to open the http://woshub.com/configure-multiple-vlan-on-windows/
Scroll down to "How to Configure Multiple VLANs in Windows Server 2016" and try follow the recommendation.
Note You need to log in before you can comment on or make changes to this bug.