VLAN Trunking Explained: 802.1Q, Allowed Lists, and Trunk Negotiation

Learn why VLAN trunks exist, how 802.1Q tagging works, the difference between ISL and 802.1Q, and how allowed VLAN lists and trunk negotiation function in Cisco networks.

VLAN trunking is the mechanism that allows multiple VLANs to coexist on a single physical link between switches. Without trunking, each VLAN would require its own physical cable between switches, making large networks impossible to build. Understanding why trunks exist, how they work at the frame level, and how to control what VLANs traverse them is fundamental to designing scalable switched networks.

Why VLAN Trunks Exist

Consider a simple network with three switches and four VLANs:

• CORE-SW1 (central switch)
• ACC-SW1 and ACC-SW2 (access switches)
• VLANs 10, 20, 30, and 40 (Users, Servers, Management, Voice)

Without trunking, you would need a separate physical cable for each VLAN between CORE-SW1 and each access switch:

CORE-SW1 to ACC-SW1:
  - 1 cable for VLAN 10
  - 1 cable for VLAN 20
  - 1 cable for VLAN 30
  - 1 cable for VLAN 40
Total: 4 cables

CORE-SW1 to ACC-SW2:
  - 1 cable for VLAN 10
  - 1 cable for VLAN 20
  - 1 cable for VLAN 30
  - 1 cable for VLAN 40
Total: 4 cables

Grand Total: 8 physical cables for just 2 access switches

This approach is wasteful, expensive, and impractical for even moderately sized networks. VLAN trunking solves this by allowing multiple VLANs to share a single physical link, using a tagging mechanism to identify which VLAN each frame belongs to.

With trunking, the same network requires only one cable per switch-to-switch link:

CORE-SW1 to ACC-SW1: 1 trunk cable carrying VLANs 10, 20, 30, 40
CORE-SW1 to ACC-SW2: 1 trunk cable carrying VLANs 10, 20, 30, 40
Grand Total: 2 physical cables

Frame Tagging: How 802.1Q Works

When traffic for a specific VLAN needs to traverse a trunk, the switch adds a VLAN identifier to the Ethernet frame. The standard mechanism for this is the 802.1Q (Dot1Q) protocol, specified in IEEE 802.1Q.

802.1Q Frame Structure

An 802.1Q-tagged frame has a 4-byte VLAN tag inserted between the source MAC address and the EtherType field:

Untagged Frame:
Destination MAC | Source MAC | EtherType | Payload | FCS
(6 bytes)       | (6 bytes)  | (2 bytes) |         |

802.1Q Tagged Frame:
Destination MAC | Source MAC | 802.1Q Tag | EtherType | Payload | FCS
(6 bytes)       | (6 bytes)  | (4 bytes)  | (2 bytes) |         |

The 4-byte 802.1Q tag contains:

• TPID (Tag Protocol ID, 2 bytes): Always 0x8100, identifying this as a 802.1Q tag
• Priority Code Point (PCP, 3 bits): Quality of Service (QoS) priority (0-7)
• Canonical Format Indicator (CFI, 1 bit): Legacy field; almost always 0
• VLAN ID (VID, 12 bits): The actual VLAN number (0-4095)

Frame Size Impact

Adding the 4-byte tag increases the frame size from a maximum of 1518 bytes to 1522 bytes (called "jumbo" or "giant" frames). Most modern networks support this, but some legacy devices or network devices may have issues. This is why older network designs sometimes had jumbo frame issues when adding VLANs.

Native VLAN: The Exception

On a trunk, frames belonging to the native VLAN are transmitted untagged (without the 802.1Q tag). This is a historical design decision from when 802.1Q was new and many devices didn't support it. By leaving the native VLAN untagged, legacy devices could still communicate on that VLAN.

When a trunk receives an untagged frame, it assumes the frame belongs to the native VLAN:

Sender on VLAN 99 (native):
Frame sent untagged → Receiver assumes it belongs to VLAN 99

