8

I have windows computers on a network that are un-unexpectedly getting an IPv6 address from tagged VLAN.

I have routers/computers connected to a switch with an untagged vlan (id 1), and a tagged (id 2). For simplicity, lets say this VLAN2 is for VoIP handsets that will see an option to use the tagged vlan as part of a DHCP request.

For some reason Windows computers on this network are picking up a SLAAC address from both the 2001:db8:1051:4001::/64 and 2001:db8:1051:4002::/64 subnets. I expected Windows computers to only pick up addresses from the untagged VLAN/Subnet.

A windows computer with address from the 2001:db8:1051:4002::/64 will not be able to actually use this address for anything. It cannot ping the gateway 2001:db8:1051:4002::1 and a ping from the gateway doesn't work. As far as I can tell it cannot actually use this address in any way.

A wireshark capture from on the Windows system with the filter icmp6 and ip6[40] == 134 will show the route advertisements for both subnets.

A tcpdump capture from that same computer booted to a Linux livecd will show that the 2001:db8:1051:4002::/64 advertisements with the proper vlan id in the Ethernet frame. Linux does not get addresses from both subnets.

The Windows computers are completely clean new installs of Windows 10 1709, and I have seen the behavior on systems with both Realtek, and Broadcom adapters.

Configuration

 +--------------+    +-----------+    +------------------+
 | Linux Router +----+ HP Switch +----+ Windows Computer |
 +--------------+    +-----------+    +------------------+

Linux router interface configuration

3: eth_lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 0c:c4:7a:14:c7:fd brd ff:ff:ff:ff:ff:ff
    inet 10.2.25.1/24 brd 10.2.25.255 scope global eth_lan
       valid_lft forever preferred_lft forever
    inet6 2001:db8:1051:4001::1/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::ec4:7aff:fe14:c7fd/64 scope link
       valid_lft forever preferred_lft forever
5: eth_lan.2@eth_lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 0c:c4:7a:14:c7:fd brd ff:ff:ff:ff:ff:ff
    inet 10.2.26.1/24 brd 10.2.26.255 scope global eth_lan.2
       valid_lft forever preferred_lft forever
    inet6 2001:db8:1051:4002::1/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::ec4:7aff:fe14:c7fd/64 scope link
       valid_lft forever preferred_lft forever

Linux RADVD Config

interface eth_lan
{
    AdvSendAdvert on;
    AdvManagedFlag on;
    AdvOtherConfigFlag on;
    MaxRtrAdvInterval 90;
    MinRtrAdvInterval 30;
    prefix ::/64
    {
    };
};
interface eth_lan.2
{
    AdvSendAdvert on;
    MaxRtrAdvInterval 90;
    MinRtrAdvInterval 30;
    prefix ::/64
    {
    };
    AdvDefaultPreference low;
};

Switch configuration

HP-2530-24G-PoEP# show running-config

Running configuration:

; J9773A Configuration Editor; Created on release #YA.15.14.0007
; Ver #05:18.63.ff.37.27:91
hostname "HP-2530-24G-PoEP"
snmp-server community "public" unrestricted
vlan 1
   name "DEFAULT_VLAN"
   untagged 1-28
   ip address dhcp-bootp
   exit
vlan 2
   name "VLAN2"
   tagged 1-28
   no ip address
   exit

Questions:

Why are Windows systems getting a non-functional IPv6 address from the tagged VLAN? Is there any way to stop this without disabling IPv6 on VLAN 2 or not having that VLAN tagged on ports Windows systems are connected to?


Answers to questions from the comments

Are the Windows machines able to communicate on the network if you assign them static IPv6 address

A computer connected to a port (untagged vlan1, tagged vlan2) will work perfectly fine if given a static address from the VLAN 1 subnet, but will not work on the VLAN2 subnet which is what I would expect to happen.

Have you tried disabling SLAAC on the router and only using DHCPv6?

If I disable SLAAC AdvAutonomous off; and enable a stateful DHCPv6 server computers will only get an address from the untagged VLAN.

What happens if you disable RA's on eth_lan.2?

The client will not get addresses from that VLAN 2 subnet then. Though, I want IPv6 to work on that subnet so RA is pretty much required.

