CUC (6) CUCM (28) Jabber (6) Python (2) Routing (3) Solarwinds Orion NPM (4) switching (1) Video (6) voice (3)

Thursday, 17 September 2015

Native VLANs; not hard at all, when used hardly at all

In my years working in IT, I have heard people say some pretty smart stuff about native VLANs. But I have also heard a lot of confused, or plain wrong comments on the topic.  This post is aimed to explain some of the 101 on native VLANs and provide some examples of when to use it and when not. So let me get going.

I am assuming I will not need to explain how a VLAN works, so let's go straight to switch trunks.

Trunk ports, contrary to access ports, can carry multiple VLANs over the same physical link.  Think of it as multiplexing VLANs. You typically see trunk configurations between switches, or links labelled as "uplinks" in general. There are two main techniques to accomplish this:

  • Interswitch Link (ISL), which is a Cisco Proprietary protocol
  • IEEE 802.1Q  (dot1q), which is standards based

Because ISL is rarely deployed and because it does not support native VLANs, I will only address the more pervasive dot1Q.  Please also note,  that I have not mentioned Cisco's VLAN trunking protocol (VTP). Why?  Because, really it has nothing to do with the establishment of a trunk between two devices. Although some people seem to think it has.

So back  to dot1q, and like I said before; in order to understand native VLANs you will need to understand how dot1q works.

Dot1Q is the IEEE standard for tagging frames on a trunk and supports up to 4096 VLANs.  IEEE 802.1Q also defines the Multiple VLAN Registration Protocol (MVRP) (which is defined in the IEEE 802.1ak amendment),  allowing switches to negotiate the set of VLANs to be used over a specific link. MVRP is not to be mistaken with Cisco's proprietary VTP.

With dot1Q, the trunking device inserts a 4-byte tag into the original frame and recomputes the frame check sequence (FCS) before the device sends the frame over the trunk link. At the receiving end, the tag is removed and the frame is forwarded to the assigned VLAN. Dot1Q does not tag frames on the native VLAN.  And there ye go, I have said it!

When an ethernet frame needs to traverse a dot1q trunk, that frame gets changed by adding its VLAN tag into it, and re-computation of the FCS. As per below:

The TAG is 4 bytes long, of which 12 bits represent the VLAN ID (hence a maximum of 4096 addressable VLANs). So the VLAN tagging is used for all (you guessed it), but the native VLAN.

This means that if you are using a native VLAN on a trunk, it will need to be set on the other side of that trunk as well. Because if you don't it will break traffic across the trunk for that particular VLAN. Imagine the following scenario:

SW1:Trunk Port with VLAN 2 tag | ------>|SW2:Trunk Port native 2

When a frame, belonging to VLAN 2,  goes from SW1 to SW2, in this scenario that traffic would die. This is because SW1 will tag the traffic as being in VLAN2 and SW2 will only put traffic in VLAN2 if dot1Q does not tag it. Likewise, traffic in the opposite direction will fail. This because SW1 will receive untagged traffic and does not know what to do with it. Because remember SW1 does not have a native VLAN is defined on its trunk port.   If you do not set the native VLAN the same on both sides of  a trunk, you will get syslog errors, notifying you of this.

So realistically, VLAN configuration takes place per trunk port and only applies to that trunk port; IT IS NOT A GLOBAL configuration. This means, you could, if you wanted, have multiple native VLANs active on a single switch. But please don't.

By default, the native VLAN is 1:

ararat-sw1#sh int fa0/1 trunk

Port        Mode             Encapsulation    Status           Native vlan

Fa0/1       on               802.1q                trunking         1

So when would you use a native vlan?

What you have to remember, is that dot1Q was designed with backward compatibility in mind. In other words it can cater for devices that cannot tag VLAN's. I have done substantial digging on this subject, but I cannot find a valid reason why native VLAN's should be used, other than lazy switch configuration work. So honestly I cannot come up with a valid reason to use a native VLAN in the year of the Lord 2015.   Let's face it, printers, PC's, laptops, IP camera's and so forth, do not tag VLANs. They can, but no one really cares, because they are typically connected to an access port and are therefore put in whatever VLAN is configured on the access port, that particular device connects to.  Or alternatively, because we will never connect an end device to a trunk port, we don't care if that device can trunk or not.

Anyone who can provide me with a valid use of the native vlan on access port level, please drop me a line and I will revise this post accordingly

Cases were native vlan's are used unnecessarily:

  • switch access ports that do not have a switchport access vlan xyz configured on them, meaning anything connected to such a port by default lands in VLAN1 and yes, thus by default in the native vlan

  • Access points connected, with multiple SSID's connected to a switch through a trunk port and somehow using native vlan

  • ESXI host, again connected to a trunkport on the switch and some vmnic are tagging and other's are not.


Stop using it, it is confusing, it can break links if not configured properly and pretty much, has no added value.


  1. "In a nuttshell, dot1Q is only a mechanism that switches use to communicate a simple message to their neighboring switch; "he dude tell me which VLANs have you got, and I will tell you mine"."

    First off 802.1Q doesn't announce anything to its neighbor. 802.1Q just tags frames with VLAN ID's and matches incomming frames with VLANs it recognizes. VLAN 1 is tagged as "1" and any VLAN can be set as the default VLAN. VLAN0 is untagged frames and reserved for that reason.

    There are many reasons to use a default VLAN.

    1. Thanks for your input, Yes and no. Dot1Q contains the dot1ak amendment which defines, Multiple VLAN registration protocol, aimed at allowing switches to communicate values like VLANs across trunks. However, Cisco's interpretation of dot1ak, is VTP, which, by its own right is not dependent on dot1q. I have therefore revised this post somewhat.