Sender on VLAN 10:
Frame sent tagged with VLAN 10 → Receiver reads the tag and assigns to VLAN 10

ISL vs. 802.1Q: Historical Context

Before 802.1Q became the industry standard, Cisco invented Inter-Switch Link (ISL), a proprietary tagging protocol. ISL added a 30-byte header to every frame and encapsulated the entire frame, making it much less efficient than 802.1Q. ISL is not supported on modern Catalyst 9000 series switches and should not be used in any new network design.

802.1Q advantages over ISL: - 4-byte tag vs. 30-byte encapsulation (much more efficient) - IEEE standard (vendor-agnostic) - Native VLAN support allows untagged frame handling - Supported across all modern vendors

If you encounter ISL in a lab or legacy network, understand it's a historical artifact. Always configure modern networks with 802.1Q.

Allowed VLAN Lists and Pruning

Not all VLANs need to traverse every trunk. A trunk from an access switch to a distribution switch might carry only VLANs used on that access switch. A trunk from a distribution switch to the core might carry many more VLANs. Allowed VLAN lists control which VLANs are allowed on a trunk.

How Allowed Lists Work

When a switch receives a frame for a VLAN on a trunk port, it checks the allowed VLAN list. If the VLAN is in the list, the frame is transmitted. If not, the frame is dropped (pruned):

Allowed VLANs on ACC-SW1 → DIST-SW1 trunk: 10, 20, 30, 40, 99

Frame for VLAN 10 arrives at ACC-SW1 → Lookup allowed list → Found → Transmit
Frame for VLAN 50 arrives at ACC-SW1 → Lookup allowed list → Not found → Drop (prune)

Active vs. Allowed

The terms "active" and "allowed" in trunk status displays have specific meanings:

ACC-SW1# show interfaces GigabitEthernet 1/0/23 trunk

Port        Vlans allowed on trunk
Gi1/0/23    10,20,30,40,50,99

Port        Vlans allowed and active in management domain
Gi1/0/23    10,20,30,40,50,99

Port        Vlans in spanning-tree forwarding state and not pruned
Gi1/0/23    10,20,30,40,50,99

• Allowed: VLANs explicitly permitted by switchport trunk allowed vlan
• Active: VLANs that both exist on the switch and are in the allowed list
• Forwarding state and not pruned: VLANs that are active and not blocked by Spanning Tree Protocol

Example: You create VLAN 200 but don't add it to the allowed list:

ACC-SW1(config)# vlan 200
ACC-SW1(config-vlan)# name New-VLAN

ACC-SW1# show interfaces GigabitEthernet 1/0/23 trunk

Port        Vlans allowed on trunk
Gi1/0/23    10,20,30,40,50,99

Port        Vlans allowed and active in management domain
Gi1/0/23    10,20,30,40,50,99,200

VLAN 200 is "active in management domain" (it exists), but not in the "allowed on trunk" list. Traffic for VLAN 200 will not cross this trunk.

Pruning for Efficiency

Pruning reduces bandwidth waste by preventing unnecessary VLAN traffic from crossing trunks. A well-designed trunk allowed list includes only VLANs that actually need to cross the link:

! ACC-SW1 serves only Users (VLAN 10) and Voice (VLAN 40)
! Only these VLANs need to cross the trunk to DIST-SW1

ACC-SW1(config)# interface GigabitEthernet 1/0/23
ACC-SW1(config-if)# switchport trunk allowed vlan 10,40,99
ACC-SW1(config-if)# end

! VLAN 20 (Servers) and 30 (Management) are not in the allowed list
! even if they exist on ACC-SW1. Their traffic is dropped.

However, pruning is a secondary benefit. The primary reason for allowed VLAN lists is operational clarity: anyone looking at the configuration can immediately see which VLANs are expected on a trunk.

Trunk Negotiation via Dynamic Trunking Protocol (DTP)

