I know that the native vlan is used for untagged traffic and from what I've googled an example of untagged traffic could be STP or VTP management traffic this makes sense to me but the other kind of traffic could be from a legacy device that does not have VLAN tag capability, but how is that possible? I mean if you have such a device then I guess you will connect it to a switch port and as we know every switch port has a vlan tag, if you don't configure anything then vlan 1 will be used... could you please help me to clarify this? how can we have such untagged traffic?
Solved! Go to Solution.
Thanks for the additional information. In reference to this statement " as we know every switch port has a vlan tag" perhaps we really are facing an issue with semantics more than with function. When you say vlan tag I assume that we are talking about the extra data that is inserted into an Ethernet frame to identify vlan membership. And not every switch port has a vlan tag. If you change the statement to say that every switch port has a vlan ID then I would be in complete agreement with your statement. And the vlan ID is how the switch knows how to forward layer 2 traffic keeping the frame in the correct vlan.
And yes the terminology if not used the same way by different vendors (HP vs Cisco, etc).
You ask an interesting follow up question "but when will we have frames that don't come from a vlan?" I can think of a couple of possible answers:
- if an Ethernet frame came from a router interface (physical interface - not subinterface) then we might say that it did not come from a vlan.
- similarly if an Ethernet frame came from a PC then we might say that it did not come from a vlan.
- some people might say that if an Ethernet frame came from an unmanaged switch it did not come from a vlan. I would not agree with that. From my perspective any switch (managed or unmanaged) implements a vlan. They might not configure the vlan, but a vlan is implemented in the sense that they have created a broadcast domain that controls which ports can communicate with which other ports.
There is no need for apologies. We tend to use terms a bit loosely. And that can generate confusion about how something works. Sometimes that is what a discussion is really about. And sometimes the answer to the question is to be more careful about how we have used terms. As in the difference between a vlan ID and a vlan tag.
And it may help if we think about this in terms of the historical context. Back when this was being developed there were multiple trunking protocols (Cisco had ISL, 3Com had VLT, IEEE had 802.1Q etc). So there was a very real possibility that a trunk port (using 802.1Q) might connect to a device that did not understand 802.1Q vlan tags. So implementing the native vlan was a way to assure that some essential functions (like spanning tree) could still work. In today's environment it would be difficult to find a device that did not understand 802.1Q tags and so the real need for native vlan is not significant - but it still exists.
The original post says "the other kind of traffic could be from a legacy device that does not have VLAN tag capability," Yes it might be a legacy device, but it could also be just a normal (current generation) PC which by default sends Ethernet frames with no vlan tag.
The original post also says "as we know every switch port has a vlan tag," This is a misunderstanding. It is not true that every switch port has a vlan tag. Any switch port configured as an access port will not have a vlan tag. vlan tags are used only on switch ports that are configured as trunk ports.