Real networks are rarely built with a single switch. Even a small office typically has at least two or three switches connected together to extend port capacity, separate floors or departments, or provide redundant paths. The links between switches — called trunk links or interswitch links — are what allow multiple VLANs to travel across a shared physical connection between devices.
This article explains, from first principles, how interswitch connectivity works, focusing on 802.1Q trunking, native VLANs, and the practical configuration and verification steps needed to make multiple switches function as one cohesive Layer 2 network.
Why Interswitch Links Are Special
A normal access port carries traffic for exactly one VLAN. But if Switch A has VLAN 10 and VLAN 20 devices, and Switch B also has devices in VLAN 10 and VLAN 20, how do frames from VLAN 10 on Switch A reach VLAN 10 devices on Switch B, while staying completely separate from VLAN 20 traffic?
The answer is trunking. A trunk link carries traffic for multiple VLANs over a single physical (or logical, e.g., EtherChannel) connection, using a tagging mechanism so each switch on either end knows which VLAN each frame belongs to.
802.1Q: The Standard Trunking Protocol
IEEE 802.1Q is the open standard for VLAN tagging. It works by inserting a 4-byte tag into the Ethernet frame header, which includes:
- A Tag Protocol Identifier (TPID) — identifies this as an 802.1Q tagged frame (0x8100)
- A Priority Code Point (PCP) — used for QoS (802.1p)
- A Drop Eligible Indicator (DEI)
- A VLAN Identifier (VID) — a 12-bit field identifying the VLAN (1–4094)
graph LR
A["Original Ethernet Frame"] --> B["802.1Q Tag Inserted (4 bytes)"]
B --> C["Tagged Frame Sent Across Trunk"]
C --> D["Receiving Switch Reads VLAN ID, Strips Tag, Forwards to Correct VLAN"]The Native VLAN
802.1Q has one special behavior: traffic belonging to the native VLAN is sent untagged across the trunk by default. This was originally designed for backward compatibility with older equipment that didn’t understand tagging.
By default, the native VLAN is VLAN 1 on Cisco switches. This is actually a common security concern (see Best Practices below) — many organizations change the native VLAN to an unused VLAN number to avoid VLAN hopping attacks.
Critical rule: the native VLAN must match on both ends of a trunk link. If it doesn’t, you’ll get a native VLAN mismatch — Cisco switches will detect this and generate warnings, and traffic on the mismatched VLAN can leak between VLANs unexpectedly.
Trunk Negotiation: Dynamic Trunking Protocol (DTP)
Cisco switches can automatically negotiate whether a link should become a trunk, using DTP (Dynamic Trunking Protocol), a Cisco-proprietary protocol.
Switchport Modes
| Mode | Behavior |
|---|---|
access | Always an access port; never trunks |
trunk | Always a trunk; sends DTP frames advertising itself as a trunk |
dynamic auto | Will become a trunk ONLY if the other side actively wants to trunk |
dynamic desirable | Actively tries to negotiate a trunk with the other side |
| Side A | Side B | Result |
|---|---|---|
| trunk | trunk | ✅ Trunk |
| trunk | dynamic auto | ✅ Trunk |
| trunk | dynamic desirable | ✅ Trunk |
| dynamic desirable | dynamic desirable | ✅ Trunk |
| dynamic desirable | dynamic auto | ✅ Trunk |
| dynamic auto | dynamic auto | ❌ Stays access (neither side initiates) |
| access | trunk | ❌ Stays access (access mode disables DTP negotiation) |
Best practice: Most production environments disable DTP entirely and hard-code switchport mode trunk on both ends, using switchport nonegotiate to stop sending DTP frames altogether. This avoids relying on automatic negotiation, which introduces unpredictability and a minor security exposure (DTP can, in rare cases, be exploited to trick a port into becoming a trunk).
Step-by-Step Configuration: Building a Trunk Between Two Switches
Topology
graph LR
SW1["SW1"] ---|"Gi0/24 (trunk)"| SW2["SW2"]
SW1 --- PC1["VLAN 10 PC"]
SW1 --- PC2["VLAN 20 PC"]
SW2 --- PC3["VLAN 10 PC"]
SW2 --- PC4["VLAN 20 PC"]Step 1: Create VLANs on Both Switches
SW1(config)# vlan 10
SW1(config-vlan)# name SALES
SW1(config-vlan)# exit
SW1(config)# vlan 20
SW1(config-vlan)# name ENGINEERING
SW1(config-vlan)# exitRepeat identically on SW2.
Step 2: Configure the Trunk on SW1
SW1(config)# interface GigabitEthernet0/24
SW1(config-if)# switchport trunk encapsulation dot1q
SW1(config-if)# switchport mode trunk
SW1(config-if)# switchport trunk native vlan 999
SW1(config-if)# switchport trunk allowed vlan 10,20,999
SW1(config-if)# switchport nonegotiateNote: The switchport trunk encapsulation dot1q command only appears on switches that support multiple encapsulation types (like older switches supporting both ISL and 802.1Q). Newer platforms support only 802.1Q and skip this step entirely.
Step 3: Configure the Trunk on SW2 (Matching Configuration)
SW2(config)# interface GigabitEthernet0/24
SW2(config-if)# switchport trunk encapsulation dot1q
SW2(config-if)# switchport mode trunk
SW2(config-if)# switchport trunk native vlan 999
SW2(config-if)# switchport trunk allowed vlan 10,20,999
SW2(config-if)# switchport nonegotiateStep 4: Create VLAN 999 as an Unused Native VLAN (Security Best Practice)
SW1(config)# vlan 999
SW1(config-vlan)# name NATIVE-UNUSEDThis VLAN carries no real traffic — it exists only to safely absorb the untagged native VLAN traffic, without exposing VLAN 1 (the default and often-attacked native VLAN).
Verification Commands
show interfaces trunk
The single most important command for verifying trunk status.
SW1# show interfaces trunk
Port Mode Encapsulation Status Native vlan
Gi0/24 on 802.1q trunking 999
Port Vlans allowed on trunk
Gi0/24 10,20,999
Port Vlans allowed and active in management domain
Gi0/24 10,20,999
Port Vlans in spanning tree forwarding state and not pruned
Gi0/24 10,20,999This output tells you:
- Mode: whether it’s statically trunking (
on) or negotiated (desirable,auto) - Encapsulation: 802.1q (or ISL on legacy gear)
- Status:
trunkingconfirms it’s actually operational as a trunk, not just configured as one - Native VLAN: confirms both sides match
- Allowed VLANs: which VLANs are actually permitted across this trunk
show interfaces <interface> switchport
Gives a detailed per-interface view, useful when a trunk isn’t forming as expected:
SW1# show interfaces GigabitEthernet0/24 switchport
Name: Gi0/24
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: Off
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 999 (NATIVE-UNUSED)
Trunking VLANs Enabled: 10,20,999show vlan brief
Confirms which VLANs exist and which access ports (if any) are assigned to them. Trunk ports do not appear tied to a single VLAN in this view since they carry multiple.
SW1# show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active
10 SALES active Gi0/1, Gi0/2
20 ENGINEERING active Gi0/3, Gi0/4
999 NATIVE-UNUSED activeCommon Interswitch Problems
Native VLAN Mismatch
If SW1 has native VLAN 999 and SW2 still has native VLAN 1 configured, the switches will log a warning:
%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet0/24 (999), with SW2 GigabitEthernet0/24 (1).This is detected via CDP and is a serious issue — it can allow traffic from one VLAN to leak into another, effectively breaking VLAN segmentation.
Fix: Ensure switchport trunk native vlan matches exactly on both ends.
Allowed VLAN List Mismatch
If SW1 allows VLANs 10, 20, and 999, but SW2 only allows 10 and 999, VLAN 20 traffic will simply never cross the trunk — with no error message, just silent connectivity failure for that VLAN.
Fix: Compare show interfaces trunk output side by side on both switches; the “Vlans allowed on trunk” line must include every VLAN you expect to pass.
Trunk Not Forming (Stuck in Access Mode)
Cause: DTP negotiation failure — e.g., both sides set to dynamic auto.
Fix: Either hard-code both sides to trunk mode, or ensure at least one side is dynamic desirable.
Interswitch Connectivity Using EtherChannel
For added resilience, interswitch trunk links are frequently bundled into an EtherChannel (see the separate EtherChannel/LACP article), so multiple physical cables act as one trunk with combined bandwidth and automatic failover — all VLAN and trunk settings are then applied to the logical Port-channel interface rather than the individual physical ports.
Best Practices
- Never leave the native VLAN as VLAN 1. Change it to an unused VLAN ID to reduce the risk of VLAN hopping attacks.
- Disable DTP negotiation (
switchport nonegotiate) and hard-code trunk mode on both ends in production networks. - Explicitly prune unnecessary VLANs from trunk links using
switchport trunk allowed vlan— don’t allow all 4094 VLANs across every trunk by default; this reduces unnecessary broadcast traffic and improves security. - Keep VLAN naming and numbering consistent across all switches in the same broadcast domain to avoid confusion.
- Document your trunk links with interface descriptions (
description Trunk to SW2 Gi0/24) so the topology is clear from the configuration alone. - Verify both sides after every change — trunking issues are frequently caused by a mismatch that only becomes visible when comparing configurations on both switches together.
Troubleshooting Checklist
show interfaces trunkon both switches — confirm status istrunking, notnot-trunking.- Confirm native VLANs match on both sides.
- Confirm the allowed VLAN list includes every VLAN you expect to traverse the link.
- Check for DTP mismatches if the trunk refuses to form (
show interfaces switchport, look at Administrative vs. Operational Mode). - Verify physical layer health — a flapping or errored physical link can cause an unreliable trunk even with correct configuration (
show interfacescounters). - Use
show cdp/lldp neighbors detailto confirm you’re troubleshooting the correct physical link on the correct remote device.
Summary
Interswitch connectivity — built on 802.1Q trunking — is what allows multiple VLANs to share a single physical link between switches while remaining logically separate. Getting it right requires matching native VLANs, matching (or deliberately pruned) allowed VLAN lists, and either careful DTP negotiation or (preferably) hard-coded, non-negotiated trunk configuration on both ends. show interfaces trunk remains the fastest, most reliable command for confirming a trunk’s health at a glance.
