Isolating RA with VLANs
-
Hello,
sorry for the noop question; but right now I do not seem ton get what is wrong:
Setup -
pfSense; Multiple VLANs; DualStack v4/v6 on some (3) VLANs.Now, I get RA for all prefixes configured on any VLAN interface . too; basically all three /64 prefixes. Basically, I want only one prefix per VLAN, the one from the interface.
Is there a way to stop this from happening?
Thanks!
-
Strange. Using tcdump I realized this was only affecting Windows 7 clients. For some reason they evaluate all RA from other vlans on that link; not only the interface is untagging.
tcdump also showed this is clearly no pfSense-issue.
-
For some reason they evaluate all RA from other vlans on that link
Eh… are you using a managed VLAN-capable switch?
-
Indeed, I do. And also, my network setup is correct.
The rest is off topic. It occurred to be just now and I consider it a major bug in Windows Ethernet stack implementation. However, MS considers it as a design concept. Anyway, anyone working with Windows networks should be aware.
Bottom line: If no VLANs are configured on a given adapter, Windows (I tested Win8.1, Win7, WinXP) removes the tag from any vlan packet it receives and forwards it to the host [1]. What might be resulting in only noise with unicast has major implications with broadcast and multicast. This way, the IPv6 stack 'sees' (mulicast) RA from all tagged vlans on the link and correctly assigns every prefix to a single link. Since outgoing traffic has no way on replying to the correct vlan (there, only the untagged vlan can be used) packets considered on link are in fact off link.
With IPv4, this may, along with other weird things, result in DHCP trouble (address assignments from the wrong DHCP server).
This is only mitigated by the fact that by best practice on any switch port only actually in the host configured vlans should be tagged. However, as you can see in the link below, rolling numerous IP phones can result in a hell of trouble.
[1] https://communities.intel.com/message/157062#157062
-
And also, my network setup is correct.
-1. Relying on Windows to do VLAN tagging is pure madness, not really sure what to say. Use the VLAN-capable switch properly.
-
Use the VLAN-capable switch properly.
What do you think I should have done differently?
-
You already noted that yourself… don't tag ports for VLANs the hosts are not supposed to see at all... I really cannot see how you could ever rely on a random host on a network to do the proper thing with the packets.
we have thousands of Cisco IP phones deployed across the network, such that the Phone is inline with the PC
Yuck.
-
Yuck.
Sorry, not an English native speaker here.
But I assume you do not have any better ideas then I have on the (IMHO) valid IP phone scenario (actually, exactly the issue I am facing… ;) -
Well, have fun. When you are in a situation where someone plugs some box in there and the whole network breaks because the host does not behave as expected - yet it behaves exactly like documented (!!!) - then the problem seems to lie in the network design department to me. (I frankly would never put thousands of VoIP phones on the same wire as the LAN computers.)
-
Endpoint should NEVER see VLAN tag except if you know what are you doing. In your case its very bad network config that is causing your issues and you should really put phones and pc's on different VLAN's…
-
Well, have fun.
I do, indeed! Thankfully, I am facing the issue in a lab and our deployment is not nearly as large.
where someone plugs some box in there and the whole network breaks because the host does not behave as expected
Actually, it does not break. It is at best a cosmetic issue if your routing tables are correct. Also, nothing stops you from from discarding the traffic at the router. I consider it dirty and a potential security issue.
But back on topic and something hopefully helpful.
Configuring an untagged vlan on the interface leads to the expected behavior (at leas, with intel nics). On windows 8+, this can even be done with netsh and is therefore scriptable. Also, I found that disabling "Priority & VLAN" seems to have the same effect (at least with my intel NICs). -
Endpoint should NEVER see VLAN tag except if you know what are you doing. In your case its very bad network config that is causing your issues and you should really put phones and pc's on different VLAN's…
This is exactly what I am doing. Until now, I never had the need to put any non - used vlans on endsystem switch ports. But as a feature and to save cabeling, many IP phones are used that way; thus 'tagging out' the voice vlan while ignoring the untagged frames and forwarding them onwards to the host. To my knowledge this is a pretty standard setup.
Interestingly the phones do the correct thing and do not acquire a prefix from the untagged vlan.
IMHO the Windows IEEE 802.1Q is broken since any other OS, be them phones, MacOS, Linux, do not such a thing. Not that I can do anything about but scripting quirks and smartport macros. And I honestly think MS will stick to the behavior. -
Standard config is:
1 cable with 1 untagged vlan (default vlan for PC`s) on it and one tagged (for phones) and never 2 tagged, so your network knowledge is a bit short.
See this: https://supportforums.cisco.com/discussion/11080716/tagged-and-untagged-same-interface -
Standard config is:
1 cable with 1 untagged vlan (default vlan for PC`s) on it and one tagged (for phones)Sorry if I was unclear, but this is a quote from my last post:
thus 'tagging out' the voice vlan while ignoring the untagged frames and forwarding them onwards to the host.
So:
Untagged / default / native/ primary vlan (whatever you like best) for the windows PC + one voice vlan tagged on the switchport, nothing else.
(Even an untagged vlan has to be a tagged one before entering the switchport untagging it, hence these terms). -
I have this config on Windows and Snom360 phones and it
s working just fine. I dont encounter this "bug" so it must be something on your config or network that is causing it.
Windows has no such bug "IMHO the Windows IEEE 802.1Q is broken" , for me everything works just fine. -
I have this config on Windows and Snom360 phones and it`s working just fine.
Interesting; I suppose this might something the phone is doing, by not forwarding its vlan? Would make some sense to me. But if you like, you can easily confirm the windows behavior by assigning tagged vlans to a Windows endsystem. As I said above, I run this in a lab right now but can confim it on on our production LAN.
Here the quote from the link I provided. apparently from MS NDIS:
If the driver isn't configured for a VLAN, then incoming VLAN tagged traffic is to be converted to untagged.
Also, unable to find the actual MS doc, Louisiana Sate University is facing the same thing; arriving at the same conclusion:
It is important for Microsoft to take a second look at how the NDIS is written and how they treat VLAN tagging.
http://www.educause.edu/discuss/networking-and-emerging-technologies/network-management-constituent-group/ipv6-vlan-tagging-windows
-
More likely it's a driver issue – AFAIK Windows leaves all 802.1q handling to the NIC driver (which may then just filter other VLAN, or expose a virtual interface per configured VLAN, or whatever else it sees fit to do).
-
True, this is a driver issue. But only a symptom - since driver vendors stick to the design described in NDIS (witch is written by Microsoft).
-
Friends don't let friends expose vlan tags to Windows boxes. The only OS I trust to do vlan tagging properly is ESXi.
-
If you are sending a tagged voice VLAN to a phone along with an untagged VLAN intended to be used by the host chained off the phone and the host chained off the phone is seeing both the tagged traffic and the untagged traffic, the phone is either broken or configured incorrectly.
