STP Root Guard: One VLAN Blocked on a Healthy Trunk
One VLAN stops crossing a trunk that is up, healthy, and carrying every other VLAN. Find out what spanning tree is protecting you from, live, right below.
Learn root election and port roles in the spanning tree lab guideSymptom
A trunk is up, the port is up, and every VLAN crosses it except one. Find the root-inconsistent port, work out what root guard is protecting you from, and fix the cause instead of silencing the alarm.
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
After a change window, hosts in VLAN 1 cannot reach anything across the trunk between SW1 and SW2. VLANs 10 and 20 on the same trunk are completely unaffected, the interface is up, and the trunk shows as trunking.
What you'll practice
- Recognise the root-inconsistent state from show spanning-tree inconsistentports
- Read BKN and ROOT_Inc in the spanning-tree port table
- Understand that root guard blocks per VLAN, not per port
- Explain why the trunk summary still looks healthy during the outage
- Repair the intended root election rather than removing the protection
The topology
Two switches joined by a single 802.1Q trunk carrying VLANs 1, 10, and 20, where the upstream switch has root guard applied to the port facing its neighbour.
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 spanning-tree inconsistentportsshow spanning-tree vlan 1show spanning-tree interface GigabitEthernet0/3 detailTopology diagram
Frequently asked
Why is only VLAN 1 affected when root guard is applied to the whole port?
Root guard is evaluated per VLAN, because spanning tree itself runs per VLAN. The neighbour was only given a superior priority for VLAN 1, so only VLAN 1's BPDU is better than the local one. Every other VLAN on that same physical port keeps forwarding normally, which is exactly why the trunk looks healthy while one VLAN is down.
Why not just remove root guard and move on?
Because that grants the neighbour the root role it was asking for. The alarm stops, the port forwards again, and the spanning-tree topology quietly reorganises around a switch nobody intended to be the root. Root guard was not the fault, it was the thing that noticed. The real repair is to restore the intended root bridge so the neighbour's advertisement is no longer superior.
Does the port recover on its own once the cause is fixed?
Yes. Root guard has no timer and no recovery command. The moment the superior BPDUs stop arriving, it unblocks the port itself and logs SPANTREE-2-ROOTGUARD_UNBLOCK. That is the difference between root guard and an err-disabled port, which does need manual intervention or errdisable recovery.
Ready to run this lab yourself?
No setup, no image sourcing. Book a session or ask for a live demo.