Isolating RA with VLANs
-
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.
