Some History on VLAN 1 in Cisco Switches

Over the years, there has been a lot of discussion on if VLAN 1 in Cisco switches is special or not. Does it have any characteristics that other VLANs don’t? I covered some of this in the Is VLAN 1 Special in Cisco Networks. This time I thought it would be interesting to give some historical perspective on VLAN 1 and describe some of the implementation details that I learned from Francois Tallet. Francois was heavily involved in L2 and STP when at Cisco.

The 802.1Q standard was released at the end of 1998. Several years before that, Cisco had introduced Inter-Switch Links (ISL) and Dynamic ISL (DISL) to support VLANs. The main difference between ISL and 802.1Q is that ISL encapsulates the entire frame as opposed to 802.1Q that adds a field to the existing frame. DISL was a method of forming trunks dynamically, a predecessor to Dynamic Trunking Protocol (DTP) if you will.

Before VLANs and before ISL, it was simple to send control plane protocol frames such as CDP, PAgP, STP, etc. There was no concept of VLANs so there was no relation to VLANs or encapsulating/tagging the frames. When VLANs were introduced, now things become more interesting as you would create trunk ports between switches and encapsulate the frames using ISL. Because ISL encapsulates every frame and the entire frame, there is no concept of a native VLAN or an unencapsulated frame. This means that every frame must belong to a VLAN on a trunk. With that in mind, what is the only VLAN you know for sure is going to be on a switch? VLAN 1! This VLAN was/is created by default as all ports must belong to a VLAN by default. This is how control plane protocols got that special relationship to VLAN 1. As it was the only VLAN guaranteed to exist on the switch, control plane protocols were encapsulated in VLAN 1 using ISL. For reference, below is a STP (PVST) BPDU that has been encapsulated using ISL:

Frame 1: 90 bytes on wire (720 bits), 90 bytes captured (720 bits)
ISL
    Destination: 01:00:0c:00:00:07
    Source: 00:02:fd:2c:b8:97
    Length: 0
    DSAP: 0xaa
    SSAP: 0xaa
    Control: 0x03
    HSA: 0x000000
    0000 0000 0000 001. = VLAN ID: 1
    .... .... .... ...1 = BPDU/CDP/VTP: Yes
    Index: 0
    Reserved: 0x0000
IEEE 802.3 Ethernet 
    Destination: 01:80:c2:00:00:00
    Source: 00:02:fd:2c:b8:98
    Length: 38
    Trailer: 0000000000000000
    Frame check sequence: 0x9b790b66 [unverified]
    [FCS Status: Unverified]
Logical-Link Control
    DSAP: Spanning Tree BPDU (0x42)
    SSAP: Spanning Tree BPDU (0x42)
    Control field: U, func=UI (0x03)
Spanning Tree Protocol

It is clear that the VLAN ID is set to 1 and that the BPDU flag has been set.

For ISL, things were simple. Encapsulate the control plane protocols with VLAN ID of 1. Now, for 802.1Q it becomes a bit more complicated. Why?

As I described, 802.1Q does not encapsulate the frame. It adds a field/tag to the existing Ethernet header. This was done to be able to introduce 802.1Q into VLAN-unaware networks. This means that VLAN-unware switches can forward the frame even if they don’t understand 802.1Q. In addition, 802.1Q also supported untagged frames on trunk links to be backwards compatible with VLAN-unaware switches. I covered this in Why Do We Have Native VLANs? Every 802.1Q port has a Port VLAN ID (PVID). On a trunk link, this is the VLAN that untagged frames belong to. Native VLAN in Cisco speak.

Even after introducing 802.1Q, VLAN 1 is still the only VLAN to be guaranteed to be configured on the switch. It still makes sense to use VLAN 1 for control plane protocols. However, with ISL every frame was encapsulated. On a 802.1Q trunk on a Cisco switch, the PVID is by default set to 1, that is, the native VLAN is set to 1. What happens to frames in the native VLAN? They are untagged! This means that with the default configuration where all VLANs are allowed on the trunk, and the native VLAN is 1, frames such as CDP, DTP, STP are sent untagged (excluding PVST+/RPVST+ in non-native VLANs). Now here comes the interesting part. What do you do with these frames when the native VLAN is changed?

When the native VLAN is changed, the control plane protocols still are sent in VLAN 1, but now tagged. The exception is DTP which is untagged in almost every scenario. I cover this in my post Encapsulation of PDUs On Trunk Ports.

There is still one more thing to consider. What happens if VLAN 1/native VLAN is not allowed on the trunk? Initially, Cisco didn’t allow for VLAN 1 to be removed from a trunk. Then, what was called VLAN 1 minimization was introduced where this was possible. What’s interesting here is that you could have a port where you don’t allow user data in a VLAN over the trunk, but you obviously don’t want to blackhole the control plane protocols. How do you do that? Essentially you put the port as STP blocking/discarding which prevents user data from being forwarded. The control plane protocols are still allowed through other implementation specific logic.

With this we now understand that the Cisco control plane protocols do have a relationship to VLAN 1. What about the IEEE protocols such as LLDP and LACP? Generally, the IEEE protocols have no concept of a VLAN. They don’t belong to a VLAN where they are sent untagged in that VLAN, they are simply not VLAN-aware. LACP frames are always sent untagged, even when the native VLAN is tagged. In my tests for the Encapsulation of PDUs post, I did see LLDP tagged in one scenario, which is interesting, but the general principle is that IEEE frames are sent untagged (not belonging to a specific VLAN).

I hope this trip down memory lane gave you some insight into why VLAN 1 does have some special characteristics. There are a lot of myths around VLAN 1, I hope I have debunked most of them by now in my various posts.