DTP: The Trunk That Never Negotiated
Two switches, one cable, and no trunk, because both ends are waiting to be asked. Diagnose it from both sides and fix it live, right below.
Symptom
Two switches, one cable, and no trunk. Both ends are perfectly willing to trunk and neither one will ask. Read both sides of the link before you change anything.
Your mission
Prove the cause, then fix it
Format
Guided CLI investigation
Investigate before you configure.
Use the CLI evidence to isolate the fault, make the smallest safe correction, then verify the network state changed.
Observe the symptom and link state.
Diagnose by comparing the protocol evidence.
Verify the expected device state and confirm the original symptom is resolved.
Console access: SW1 · SW2
This workspace stacks for portrait phones. Rotate to landscape for the full split-screen console.
Need a hint?
Reveal the root cause when you're ready.
Try the investigation first, then use this as your escape hatch, not a dead end.
Lab debrief
Turn the session into a repeatable troubleshooting pattern.
Use this reference after your attempt: first explain the symptom, then verify the evidence, then confirm the repair.
The problem
SW1 and SW2 are cabled on GigabitEthernet0/1. Both switches have VLANs 10 and 20 defined, the interface is up on both ends, and no access VLAN was ever configured. Hosts in VLAN 10 on SW1 still cannot reach VLAN 10 on SW2, while a second link between the same two switches works normally.
What you'll practice
- Tell the difference between administrative mode and operational mode
- Recognise that a port can be up, error-free, and still not trunking
- Understand which DTP modes propose a trunk and which only accept one
- Diagnose a negotiated protocol by reading both ends, not one
- Set a trunk encapsulation before hardcoding trunk mode
The topology
Two switches joined by two links: one already hardcoded as an 802.1Q trunk, and one left to negotiate, which is the link under investigation.
Commands to run yourself
The real diagnostic commands for this lab, copy-paste ready. Run these in the same order to reproduce the investigation on your own session.
show interfaces trunkshow interfaces GigabitEthernet0/1 switchportshow interfaces statusTopology diagram
Frequently asked
Why does dynamic auto on both ends fail when the mode is called dynamic?
Dynamic auto will accept a trunk if the other end proposes one, but it never proposes on its own. With auto facing auto, both switches wait politely for an offer that never comes and the link falls back to being an access port in the default VLAN. Dynamic desirable is the mode that actively proposes, which is why auto facing desirable does form a trunk.
The port is up and there are no errors. Why is that not enough?
Layer 1 and Layer 2 are fine, which is exactly what makes this confusing. The link is passing traffic perfectly well for VLAN 1. What it is not doing is tagging frames, so every other VLAN is invisible across it. Only the operational mode line, or the absence of the port from show interfaces trunk, reveals that.
Why set the encapsulation before the mode?
On a switch that supports more than one trunk encapsulation, the encapsulation defaults to negotiate, and IOS refuses to hardcode trunk mode while it is still set that way. You get a command rejected message telling you the interface encapsulation is Auto. Setting dot1q first avoids it.
Ready to run this lab yourself?
No setup, no image sourcing. Book a session or ask for a live demo.