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

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 mode access
 switchport access vlan 10
 spanning-tree portfast

Option 2: My preferred method

interface Ethernet 0/2
 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.


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



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


About RedNectar Chris Welsh

Professional IT Instructor. All things TCP/IP, Cisco or VoIP
This entry was posted in Access VLAN, CCNA, Cisco, Native VLAN, VTP and tagged , , , , , . Bookmark the permalink.

4 Responses to The Access VLAN is dead. Long live the Native VLAN.

  1. diablo says:

    You did not consider the STP, L2 attacks and loops into consideration. 🙂

    • rednectar says:

      Hi diablo,
      1. I did actually consider STP – hence the line “spanning-tree portfast trunk” in the configuration. Remember, this article is about connecting end-stations to trunk ports, not about connecting switches to switches. I didn’t bother with a discussion of the few extra VTP or DTP packets that might be received by the end station – perhaps I should have, but I was trying to keep it as simple as possible.
      2. I’m not sure what L2 attacks you are referring to, but if you take for instance ARP poisoning, then it makes no difference if a port is configured as a trunk or access.
      3. Loops do not occur if you connect trunk ports to end stations. If a STP switch is connected by mistake to a trunk port that has been configured with “spanning-tree portfast trunk”, then the port will participate in spanning tree as soon as it receives a BPDU, and any temporary loop created should be resolved. I say “should be” because with Cisco you have non-standard PVST to deal with, and that can indeed cause loops. I guess I should add a recommendation that the global configuration command spanning-tree mode mst be added to all switches so that there are not multiple spanning trees around the place.

  2. Khaled says:

    Hi Chris,

    Thanks for the thorough and clear article.

    To answer your last question about Windows. VLAN tagging, as far as I know, is chipset dependent. I have come across NICs with Intel chipset in Windows (XP machines that is) which can perform VLAN tagging and some, with unknown chipset, that don’t. So as you can see, it’s either a chipset or driver-dependant issue.


    • rednectar says:

      Thanks Khaled. One would imagine that it is the same deal for Linux. I know that I often have trouble capturing VLAN tags on Wireshark on Windows PCs, even though I know the tags are there. Have spent hours tweaking registry settings looking for “coalescing ticks” (whatever they are) to make Windows allow VLAN tags to pass to Wireshark!

Comments are closed.