Table of Contents
A trunk link is what lets a single physical connection between two switches carry traffic for dozens of VLANs simultaneously — but that convenience depends on both ends agreeing on encapsulation, native VLAN, and negotiation mode. Get any of those out of sync and you end up with a link that looks "up" but silently drops or misroutes traffic. This guide covers how trunking actually works at the frame level, how 802.1Q compares to its now-legacy predecessor, the exact diagnostic steps for the most common trunk failures, and a full command reference to keep on hand.
How Cisco Trunking Actually Works: 802.1Q, Tagging, and the Native VLAN
Before troubleshooting a trunk, it helps to understand exactly what's happening to a frame as it crosses one.
- Understand the problem trunking solves. A single access port can only belong to one VLAN, which would mean a dedicated physical link between switches for every VLAN in the network — trunking eliminates that by letting one link carry traffic for many VLANs at once.
- Learn how 802.1Q identifies which VLAN a frame belongs to. As a frame crosses a trunk link, the switch inserts a 4-byte 802.1Q tag into the Ethernet header, containing a 12-bit VLAN ID field that identifies which of up to 4094 VLANs the frame belongs to. The receiving switch reads this tag to determine forwarding behavior, then strips it before delivering the frame to an access port.
- Understand the native VLAN exception. Exactly one VLAN on a trunk — the native VLAn — is treated differently: frames belonging to it are sent untagged rather than carrying an 802.1Q header. This exists largely for backward compatibility with older equipment that doesn't understand 802.1Q tags at all.
- Recognize why native VLAN agreement matters so much. Because untagged frames are implicitly assumed to belong to whatever VLAN each switch considers native, if the two ends of a trunk disagree on which VLAN is native, untagged traffic can end up delivered into the wrong VLAN on one side — a subtle, often intermittent problem rather than an obvious link failure.
- Understand how Catalyst and Nexus platforms differ in defaults. Catalyst switches default the native VLAN to VLAN 1 unless explicitly changed, while Nexus platforms (running NX-OS) follow the same 802.1Q standard but are more commonly configured with an explicit, non-default native VLAN as a best practice from the outset — the underlying protocol behavior is identical across both platforms.
- Learn how trunks negotiate automatically via DTP. Dynamic Trunking Protocol (DTP) allows two connected Cisco switches to automatically negotiate whether a link should become a trunk, without both sides needing hard-coded configuration — though in practice, most production environments disable DTP negotiation in favor of explicit configuration for predictability and security.
- Understand allowed VLAN lists. By default, a trunk carries all VLANs, but administrators typically restrict this explicitly to only the VLANs actually needed across that link — both for security (limiting broadcast domain exposure) and to reduce unnecessary flooding.
With the tagging mechanism and native VLAN behavior clear, the next practical question is which encapsulation and negotiation settings to actually use — which is where 802.1Q's now-retired predecessor and DTP's negotiation modes come in.
802.1Q vs. ISL, and DTP Negotiation Modes Compared
Trunking encapsulation and negotiation behavior both come with real trade-offs worth understanding, even though one side of this comparison is now largely historical.
| Criteria | 802.1Q | ISL (Inter-Switch Link) |
|---|---|---|
| Standard type | IEEE open standard | Cisco-proprietary |
| Frame handling | Inserts a 4-byte tag into the existing Ethernet frame | Fully encapsulates the original frame inside a new ISL header and trailer, adding more overhead |
| Native VLAN concept | Yes — one VLAN carried untagged | No — ISL tags every VLAN, no native VLAN concept |
| Multi-vendor interoperability | Yes — works with any 802.1Q-compliant switch | No — requires Cisco equipment on both ends |
| Current status | Universal standard; the only encapsulation used in any current deployment | Deprecated — not supported on modern Cisco platforms |
| Overhead | Lower — smaller tag insertion | Higher — full frame encapsulation |
| Criteria | DTP Desirable | DTP Auto | Trunk (nonegotiate) |
|---|---|---|---|
| Negotiation behavior | Actively initiates trunk negotiation with the connected switch | Passively waits and will only form a trunk if the other side initiates | No negotiation — trunk is hard-set regardless of the other side |
| Forms a trunk if both sides set to Auto? | No — two "auto" ports will never negotiate a trunk between them | No — same limitation applies symmetrically | N/A — bypasses DTP negotiation entirely |
| Security consideration | Leaves the port open to potential VLAN hopping via DTP spoofing if untrusted devices connect | Same DTP exposure as desirable, though passive | Recommended for production — eliminates DTP as an attack surface entirely |
| Typical use case | Rare in production; sometimes used temporarily during initial buildout | Rare in production for the same reason | Standard best practice for known, permanent trunk links |
The practical takeaway on both fronts: 802.1Q isn't really a choice anymore — ISL is retired hardware history at this point — and while DTP can auto-negotiate a trunk, most production environments explicitly hard-set trunk mode with nonegotiate on both ends rather than relying on DTP at all, precisely because of the VLAN-hopping security exposure DTP negotiation introduces.
Troubleshooting Trunk Failures: Native VLAN Mismatches, Pruning, and DTP
When a trunk link is up but VLANs aren't passing traffic correctly — or won't form a trunk at all — work through this sequence.
- Confirm the link is physically up and stable first. Trunk-specific troubleshooting only makes sense once basic Layer 1 connectivity (no errors, no flapping) is confirmed.
switch# show interfaces gigabitEthernet 1/0/48
- Check whether the trunk actually formed. If DTP negotiation failed, the port may still be in access mode despite configuration intent — this is the first thing to rule out before looking at VLAN-specific issues.
switch# show interfaces gigabitEthernet 1/0/48 switchport
- Check for a native VLAN mismatch. This is one of the most common real-world trunk issues — Cisco switches log an explicit console warning when they detect mismatched native VLANs on a trunk, so check logs as well as live configuration on both ends.
switch# show interfaces gigabitEthernet 1/0/48 trunk
Compare the "Native vlan" line reported on both ends of the link directly against each other — a mismatch here explains symptoms like devices in the native VLAN being unable to reach each other despite the trunk otherwise working.
- Check the allowed VLAN list on both ends. A VLAN missing from the allowed list on just one side of the trunk will silently fail to pass traffic for that VLAN, without necessarily generating an alert.
switch# show interfaces trunk
Look specifically at the "VLANs allowed on trunk" output and compare it against what you expect on both switches.
- Check for VTP pruning if a VLAN that should be allowed still isn't passing traffic. Even when a VLAN is in the allowed list, VTP pruning can remove it from a trunk dynamically if the switch believes no downstream device needs it — this can cause confusing, seemingly-inconsistent behavior.
switch# show interfaces trunk
(Same command — check the separate "VLANs allowed and active in management domain" and "VLANs in spanning tree forwarding state" columns, since pruning shows up as a discrepancy between allowed and active VLANs.)
- Diagnose a DTP negotiation failure. If a link that should be a trunk keeps coming up as access mode, confirm both sides aren't both set to
auto(which never negotiates a trunk) — and remember that mismatched DTP modes, or one side usingnonegotiate, can also prevent negotiation depending on the exact combination.
switch# show dtp interface gigabitEthernet 1/0/48
- Resolve by hard-setting both ends explicitly rather than continuing to rely on negotiation. Once you've diagnosed a DTP-related failure, the most reliable fix — and standard best practice regardless — is to explicitly configure trunk mode with
nonegotiateon both switches rather than troubleshooting negotiation state repeatedly.
switch(config-if)# switchport mode trunk
switch(config-if)# switchport nonegotiate
- Re-verify all trunk parameters after any change. After correcting a native VLAN, allowed VLAN list, or DTP mode, re-run the verification commands above on both ends to confirm agreement — don't assume a one-sided fix resolved the issue.
Working through link status, trunk formation, native VLAN agreement, allowed VLAN lists, pruning, and DTP state in that order will resolve the large majority of real-world trunk issues without needing to fall back on removing and rebuilding the configuration from scratch.
Cisco Trunk Configuration and Troubleshooting Command Cheat Sheet
For quick reference during deployment or troubleshooting, here's a consolidated command set covering configuration, DTP, and verification.
# --- Basic trunk configuration ---
switch(config-if)# switchport trunk encapsulation dot1q # Required on platforms supporting multiple encapsulations
switch(config-if)# switchport mode trunk # Set port to trunk mode
switch(config-if)# switchport trunk native vlan 99 # Set native VLAN explicitly
switch(config-if)# switchport trunk allowed vlan 10,20,30 # Restrict to specific VLANs
switch(config-if)# switchport trunk allowed vlan add 40 # Add a VLAN to existing allowed list
switch(config-if)# switchport trunk allowed vlan remove 20 # Remove a VLAN from allowed list
# --- DTP control ---
switch(config-if)# switchport mode dynamic desirable # Actively negotiate trunk
switch(config-if)# switchport mode dynamic auto # Passively negotiate trunk
switch(config-if)# switchport nonegotiate # Disable DTP negotiation (recommended for production)
# --- Verification ---
switch# show interfaces trunk # Trunk state, native VLAN, allowed/active VLANs
switch# show interfaces gigabitEthernet 1/0/48 switchport # Detailed switchport/trunk status for one interface
switch# show interfaces gigabitEthernet 1/0/48 trunk # Trunk-specific detail for one interface
switch# show dtp interface gigabitEthernet 1/0/48 # DTP negotiation state for one interface
switch# show interfaces gigabitEthernet 1/0/48 # Physical/Layer 1 status and error counters
# --- VTP pruning (if used) ---
switch(config)# vtp pruning # Enable VTP pruning domain-wide
switch# show interfaces gigabitEthernet 1/0/48 pruning # View pruning-eligible VLANs on a trunk
Keep this reference alongside the troubleshooting sequence above — show interfaces trunk in particular answers the majority of trunk questions (native VLAN, allowed VLANs, active VLANs) in a single command.
