Why Do We Have Native VLANs?

Recently, my friend Andy Lapteff asked an excellent question. Why do we have native VLANs? As in, why allow untagged frames on a trunk link?

There was a time where we didn’t have VLANs. At first there was hubs, then bridges, multi-port bridges, and finally switches. Cisco was one of the first vendors to introduce VLANs, even before it became a standard, through the use of Inter Switch Links (ISL). ISL is long gone and encapsulated the entire Ethernet frame so native VLANs were not relevant there. In 1998, the 802.1Q standard was released.

In 802.1Q, 1.2 VLAN aims and benefits, the following is described:

a) VLANs are supported over all IEEE 802 LAN MAC protocols, and over shared media LANs as well as point-to-point LANs.
b) VLANs facilitate easy administration of logical groups of stations that can communicate as if they were on the same LAN. They also facilitate easier administration of moves, adds, and changes in members of these groups.
c) Traffic between VLANs is restricted. Bridges forward unicast, multicast, and broadcast traffic only
on LAN segments that serve the VLAN to which the traffic belongs.
d) As far as possible, VLANs maintain compatibility with existing bridges and end stations.
e) If all Bridge Ports are configured to transmit and receive untagged frames (3.14), bridges will work
in plug-and-play ISO/IEC 15802-3 mode. End stations will be able to communicate throughout the
Bridged LAN.

This should all look familiar. Note that it’s explicitly mentioned that backwards compatibility (d) is an aim of the standard.

Then, in 3.3 Frame, there are three types of frames that are defined:

• Untagged frames.
• VLAN-tagged frames.
• Priority-tagged frames.

Most people will be aware of untagged and tagged frames, but perhaps not that frames can be priority-tagged and that it’s possible to have a priority tag without a VLAN tag.

Later, in 3.13 Tag header, it’s interesting to note that the standard says:

A tag header allows user priority information, and optionally, VLAN identification information, to be associated with a frame.

Priority tagging was an important part of the standard even though it didn’t get deployed that frequently.

In 3.16 Virtual Local Area Network, a VLAN is defined as being a subset of the active topology of a bridged LAN. Associated with each VLAN is a VLAN Identifier (VID).

In 5.1 Static conformance requirements, it’s defined what is needed to conform to the standard. It describes conforming to previous standards, relaying and filtering of frames, but it also introduces the concept of a Port VLAN Identifier (PVID) and how the PVID must be able to be set by management operations. It also mentions that the bridge must be able to insert, modify, and remove tag headers.

Later in 6.3 Relay, there is a point that’s easy to miss when reading the standard. It says that each received frame must be classified as belonging to one and only one VLAN. Then it also says that the ingress, forwarding, and egress rules allows a bridge to classify any received untagged or priority-tagged frame submitted to the forwarding process as belonging to a particular VLAN, as defined by the PVID for the receiving port.

This means that even when untagged frames are received, they must be able to be mapped to a VLAN.

6.5 VLAN Classification says that untagged frames are classified belonging to a particular VLAN based on parameters associated with the receiving port, or proprietary extensions of the standard.

Then, in 6.6 Rules for tagging frames, it says that for a given VLAN on a LAN segment, all frames for that VLAN must either be tagged or untagged. It also says that both tagged and untagged frames can be sent on a link, but not for the same VLAN.

In 8.3 Model of operation, it says that a bridge may filter frames based on the absence of a VID, as well as the presence of a VID.

Then in 8.4.3 Acceptable Frame Types, it says that a port can operate in two modes:

• Admit only VLAN-tagged frames.
• Admit all frames.

Admitting only VLAN-tagged frames would mean discarding untagged frames.

Then we come to 8.4.4 Port VLAN identifier, which is a key part of the standard. There it says that each port should have a PVID that is used to classify untagged and priority-tagged frames. This includes frames with no tag, as well as tagged with null VLAN ID. The PVID can’t be null. This rule is to ensure that every frame received is associated with a non-null VID.

In 9.3.2.3 VID format, the following VLANs (in hex) are defined as reserved:

• 0 – Null VID indicates that tag header only has priority information.
• 1 – Default PVID used for classifying frames. This can be changed by management on per-port basis.
• FFF – Reserved for implementation use.

Going back to the standard explains why a Cisco switch always has all ports in VLAN 1 by default.

So far we’ve learned the following based on the standard:

• VLANs are supported both on shared media as well as point-to-point LANs.
• The standard should as far as possible maintain compatibility with existing bridges and end stations.
• Frames can either be untagged, priority-tagged, or tagged.
• A VLAN is a subset of the active topology of a bridged LAN.
• Each VLAN has a VLAN Identifier (VID).
• Each port has a Port VLAN Identifier (PVID) that is used to classify untagged and priority-tagged frames.
• Priority-tagged frames have a VID of 0.
• The default PVID is 1, but can be changed by management.
• Each frame must be classified as belonging to one and only one VLAN.
• A VLAN can’t be both tagged and untagged on the same link.

With this information we now turn to the annexes of the standard which has some interesting information. In Annex D.1.3, the concept of hybrid links is introduced. A hybrid link is a LAN segment that has both VLAN-aware and VLAN-unaware devices attached to it. The hybrid link can carry both VLAN-tagged as well as untagged and priority-tagged frames. Why would we have a scenario with both VLAN-aware and VLAN-unaware devices? When you’re introducing a new technology, which 802.1Q was at the time, you’ll have legacy devices. These were VLAN-unaware bridges or even hubs! Let’s take a look at the topology below:

The hybrid link is a shared segment. It could for example consist of VLAN-unaware bridges and/or hubs. In VLAN Z, there are VLAN-unaware end stations. This means they will send untagged frames. For these frames to make it to the right-hand bridge, the hybrid link must know what to do with the untagged frames. This is where the PVID comes into play. The PVID on a trunk link on a Cisco switch is the native VLAN. It’s the VLAN that untagged frames belong to. Note that if there was another VLAN with VLAN-unaware end stations on the shared segment, that would be undistinguishable from VLAN Z.

With a better understanding of the 802.1Q standard and it’s aim to be backwards compatible, we now understand why there had to be a mechanism to associate untagged frames with a VLAN, the PVID. Cisco refers to this as the native VLAN on a trunk link.

The networks we build now, and for the past 20 years, generally only have point-to-point LANs meaning that trunk links exist between two switches. On such a link, there isn’t much of a usecase for a native VLAN and many switches allow you tag all frames, including the native VLAN.

What are some scenarios today that would warrant having a link with both tagged and untagged frames? A few come to mind:

• A port that connects to an IP phone where user is also connected.
  • The phone would tag frames and user frames would be untagged.
• Zero Touch Provisioning – An existing switch connected to a new switch with existing switch configured with a trunk port. The new switch will boot up with all ports in VLAN 1 and try to acquire an IP address. As the trunk port has a native VLAN, it accepts the untagged frames.
• Port towards virtualization host where some frames will be tagged and some untagged.
• Preparing a port for tagged frames, but allowing untagged frames. For example, connecting a server at first it may have a single VLAN, but then requires multiple. Configuring the port as trunk with a native VLAN allows for this.

Coming back to the original question. The native VLAN is mainly there for historical reasons, to be backwards compatible with devices that were VLAN-unware. These were generally bridges or hubs. Still, the native VLAN provides some nice use cases even to this day. I hope this post has been informative and see you in the next one!