I have a question. The part you said “The vlan dot1q tag native is a global command so it applies to all interfaces. If you want to exclude certain interfaces, you can use the no switchport trunk native vlan tag command on the interface level.”. Currently I have all of my switches using Native VLAN 1. I want to change all Native VLAN 2. If I am to do the global command, will it bring down my network/switch? This is how our network works. Router -> Switch 1 -> Switch 2 -> Switch 3 -> Switch 4. I logged in Switch 1. If I am to do global command to change all to Native VLAN 2, will it bring down Switch 3 and Switch 4? What about router? I don’t maintain the router, my ISP does. Suggestion? Thank you, Vincent
By default, and by definition, the native VLAN is the VLAN on which all untagged traffic that arrives on a trunk port will be placed on. On Cisco switches, we have the option of obligating all native VLAN traffic to be tagged. This is achieved using the global command that Rene mentions in the lesson. So this command will cause all native VLAN traffic to use tags.
If you want to change which VLAN will be the native VLAN, there is no global command to do this. This is done on each interface that is configured as a trunk. You will have to go into each trunk interface on each switch and make the change.
Now it is best practice to configure trunk ports to use a native VLAN that is not used by user traffic. If your native VLAN is in use for user or management traffic, and you have configured it on the trunks, then changing the native VLAN may have an affect on the network. It all depends on how your trunks are configured. It would be a good idea to make the changes during a maintenance window and to make sure that you have local access to all switches such that if you lose connectivity, you can connect locally via a console cable.
This change should not affect the connection to the ISP router since that should connect to an access port of Switch 1 which does not deal with the native VLAN.
Thanks for the explanation. I have a question if this will work or not. If I have these switches linked together via trunking (Native Vlan1) and we don’t have any using vlan 2. I plan to change all to native vlan2. I have switch 1 trunked to switch 2, then switch 2 port 15 trunked to switch 3. Then switch 2 port 16 trunked to switch 4. Then switch 4 trunked to switch 5. Should I do it this way and it won’t interrupt the network for those switches -> configure switch 5 trunk to Native Vlan 2, then Switch 4 to Native Vlan 2, then Switch 3 to Native Vlan 2 then Switch 2 to Native vlan 2 then switch 1 to Native vlan2. Will this work and won’t affect the network? Thanks, Vincent
You should be fine but still I wouldn’t recommend changing this on Monday morning 9 AM.
Once you change the native VLAN on one side, you will see a CDP message:
%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet0/2 (2), with SW2 GigabitEthernet0/2 (1).
I had two devices in VLAN 100, one connected to SW1 and the other one connected to SW2 and my ping keeps running, even with the native VLAN mismatch on the trunk. Still, you might have some other protocols in the native VLAN that don’t like this.
M apologies if my question is irreverent I would like to know what kind of system generate untag packet/frame in the real network environment and how that untag frame look like ( does it is same as Ethernet frame with tag ) and why it, not getting discard/drop by while encapsulating with the IP packet in transport layer when we have the checksum mechanism?
Frames that are sent from almost all network devices such as computers, are sent without tags. Frames sent out of access ports on switches are also sent without tags. Tags are only added when a frame exits a trunk port and are removed once again when it enters the trunk port on the other end. Tagged frames should only exist on the link between two switches connected via a trunk.
Having said that, the Native VLAN is set up on a trunk so that any frames that do arrive on that trunk port without a tag will be placed on the appropriate VLAN. Situations where this is used is when switches communicate with each other using control frames such as those use in the CDP, VTP and STP protocols.
Another situation in which the native VLAN can be used is depicted in this topology:
Now the network shown above contains a very bad network design and should never be replicated, but it is used to prove a point. PC1 is connected to a hub which is in turn connected to Switches A and B. The link between Switches A and B (via the hub) is a trunk connection. Any frames sent by PC1 will be sent without tags, so untagged frames will reach the trunk ports of Switches A and B, due to the hub. Those frames will be placed on the configured native VLAN on each of those trunk ports.
An untagged frame is not a frame with an error, it is just one that doesn’t include the tag. This would not show up as an error so it wouldn’t be caught by the checksum mechanism.
Exactly Andrew, i work on private p2p network for video delivery and first step when configuring a switch is to make sure VLAN 1 not assigned to any port and create interface vlan 1 with no ip address and shut. All our switches pass cdp etc.
I have seen a working scenario wherein DATA VLAN is 135 & VOICE VLAN is 137, also switch port is not TRUNK, Native VLAN is 1. So how could DATA Vlan traffic will go untagged as DATA Vlan being 135… Also under switchport we are giving commnad as "Switchport mode access " for DATA vlan, then how can we put this interface in Trunk mode?
There are two ways to implement the following scenario:
One is to configure the Gi0/1 interface as a trunk. Let’s say the voice VLAN on our network is 137 and the data VLAN is 135. We would configure the Gi0/1 interface as a trunk, with a native VLAN of 135 and an allowed VLAN of 137. This means that frames on VLAN 135 destined for H1 would exit the Gi0/1 interface untagged. Any such frames reaching the IP phone would continue on to H1. Any frames on VLAN 137 destined for the phone would exit the Gi0/1 with a tag of 137. The phone receives this frame, removes the tag and takes the frame for itself to be processed.
Now this is the “old” way of implementing voice in this manner. It is actually still used on Cisco switches when configuring third party vendor phones. The “new” way of implementing this is using the voice VLAN.
In this case, the interface is configured as an access interface with an assigned VLAN oif 135, which is the native VLAN. An additional command would be added indicating which is the voice VLAN, specifically, VLAN 137. A sample config is the following:
The configuration is a little more elegant and more intuitive, but the result is the same. Now there is the following important difference between these two configs: the latter involves CDP communicating with the IP phone and letting it know which is the voice VLAN and which is the data VLAN so it can react correctly to the appropriate tagged/untagged frames.
To find out more about the voice VLAN and how it is configured, take a look at this lesson:
Side of a trunk with “vlan dot1q tag native” set, is going to drop all frames, that are not tagged with dot1q.
Switch A: is not tagging frames on its native vlan
Switch B: is tagging all frames, including frames from his native vlan, because there is set “vlan dot1q tag native”
Switch A is sending frame from his native vlan to Switch B. Frame is not tagged, because it belongs to Switch A native vlan. Switch B drops that frame, because he expects only tagged frames. Scenario 2:
Switch B is sending tagged frame from its native vlan, with native vlan number tag. Switch A normally accepts this frame and process it.
Nevertheless control traffic like CDP will pass from Switch A to Switch B just fine. It is not really tagged, but Switch B will process it. For control traffic it does not matter that one side of a trunk is tagging native vlan and other is not.
@fugazz has got it right. His example scenarios are clear and correct.
As for control traffic such as VTP, CDP, and PagP they will never be tagged (even if you configure tagging on the native VLAN) and they will always use VLAN1 even if you have configured another VLAN as native VLAN. This is the case even if you have disallowed VLAN1 from a specific trunk! Other control traffic such as DTP for example, will use the configured native VLAN, but will still be sent untagged even if you configure tagging on the native VLAN.
When we configure VLAN 1 on Switch1 and Switch 2, and there is trunk b/w both switches, when traffic comes from PCs to switch and then to trunk port where does tagging occur?
Am I correct? For this:
when traffic comes from PCs to switch so the switches check which VLAN the traffic belongs to if the VLAN is configured on both switches then OK otherwise the traffic will be sent to NATIVE VLAN that is VLAN 1 by default this is called Native VLAN.
What is the native VLAN in protocols, like: CDP and others mentioned above? I am totally confused about this.
VLAN tags only exist on the trunk itself. In other words, if you have Fa0/1 interfaces on two switches connected to each other, and these interfaces are configured as trunks, then as the frame egresses Fa0/1 of SW1, the tag is added. Once it reaches Fa0/1 of SW2, the tag is removed.
So let’s say PC1 connected to SW1 sends a frame to the switch. The port on the switch where PC1 is connected is configured as an access port on VLAN1. The switch will receive this frame and will send it out of Fa0/1 on SW1. When it does so, it knows that it belongs to VLAN1, because it came in on a port that is an access port on that VLAN. So it adds a tag with the appropriate VLAN and is sent over the trunk.
When it reaches Fa0/1 on SW2, which is also a trunk port, the trunk port reads the VLAN tag, removes it, and sends the frame to the appropriate egress port on VLAN1, where PC2, the intended destination, is connected.
Concerning how the native VLAN functions, take a look at this previous post:
Finally, concerning protocols like CDP and VTP that require Layer 2 connectivity to exchange information, these protocols always use VLAN1 and will be untagged (unless configured otherwise). These protocols function in this way as an exemption to the normal rules governing tagging and native VLANs. The post above explains this in more detail.
Dear ReneMolenaar, how did you capture the Traffic over wireshark as I am little unaware to how to use wireshark but as i am trying to capture traffic over switch interface but it doesnt showing me anything, please help.
This article said that the native vlan carries some control plane traffic. I’ve read elsawhere that the DEFAULT vlan (always VLAN 1) carries the control plane traffic (CDP, STP, etc.). Can you clarify? There seems to be some contradiction here.
Under which circumstances would you want to tag the native VLAN?
You are correct, in most cases it is indeed the default VLAN that carries the control traffic. CDP, VTP, DTP all use VLAN1. Some types of STP however (MSTP for example) use untagged frames, meaning they automatically use the native VLAN, as do LACP and LLPD. To some extent, it is IOS and platform dependent as well. So some control traffic does use the native VLAN, some uses the default VLAN, but which uses which can vary from platform to platform, and configuration to configuration.
Why would you want to tag the native VLAN? This is done for security purposes to mitigate against techniques such as double tagging to gain access to other VLANs. More about this can be seen in the following lesson:
if we use ‘switchport trunk encapsulation isl’ for trunking on both SWs, why should we still use ‘vlan dot1q tag native’? Why can not we use ‘vlan isl tag native’?
Can TAGging native vlan be done only with 802.1q?