5
  • I'd comment But I don't have 50 rep. Are the Windows machines able to communicate on the network if you assign them static IPv6 address on the desired subnet? Have you tried disabling SLAAC on the router and only using DHCPv6? What happens if you disable RA's on eth_lan.2?
    – McITGuy
    Apr 18, 2018 at 17:43
  • 2
    I would double-check to be sure the minidriver are installed, as natively Windows NDIS don't support VLAN correctly. (Native NDIS strip VLANid for all the incoming traffic)
    – yagmoth555
    Apr 18, 2018 at 18:19
  • Static addresses work perfectly fine. Disabling RA for eth_lan.2 does mean the client doesn't get the invalid addresses, but I want SLAAC to work for un-tagged VLAN2 devices. If I use stateful DHCPv6 things work fine, computers will only get addresses from the correct subnet. So I do have alternatives, but I am mostly interested in solving why computers are seeing this at all.
    – Zoredache
    Apr 18, 2018 at 18:22
  • @yagmoth555 can you tell me more about that, or give me some links about NDIS not supporting VLAN properly? I wasn't aware that NDIS would strip the tags. That may be my 'answer'.
    – Zoredache
    Apr 18, 2018 at 18:25
  • 1
    The info is hard to find :) but I will write an answer with what Wireshark official statement versus NDIS tell, easier to find that one. Will try later on to find more advanced NDIS info.
    – yagmoth555
    Apr 18, 2018 at 18:40

1 Answer 1

4
+50

I would make sure the NIC's driver are fully installed with their minidriver to enable VLAN support in the OS correctly.

Native Windows NDIS don't support correctly VLAN and it just strip the VLANid in worst case.

Quoted from Wireshark;

Windows has no built-in support mechanisms for VLANs. There aren't separate physical and VLAN interfaces you can capture from, unless a specialized driver that adds such support is present.

So whether you see VLAN tags in Wireshark or not will depend on the network adapter you have and on what it and its driver do with VLAN tags.

Most "simple" network adapters (e.g. widely used Realtek RTL 8139) and their drivers will simply pass VLAN tags to the upper layer to handle these. In that case, Wireshark will see VLAN tags and can handle and show them.

Some more sophisticated adapters will handle VLAN tags in the adapter and/or the driver. This includes some Intel adapters and, as far as i know, Broadcom gigabit chipsets (NetXtreme / 57XX based chips). Moreover, it is likely that cards that have specialized drivers will follow this path as well, to prevent interference from the "real" driver.


Update 1
=======

Found a MS Blog reference there; Windows Core Networking talk about 802.1P, but they give some more info on 802.1Q (VLAN tagging)

The Windows networking stack fully supports the 802.1Q tag, i.e. both UserPriority (as Mathias discusses in this post) as well as VlanId. However, no stack component (tcpip, etc.) ever acts on the VlanId field. Vendors, such as Intel, Broadcom, etc., implement VLANs in their miniport drivers in combination with NIC hardware. Thus, Windows enables ISVs to implement VLAN if they wish, but does not natively implement them.

– Gabe

From that other MS blog (that could explain why your Windows computer can't ping the IPv6's gateway (and easy to validate with the wireshark, as the outgooing packet (PC->Gateway) would be unttaged even if it's supposed to be tagged))

Your NIC is responsible for adding the 802.1q tag to the outgoing packet.

With that update in mind, my term "strip the vlan id" was a bit heavy at first, as it don't strip it by default, it get the vlan id as input, but ignore it, and it just don't send the vlan id out after, and leave all that management to the NIC's driver.

5
  • 1
    This is the answer. Windows computers do not support trunks/tagged traffic at the OS level. You need a driver/NIC that supports creating a virtual adapter per-VLAN. Otherwise Windows just mixes all the DHCP/SLAAC/etc. info coming in the interface together regardless of VLAN. Apr 22, 2018 at 15:55
  • 4
    This behavior is asinine. If the Windows networking stack doesn't know how to properly act on the presence of a VLAN tag (because it doesn't natively support VLANs), it should do like it does for any other unrecognized ethertype and drop the frame. Feb 2, 2021 at 20:31
  • This answer explains why it is broken, but makes no mention of actions to take to fix / work around? What parts of Windows do you need to replace? Nov 30, 2022 at 14:17
  • @GrahamLeggett The fix stated in the answer is to use a NIC that allow the VLAN id, thus a third part nic driver that work for your need. If you can’t, it’s sadly a switch config to do to shape the traffic to those computers
    – yagmoth555
    Dec 1, 2022 at 17:17
  • @yagmoth555 Most NICs allow specification of a VLAN id, this breakage is the exact opposite of that - NICs are broken when they do not have or want a VLAN id. On Realtek cards setting the MonitorModeEnabled registry key to 1 works around the problem. Dec 2, 2022 at 13:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .