I saw a question recently that asked “What is the point of the Native VLAN?” – and I could sense a degree of frustration in the question caused by Cisco’s weird way of describing untagged VLANs differently on different port types as either Access VLANs or Native VLANs.  To try and clear the confusion, I answered with an abridged version of the following, finishing with a conclusion that we don’t really need Access VLANs at all, and we could run our network using just Native VLANs:

Tagged and Untagged

When a frame is forwarded on a port, it is sent either “Tagged” or “Untagged”.

For some vendors, that’s the end of the story.  For a given port, you have “Tagged” or “Untagged” VLANs, but for Cisco:

Tagged VLANs can be called:

• Tagged VLANs
• Voice VLANs
• Auxiliary VLANs (old terminology)

Untagged VLANs can be called:

• Untagged VLANs
• Access VLANs
• Native VLANs

Why Cisco has multiple names for the same concept is a mystery to me.  But it is not just a simple case of naming – although the terms “Native VLAN” and “Access VLAN” both refer to “Untagged VLANs”, they cannot be used interchangeably.  I’ll explain more later.

Vendors like Enterasys who simply use “Tagged” and “Untagged” to describe the traffic, rather than a port, allow you to specify which VLANs are allowed out that port, and whether the traffic should be forwarded with or without tags for each VLAN.  Normally, if a port connects to another switch, all traffic would be tagged and many VLANs would be permitted on that link.  If the port connects to a PC, traffic for only a single VLAN is forwarded, and is forwarded untagged.  If it connects to an IP phone/PC pair, traffic for the PC’s VLAN would be forwarded untagged, and traffic for the IP Phone would be forwarded with VLAN tags.

Trunk ports and Access Ports

In the Cisco world, links to other switches are known as “Trunk” ports and links to end devices like PCs are known as “Access” ports.

On a port, which is an Access Port, the Untagged VLAN is called the Access VLAN
On a port, which is a Trunk Port, the Untagged VLAN is called the Native VLAN.

So far, I have only talked about traffic leaving a switch.  Traffic entering a switch also arrives either “Tagged” or “Untagged”.  Tagged traffic has a VLAN ID embedded in the tag, so the switch knows which VLAN the frame belongs to.  But untagged traffic arriving on a switch port also has to be associated with a VLAN, and each port has to have a VLAN ID associated with it to act as the classifier for untagged traffic.  For some fanciful reason, which escapes me, Cisco has chosen two different ways to define this VLAN association.  On “Access” ports, untagged traffic is associated with the “Access VLAN”.  On “Trunk” ports, untagged traffic is associated with the “Native VLAN”.  Just why there are two different ways of describing the same thing remains a mystery to me, and caused me great confusion when I was coming to terms with Cisco esoteric implementation of VLANs.

The end result is that with Cisco’s two methods of handling “Untagged” traffic on a port it is possible to have a port assigned to “Access VLAN x” and to “Native VLAN y” simultaneously.  This can be especially confusing if the port also determines its “Trunking” configuration dynamically.  If such a port were connected to a PC, untagged traffic would be classified as belonging to VLAN x, whereas if it were connected to another Cisco Trunk port, untagged traffic would be classified as being on VLAN y.

Now back to the original question. “What is the point of the Native VLAN?”

Quite simply, the point of the Native VLAN is to specify which VLAN should handle untagged traffic for a given Trunk Port.

However, the “point” of having both the concept of an “Access VLAN” AND a “Native VLAN” I can’t help you with.  But I will help you with a few scenarios that you ought to be aware of when dealing with the “Native VLAN”.

Firstly, you are going to find in the future that you will need tagged packets on more and more ports – ports that connect to servers often need to see tagged packets, IP phones like to see tagged packets, some IP cameras use tagged packets, Video equipment, etc., etc. – the list grows longer every day.

So get used to the idea that pretty soon you’ll need to make lots of ports Trunk ports, so I’ll suggest now that you make ALL your ports trunk ports, and treat the Native VLAN as the VLAN that handles untagged traffic for that port.  Consider the following two configuration options for a switchport.

Option 1: Traditional Cisco

interface Ethernet 0/2
 switchport
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast

Option 2: My preferred method

interface Ethernet 0/2
 switchport
 switchport mode trunk
 switchport trunk native vlan 10
 switchport trunk allowed vlan 10
 spanning-tree portfast trunk

Both configurations will result in the same behaviour.  Only VLAN 10 traffic will be forwarded on each port, and it will be forwarded untagged.  Any untagged traffic arriving at the port will be classified into VLAN 10.

But now assume you want to create a Virtual Machine on your PC that’s plugged into Ethernet 0/2, and you want that VM to be assigned to VLAN 20*.  You’d now need to alter your configuration to:

Option 1: Traditional Cisco

interface Ethernet 0/2
 no  switchport access vlan 10 !Optional
 switchport mode trunk
 switchport trunk native vlan 10
 switchport trunk allowed vlan 10,20
 spanning-tree portfast trunk

Option 2: My preferred method

interface Ethernet 0/2
 switchport trunk add vlan 20

I think the second option is much easier.

Now the same story could be repeated for the following scenarios:

I want to add an IP camera.
I want to add a (forgive me – a NON-Cisco) IP Phone
I want to add [insert your own scenario here]

The Access VLAN is dead.  Long live the Native VLAN.

I will mention that there are a couple of disadvantages to making all ports Trunk Ports.

1. The “show interfaces status” command now shows all ports as trunk ports, and doesn’t show you which VLAN untagged traffic will be classified on, however the command “show interfaces trunk | in Mode|q” does a pretty god job instead.
2. The “show vlan” command only shows inactive ports (at least on ver 12.1(22)EA13 on a C2950).  I know NX-OS behaves differently with the output of the “show vlan” command, but I don’t have a Nexus 7K at my desk to try!
3. Your devices will now see some additional Cisco proprietary protocols that are only sent on Trunk ports, including DTP, VTP and PVST
4. If you don’t include VLAN 1 in the list of allowed VLANs, IEEE STP BPDUs are not sent

Native VLAN Traps

Let me finish with one more gem about the native VLAN.  And it concerns the “switchport trunk allowed vlan” command.  I want to tell you that you need to be very careful to include the “Native VLAN” in the list of allowed VLANs – especially if the port is connected to another switch.  Why? Because all those control protocol frames – CDP, VTP, DTP, STP etc are all sent on the Native (untagged) VLAN.  If the Native VLAN is NOT in the list of allowed VLANs, then these frames may not be transmitted. (I say MAY not, because with different switches and different version of IOS, different protocols are included or excluded).  This can lead to the creation of loops due to the lack of Spanning Tree BPDUs being transmitted, and unexpected behaviour if you rely on dynamic trunking or the Vlan Trunking Protocol to disseminate VLAN information.

Conclusion:

• The terms “Native VLAN” and “Access VLAN” are two different ways of referring to untagged VLANs on Cisco switches – each term is tied to a port type.  Native VLANs for Trunk Ports and Access VLANs for Access ports.
• If you make all your ports trunk ports, you won’t have to worry about “Access VLANs” any more, and your configuration will be more flexible.

End

Footnotes:

*This assumes you have a PC that supports tagged frames.  My OS X does, and I’ve done it on Linux.  I don’t know about Windows.