I have always been a little confused with regards to 802.1Q Native VLAN. For example lets say there was a 802.1Q Trunk between two Switches and the native VLAN command ( switchport trunk native vlan x ) was used on both ends as required. What affect does that have on VLAN 1...? Does this mean that VLAN X and VLAN 1 are both carrying less ( untagged ) overhead across the Trunk link...? Furthermore all defined VLANs will still continue to propagate across the Trunk thanks to VLAN 1.
When a switch port is configured with the default natave vlan, you will really not see a native vlan configured in the configuration on that port. This is the equivalent of "switchport trunk native vlan 1". In this case any traffic on vlan 1 that is leaving the switch is untagged. Any untagged traffic coming into the switch is assumed to be on vlan 1.
If we changed it to say vlan 10, then any traffic on vlan 10 that was leaving a switch would be untagged. Any traffic arriving untagged would be assumed to be on vlan 10. Additionally, in this case, traffic leaving the switch that was on vlan 1 would be tagged just as any other traffic except the traffic that was from vlan 10. As stated, any traffic arriving untagged would be assumed to be part of vlan 10, and therefore cannot be part of vlan 1.
There is only one native vlan per trunk. This must match on both ends of the trunk and is responsible for all of the untagged traffic. The native vlan could also be called the untagged vlan.
Here is the scoop! Trunks ONLY CARRY TAGGED FRAMES, that's what trunks were designed to do. the purpose of a trunk is to be able to TRANSFER DATA FROM DIFFERENT VLANs. The reason the frames are tagged before they traverse the trunk is so that when it gets to the other side of the trunk, the switch can READ THE TAG AND DETERMINE WHICH VLAN THE FRAME BELONGS TO and then forward it on to that VLAN.
Now the native VLAN. The purpose of the native VLAN is so that if untagged data finds its way traversing the trunk (usually because it entered the trunk somewhere in the middle, most likely from a connected hub so that the frame could not be tagged by the switch before entering the trunk), when that untagged frame gets to either end of the trunk, the switch then reads the frame sees that it is an untagged frame that ended up on the trunk and sends that untagged frame to the VLAN that has been assigned as the native VLAN.
Remember, TRUNKS ONLY CARRY TAGGED FRAMES, all untagged frames goes to the native vlan. So to answer your question, if VLAN1 hits the trunk, it too will be tagged, so that the switch on the other side of the trunk can determine which VLAN the frame belongs to and forward the frame to the appropriate VLAN.
I don't agree with the fact that trunks only carry tagged traffic. If you hard code a switch port to trunk mode and configure the native vlan. You can connect a pc with addressing for that native vlan. It will work fine.
Additionally, if that was the case and you configured two connected switches with different native vlans, those vlans should still be able to communicate. That is not the case, the non native vlans can communicate but those native vlans will no longer communicate.
A native vlan is not tagged. Packets egressing a port with a native vlan of 10 will be untagged. Incoming untagged packets on a port with a native vlan of 10 will be handled as part of vlan 10. Meaning if they were forwarded out another trunk with a different native vlan, they would be tagged with vlan 10 at that point.
I just love these debates, don't you? The really stimulate the mind.
Paul, I believe you are on the right track but you are misunderstanding a basic principle. If a frame originates from a PC that is connected to a port that is a member of the native VLAN, then hits the trunk from its ingress port and NOT FROM THE MIDDLE, OR SPECIFICALLY FROM A HUB THAT CONNECTS THE TWO SWITCHES, then that frame will be tagged and treated as a frame that the switch knows which VLAN the frame originated from at the egress port and therefore, which VLAN it needs to go to. The only untagged frames that traverse the trunk are those that originate somewhere in the middle, THATS THE ONLY WAY AN UNTAGGED FRAME CAN APPEAR ON THE TRUNK, and of course if it is untagged, the switch sends that frame to the native VLAN because the switch has no way of knowing what VLAN the frame originated from because it did not originate from any VLAN.
When you stated that the native VLAN can be considered the UNTAGGED VLAN, that is true, but also false . Here's why, the native VLAN is a genuine VLAN with it's members, and send frames that are encapsulated/tagged etc. etc. but it also take care of frames that does not have an assigned VLAN membership and are therefore untagged.
I look forward to your feedback.
I too, absolutely love these debates. I am standing by my position though. I think we agree on the fact that untagged traffic received by a trunk port will be handled as though it is in whatever native vlan. I know that it is unlikely that anyone would trunk through a hub and that would be the only way traffic could be introduced in the middle of the link. The native vlan is a real vlan with its members. That said, the native vlan is a per trunkport configuration. Both ends of the trunk ports should match.
The point that we disagree on is on typical traffic traversing the trunk that is part of the native vlan. The default method for transferring these dot1q frames is untagged. I am assuming that we are talking about dot1q as opposed to ISL (which lacks the concept of a native vlan and tags all frames).
This behavior is documented at the following url:
Wikipedia Says this is in clause 9 of the ieee standard.
On some Cisco devices, you can change this behavior to always tag with the following command.
vlan dot1q tag native
This is per the following document:
This document also states that vlan tagging on the native
vlan is disabled by default.
This brings up a couple of interesting points most people do not realize. The fact that dot1q has a native vlan can allow double encapsulation of dot1q frames and vlan hopping (if you have access to another trunk). Second CoS does not carry across a trunk for the traffic on the native vlan.
I submit, you are indeed both a Scholar and a Gentleman. After reading the documents you provided the links to (I saved them by the way) I it does appear that you are absolutely correct. The document clearly states that "802.1Q does not tag frames on the native VLAN. It tags all other frames that are transmitted and received on the trunk". I was also unaware that there is a command option that allows us to modify the default feature and enable or disable tagging of native VLAN frames, all very interesting stuff. Thank you very much. This is why I truely enjoy these debates Paul.
Do we agree however, that Wikipedia is incorrect in one of its statements? Wikipedia indicates that "Frames which ingress (enter) this port and have no 802.1Q header are put into VLAN 2" (VLAN 2 is the native VLAN in their example and "this port" refers to a trunk port). I ask this because, trunk ports are designed to carry VLAN traffic, not only that but, ALL SWITCH PORTS HAVE TO BELONG TO A VLAN. VLAN 1 is the default VLAN, but how can a frame that does not belong to a VLAN, ingress the trunk port on a switch if it did not belong to a VLAN to begin with, or it did not enter the trunk from somewhere in the middle? I submit, it simply cannot.
Well done Paul, very well done.
Your explanation makes a lot of sense, you are quite correct in assuming that traffic that passes through an IP phone that originates from a PC is sent untagged, because the IP phone has no way of determining what VLAN that PC belongs to. PCs don't know, nor do they care anything about VLANs, so they don't send encapsulated frames. The IP phone will forward the untagged frame to the switch, the untegged frame will then hit the ingress port and then be treated as any untagged frame will.
See there, again I learn something. I did not think about access to the ingress port via an IP phone, which is basically a mini switch providing access to the ingress port for a frame that does not originate from a VLAN.
This debate has been truly rewarding, I hope you enjoyed it as much as I did.
Thanks again Paul, I give you two bows.:D
I think that 802.1Q is hardware (trunk) and then software. Default VLAN 1 is because you need a transmission medium when you start to configure all switchs. VLAN 1 is like a hardware multiplexor T1-T1 (point-to-point) you not need software.
Sorry for my english.
A quick point of information to expand everyone's knowledge...
Regarding "as opposed to ISL (which lacks the concept of a native vlan and tags all frames)"
ISL does not actually tag frames like dot1q, but rather encapsulates frames.
Thanks for the explainations regarding how the native VLAN is handled on trunks. But I still have two questions.
1- First one "default native VLAN". Is that a global setting for the switch ? If I understood correclty what Paul explained, the answer seems to be yes. Native VLAN (alone, without the prefix "default") is different from the default native VLAN and is applied on a per trunk / port basis)
2- Second question: why should the native VLAN be the same on both sides of a trunk ? Is that a 802.1Q requirement ? If yes, why such a requirement (I can imagine that we don't want untagged frames to travel from VLAN to VLAN)
What happens if this rule is not followed ?
Let me try to give you an exemple, please understand that I don't know the cisco command line (but I am interested in the concepts)
switch A trunkX accepts/part of VLAN 2 , 3 and 4, native VLAN 5
switch B trunkY accepts/part of VLAN 2, 3 and 4, native VLAN 6
If everything is fine in the configuration except the native VLAN mismatch, what will happen ? (no frame will travel, trunk down, VLAN 2, 3 and 4 ok but untagged frames will be rejected ...)
Thanks in advance
1- Defining the native VLAN is done on an interface level, the Cisco default for a Native VLAN is 1. So if I have 2 switches connected to each other on fast ethernet 0/1 on both sides, and I configure those ports for 802.1q (dot1q) trunk encapsulation, and set both ports to trunk ports, I now have a trunk between the 2 switches, with a Native VLAN of 1. Even though dot1q does not "encapsulate" the frame, I used the word "encapsulate" above becasue that is how the IOS accepts the command syntax (switchport trunk encapsulation dot1q) 802.1q actually places a 4 byte tag after the source mac-address of the frame, ISL on the other hand (Cisco proprietary) adds 40 bytes of encapsulation.
Now we have a trunk port using 802.1q with a native VLAN of 1 connecting the 2 switches. A Native VLAN will not be tagged by 802.1q (ISL will encapsulate the native VLAN). So any access ports that are assigned to VLAN1 will not be tagged when being transmitted between the switches. This is not a bad thing, but it should be avoided as it is not a good practice and some can argue security concerns. The native VLAN is used primarily to transmit management information between 2 switches, management information such as CDP packets, VTP packets, Spanning-tree information, and PaGP.
To change a Native VLAN on a port, you would use the "switchport trunk native vlan x" and each trunk can have a different native VLAN, it is not a global configuration.
2- If the native VLAN's do not match on an 802.1q trunk, then Spanning-Tree will place the mismatching VLAN in a PVID inconsistent state, essentially blocking the management traffic from being exchanged, your network can still technically work, but might have undesireable effects, loops, port channel issues etc. ISL does not require the native vlan's to match, but if you are reviewing your syslog daily, then you should get tired of seeing the native VLAN mismatch errors
I hope that clarifies that a bit for you,