Cisco switches support a proprietary protocol called Dynamic Trunking Protocol (DTP) that negotiates whether a link should be a trunk or an access port. This negotiation is automatic unless explicitly disabled.

DTP Negotiation Outcomes

DTP operates in three modes per switch port:

1. switchport mode trunk: Always a trunk
2. switchport mode dynamic auto: Trunk if neighbor requests it
3. switchport mode dynamic desirable: Actively requests trunk

The final link state depends on both sides' modes:

Why DTP Creates Problems

Although DTP provides automatic negotiation, production networks universally disable it:

1. Security: An attacker who gains access to a port could configure it to dynamic desirable and negotiate a trunk, bypassing access port restrictions
2. Reliability: Misconfiguration on one switch cascades to the neighboring switch
3. Operational visibility: Explicitly configured modes are easier to audit and understand
4. Troubleshooting: A link is either trunk or access by design, not by negotiation outcome

Disabling DTP

Disable DTP by explicitly setting the switchport mode to static (access or trunk) and adding the switchport nonegotiate command:

ACC-SW1(config)# interface GigabitEthernet 1/0/23
ACC-SW1(config-if)# switchport mode trunk
ACC-SW1(config-if)# switchport nonegotiate
ACC-SW1(config-if)# end

! The port is now a static trunk; DTP negotiation is disabled
! If the remote port is also static, the link will function normally

Trunk Status: Reading the Output

The show interfaces trunk command provides detailed status. Understanding each line is important for troubleshooting:

ACC-SW1# show interfaces trunk

Port        Mode         Encapsulation  Status        Native vlan
Gi1/0/23    on           802.1q         trunking      99

Port        Vlans allowed on trunk
Gi1/0/23    10,20,30,40,50,99

Port        Vlans allowed and active in management domain
Gi1/0/23    10,20,30,40,50,99

Port        Vlans in spanning-tree forwarding state and not pruned
Gi1/0/23    10,20,30,40,50,99

• Mode on: The port is configured as a trunk (static or negotiated)
• Encapsulation 802.1q: Using 802.1Q tagging (ISL would show here if configured)
• Status trunking: The link is physically up and functioning as a trunk
• Native vlan 99: Untagged frames belong to VLAN 99
• Vlans allowed on trunk: Which VLANs are explicitly permitted
• Vlans allowed and active: Which allowed VLANs actually exist on the switch
• Vlans in spanning-tree forwarding state and not pruned: Which VLANs can actually forward traffic (not blocked by STP)

If "Status" shows "not-trunking," the link is either down, one side is in access mode, or a configuration mismatch exists.

Trunk Troubleshooting Framework

When a trunk doesn't work:

1. Check physical status: Is the link up? (show interfaces <port>)
2. Check mode: Is it configured as trunk? (show interfaces <port> switchport)
3. Check allowed VLANs: Is the VLAN in the allowed list? (show interfaces <port> trunk)
4. Check STP status: Is the VLAN blocked by STP? (show spanning-tree vlan <id>)
5. Check native VLAN: Do both sides match? (CDP error or show interfaces <port> trunk)
6. Check remote switch: Is the remote port also a trunk? (SSH to remote or use CDP)

Key Takeaways

• Trunks exist to carry multiple VLANs on a single physical link, eliminating the need for a separate cable per VLAN
• 802.1Q tagging adds a 4-byte header to frames to identify the VLAN; frames in the native VLAN are sent untagged
• Allowed VLAN lists prune unnecessary traffic and provide operational clarity; a VLAN in the "allowed" list but not in the "active" list cannot forward traffic
• DTP negotiation is automatic but should be disabled in production; always use static switchport mode trunk with switchport nonegotiate
• Native VLAN mismatch is detected by CDP and indicates a configuration error; ensure both trunk ends use the same native VLAN
• Verify trunk status with show interfaces trunk and show interfaces <port> trunk; understand the difference between "allowed," "active," and "forwarding" VLANs