802.1Q Native VLAN on Cisco IOS Switch

Hi 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?

Hello Karan

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.

I hope this has been helpful!


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.

1 Like

Hello Andrew,

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?

Hello Aniket

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.

A sample config would be:

interface gigabitetherent 0/0
  switchport mode trunk
  switchport trunk allowed VLAN 137
  switchport turnk native vlan 135

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:

 interface gigabitetherent 0/0
      switchport mode access
      switchport access vlan 135
      switchport voice vlan 137

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:

I hope this has been helpful!




I have a question, what happen If I configure “vlan dot1q tag native” in one switch and doen’t in the another peer?

Is this cause a problem with control traffic? what would happen with trunk in both sides?

This is why not all switches that I configure supports this command.

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”

Scenario 1:
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.

Hello Carlo

@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.

I hope this has been helpful!


1 Like

Hi Lazaros
I have questions:

  1. 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?
  2. 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.
  3. What is the native VLAN in protocols, like: CDP and others mentioned above? I am totally confused about this.

Hello Muhammad

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.

I hope this has been helpful!


Thanks Lazaros,
Now it is clear.

1 Like

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.

Hello Waseem

When using wireshark on a switch, it is most often used with the SPAN or RSPAN feature of a switch. Take a look at this lesson, which explains this feature.

I hope this has been helpful!



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?

Hello Andy

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:

I hope this has been helpful!


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?

Hello Murat

ISL has no concept of VLAN tagging and as a result, it has no concept of the native VLAN either. This is because ISL works on a completely different principle than 802.1Q.

ISL will take an Ethernet frame and it will encapsulate it into an ISL frame. This frame places an additional header of 26 bytes to the Ethernet frame along with an ISL CRC trailer. The information about the VLAN to which the frame belongs is contained within the ISL header.

802.1Q doesn’t add a whole header, but adds a field to the existing frame header where the tag is placed.

I hope this has been helpful!


Hi Rene,

On a previous post you mentioned the host never adds a tag on the ethernet frame but when the switch receives the frame it adds the tag. Also I know that all access interfaces have to belong to a vlan.
Now when it comes to the native vlan, what do you mean when you saying “when the switch receive an untagged frame”? as if it is a host attached to the port, it will always receive untagged frames and then will add the necessary tag. So if the interface belongs to the native vlan membership will add the native vlan tag. is it correct?

Hello Charalambos

When rene says “when the switch receives an untagged frame?” he means “on a trunk port”. Of course you are correct that all frames received on an access port will be untagged, but the native VLAN has meaning only when an untagged frame is received on a trunk port. Only then will that frame be placed on the configured native VLAN of that trunk port, otherwise, the switch doesn’t know which VLAN to place it on.

You might say “how can an untagged frame find itself on a trunk?” and you would be correct in asking that question. When a network is configured correctly, this shouldn’t happen. For more info on examples where this may occur, take a look at this post:

Having said that, there is a special case where untagged frames are received by trunk ports, and that is when you connect an IP phone to a switch, and a PC to the IP phone. The configuration doesn’t specifically use the term “trunk” although that is essentially what is created. You can find out more about that at this post:

I hope this answers your question, and although I have gone a bit overboard in providing additional information ( :stuck_out_tongue: ), I hope that you find it useful.