Understanding STP Guard Features and Errdisable
STP guard features are protective mechanisms that disable ports when topology violations are detected. The goal is correct: prevent unauthorized switches from entering the network, or block links that could create loops. However, misconfigured guards on legitimate ports cause errdisable states that cut traffic off immediately.
Errdisable is a port shutdown triggered by a hardware or software error. Once a port enters errdisable, it stays disabled until manually recovered or auto-recovery is configured. Understanding which guard triggered the error and why is essential for quick diagnosis and fix.
The Three STP Guards
Guard 1: BPDU Guard
Purpose: Prevent a user device (or rogue switch) from sending BPDUs on an access port where BPDUs should never arrive.
How it works:
- Enable BPDU Guard on an access port
- If the port receives a BPDU, it immediately goes errdisable
- No questions asked—the port is disabled to protect the topology
Use case: Ports connected to user devices, printers, IP phones.
Misconfiguration: Applying BPDU Guard to a trunk interface or a port where a switch should connect.
Guard 2: Root Guard
Purpose: Prevent an inferior switch from becoming the root bridge by blocking reception of superior BPDUs on designated ports.
How it works:
- Enable Root Guard on a designated port (e.g., link to a backup switch)
- If a superior BPDU arrives (indicating a switch with a lower bridge ID is trying to be root), the port goes errdisable
- This prevents an unexpected switch from hijacking the root role
Use case: Links where a specific topology hierarchy is critical and unexpected root elections would break it.
Misconfiguration: Applying Root Guard to the root bridge's own ports, or to a port where a better switch should be root.
Guard 3: Loop Guard
Purpose: Detect unidirectional link failures and prevent loops caused by a port with no incoming BPDUs from becoming designated.
How it works:
- Enable Loop Guard on a port
- The port monitors for incoming BPDUs from the upstream switch
- If BPDUs stop arriving (but the link is still up), the port suspects a unidirectional link failure
- The port is disabled to prevent a loop
Use case: Point-to-point links where a unidirectional failure could be dangerous (fiber links, dedicated trunk lines).
Misconfiguration: Applying Loop Guard to shared media (hubs), or to ports that legitimately have no incoming BPDUs.
Identifying Errdisable Ports
Quick Check: Show Interfaces Status
SW1# show interfaces status err-disabled
Port Name Status Reason
-----------+-------------------+-----------+--------------------
Gi0/0 err-disabled bpduguard
Gi1/0 err-disabled rootguard
Gi2/0 err-disabled loopback
Three ports are errdisable. Gi0/0 due to BPDU Guard, Gi1/0 due to Root Guard, Gi2/0 due to loopback detection (hardware error).
Detailed Interface Status
SW1# show interfaces Gi0/0 status
Port Name Status Vlan
Gi0/0 err-disabled routed
SW1# show interfaces Gi0/0
...
Encapsulation ARPA, loopback not set
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue (0/40), (0/1000)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts (0 multicast)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output hang timeouts
The interface is administratively down (errdisable). No statistics because the port is disabled.
Guard 1: BPDU Guard Errdisable
Scenario 1: BPDU Guard on Access Port (Correct Use)
A user device is connected to Gi0/0 with BPDU Guard enabled:
SW1(config)# interface Gi0/0
SW1(config-if)# switchport mode access
SW1(config-if)# switchport access vlan 10
SW1(config-if)# spanning-tree portfast
SW1(config-if)# spanning-tree bpduguard enable
SW1(config-if)# exit
A misconfigured switch is accidentally connected to Gi0/0. It sends BPDUs:
*Mar 25 14:35:10.234: %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Gi0/0 with BPDU Guard enabled. Disabling port.
*Mar 25 14:35:10.345: %LINK-3-UPDOWN: Interface Gi0/0, changed state to down
The port is immediately errdisable. This is correct behavior. The port protected the topology by blocking the rogue switch.
Scenario 2: BPDU Guard on Trunk (Wrong Use, Common Mistake)
A trunk interface Po1 connects two core switches. Someone enables BPDU Guard by mistake:
SW1(config)# interface Po1
SW1(config-if)# switchport mode trunk
SW1(config-if)# spanning-tree bpduguard enable
SW1(config-if)# exit
The trunk immediately receives BPDUs from SW2 (normal). BPDU Guard triggers:
*Mar 25 14:36:45.123: %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Po1 with BPDU Guard enabled. Disabling port.
*Mar 25 14:36:45.234: %LINK-3-UPDOWN: Interface Po1, changed state to down
*Mar 25 14:36:45.345: %LINK-5-CHANGED: Interface Port-channel1, changed state to down
The trunk is disabled, severing the connection between SW1 and SW2. The network segments immediately.
Fix:
SW1(config)# interface Po1
SW1(config-if)# no spanning-tree bpduguard enable
SW1(config-if)# exit
Then manually recover:
SW1# clear errdisable interface Po1
Or wait for auto-recovery (if configured):
SW1# show errdisable recovery
ErrDisable Recovery Timer [errdisable recovery cause bpduguard]: 300 seconds
The port will recover after 300 seconds.
Guard 2: Root Guard Errdisable
Scenario 1: Root Guard on Backup Root Link (Correct Use)
SW1 is the root. SW2 is a backup core. A trunk Po1 connects them. Root Guard on SW2 prevents a new switch from becoming root:
SW2(config)# interface Po1
SW2(config-if)# switchport mode trunk
SW2(config-if)# spanning-tree guard root
SW2(config-if)# exit
A new Catalyst 9300 (SW4) is accidentally connected with default priority (lower than current root). Its BPDUs arrive at SW2 claiming to be the new root:
*Mar 25 14:40:10.234: %SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard is enabled on port Po1.
*Mar 25 14:40:10.345: %SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port Po1 on VLAN0010.
SW2's Po1 goes errdisable. This is correct. Root Guard protected the topology by preventing the inferior switch from becoming root.
Scenario 2: Root Guard on Root Bridge's Own Port (Wrong Use)
Someone applies Root Guard to a port on the root bridge itself:
SW1(config)# interface Po1
SW1(config-if)# spanning-tree guard root
SW1(config-if)# exit
SW1 is the root and sends BPDUs claiming to be the root. On the local port Po1, Root Guard sees this BPDU and interprets it as: "A more superior root (itself!) is claiming to be better than us." This is a paradox. The port immediately goes errdisable:
*Mar 25 14:41:50.123: %SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port Po1 on VLAN0010.
SW1's critical trunk is down.
Fix:
Remove Root Guard from the root bridge:
SW1(config)# interface Po1
SW1(config-if)# no spanning-tree guard root
SW1(config-if)# exit
SW1# clear errdisable interface Po1
Rule: Never apply Root Guard to the root bridge's own ports.
Scenario 3: Root Guard When Better Switch Should Be Root
SW1 is currently root with priority 4096. A new core switch SW5 joins with better hardware and lower priority 2048. Its superior BPDUs arrive at SW1. But Root Guard is enabled on SW1:
SW1(config)# interface Po1
SW1(config-if)# spanning-tree guard root
SW1(config-if)# exit
Root Guard blocks SW5's BPDUs, preventing the election:
*Mar 25 14:43:20.345: %SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port Po1 on VLAN0010.
SW1 remains root, but the topology is artificially locked in place. This violates the intent of allowing better switches to become root.
Fix:
Remove Root Guard and allow the election:
SW1(config)# interface Po1
SW1(config-if)# no spanning-tree guard root
Then manually adjust priorities if SW5 shouldn't be root after all:
SW5(config)# spanning-tree vlan 10 priority 8192
Guard 3: Loop Guard Errdisable
Scenario 1: Loop Guard on Unidirectional Link (Correct Use)
Two core switches are connected via a fiber link with redundancy. Loop Guard is enabled on both ends:
SW1(config)# interface Po1
SW1(config-if)# spanning-tree guard loop
SW1(config-if)# exit
SW2(config)# interface Po1
SW2(config-if)# spanning-tree guard loop
SW2(config-if)# exit
The fiber link from SW1 to SW2 is working, but the return path from SW2 to SW1 fails (unidirectional). SW1 stops receiving BPDUs from SW2, but the link is still up:
*Mar 25 14:45:30.123: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port Po1 on VLAN0010.
SW1's Po1 goes errdisable because Loop Guard suspects a unidirectional failure. This is correct. The port is disabled to prevent a loop where SW2 might promote its blocked ports to forwarding, creating a loop back through SW1.
Scenario 2: Loop Guard on Shared Media (Wrong Use)
A hub (shared Ethernet segment) connects multiple switches. Loop Guard is enabled on the interface:
SW1(config)# interface Gi1/0
SW1(config-if)# spanning-tree guard loop
SW1(config-if)# exit
On a hub, BPDUs from all connected switches arrive on all other switches' ports simultaneously. Due to the shared nature, there may be moments when BPDUs are delayed or missing from some sources due to congestion. Loop Guard interprets the absence of BPDUs from one source as a unidirectional failure and errdisables the port:
*Mar 25 14:47:15.234: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port Gi1/0 on VLAN0010.
The port is incorrectly disabled because the hub is legitimate shared media, not a unidirectional failure.
Fix:
Remove Loop Guard from shared media:
SW1(config)# interface Gi1/0
SW1(config-if)# no spanning-tree guard loop
Loop Guard should only be used on point-to-point links (port-channels, dedicated fiber trunks, not hubs or repeaters).
Viewing and Understanding Errdisable Causes
Show All Errdisable Reasons
SW1# show errdisable recovery
ErrDisable Recovery Timer [bpduguard]: 300 seconds
ErrDisable Recovery Timer [rootguard]: 300 seconds
ErrDisable Recovery Timer [loopguard]: 300 seconds
ErrDisable Recovery Timer [pagp-flap]: 300 seconds
ErrDisable Recovery Timer [dtp-flap]: 300 seconds
ErrDisable Recovery Timer [link-flap]: 300 seconds
ErrDisable Recovery Timer [gbic-invalid]: 300 seconds
ErrDisable Recovery Timer [bad-pagp]: 300 seconds
ErrDisable Recovery Timer [bad-lacp]: 300 seconds
ErrDisable Recovery Timer [bad-sfp-checksum]: 300 seconds
ErrDisable Recovery Timer [psecure-violation]: 300 seconds
ErrDisable Recovery Timer [loopback]: 300 seconds
ErrDisable Recovery Timer [storm-control]: 300 seconds
ErrDisable Recovery Timer [mlacp-minlink]: 300 seconds
ErrDisable Recovery Timer [mac-limit]: 300 seconds
ErrDisable Recovery Timer [udld]: 300 seconds
ErrDisable Recovery Timer [evc-lite channel-misconfig]: 300 seconds
ErrDisable Recovery Timer [dot1x-security]: 300 seconds
ErrDisable Recovery Timer [psp]: 300 seconds
ErrDisable Recovery Timer [sp-stp-misconfig]: 300 seconds
All recovery timers are set to 300 seconds (5 minutes). This means any port errdisabled for these reasons will automatically recover after 5 minutes of being in errdisable state.
Identify All Currently Errdisabled Ports
SW1# show interfaces status err-disabled
Port Name Status Reason
-----------+-------------------+-----------+--------------------
Gi0/0 err-disabled bpduguard
Gi0/1 err-disabled loopguard
Po1 err-disabled rootguard
Three ports. One per guard type. Check each reason in syslog:
SW1# show log | include "err-disabled|Root guard|BPDU Guard|Loop guard"
*Mar 25 14:35:10.345: %LINK-3-UPDOWN: Interface Gi0/0, changed state to down
*Mar 25 14:35:10.234: %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Gi0/0 with BPDU Guard enabled. Disabling port.
*Mar 25 14:45:30.123: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port Gi0/1 on VLAN0010.
*Mar 25 14:40:10.345: %SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port Po1 on VLAN0010.
Syslog Messages to Watch For
BPDU Guard Message
%SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Gi0/0 with BPDU Guard enabled. Disabling port.
What to do:
- Verify Gi0/0 is an access port where BPDUs should never arrive
- Check what's connected: Is it a user device or a switch?
- If it should be a switch, remove BPDU Guard
- If it should be a user device but a switch was connected, investigate why
Root Guard Message
%SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port Po1 on VLAN0010.
What to do:
- Verify Root Guard is intentionally enabled on Po1
- Check the remote switch's priority
- If the remote switch should be root, remove Root Guard or lower its priority
- If it shouldn't be root, the blocking is correct—check why a superior BPDU arrived
Loop Guard Message
%SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port Po1 on VLAN0010.
What to do:
- Verify Po1 is a point-to-point link (not shared media)
- Check if the remote switch is sending BPDUs
- If BPDUs are missing, investigate unidirectional link failure (check hardware/fiber)
- If BPDUs are present, investigate why they're not being received
Manual Port Recovery
Recover a Single Port
SW1# clear errdisable interface Gi0/0
Gi0/0 transitions to up/up. If the original error condition still exists (e.g., a rogue switch is still sending BPDUs), the port will immediately errdisable again.
Recover All Errdisabled Ports
SW1# clear errdisable interface all
Use with caution. This brings up all errdisabled ports simultaneously, which can shock the network if the root causes aren't fixed.
Configuring Automatic Recovery
Auto-recovery prevents manual intervention. Ports will errdisable, then automatically recover after a timeout.
Enable Auto-Recovery for Specific Causes
SW1(config)# errdisable recovery cause bpduguard
SW1(config)# errdisable recovery cause rootguard
SW1(config)# errdisable recovery cause loopguard
SW1(config)# errdisable recovery interval 300
The interval can be between 30 and 86400 seconds. 300 seconds (5 minutes) is common.
Verify Recovery Configuration
SW1# show errdisable recovery
ErrDisable Recovery Timer [bpduguard]: 300 seconds
ErrDisable Recovery Timer [rootguard]: 300 seconds
ErrDisable Recovery Timer [loopguard]: 300 seconds
Disable Auto-Recovery
If you want to require manual intervention:
SW1(config)# no errdisable recovery cause bpduguard
This port will remain errdisable indefinitely until manually cleared.
Troubleshooting Symptom → Cause → Fix
Symptom: Critical Trunk Port Errdisabled for BPDU Guard
Cause: Someone enabled BPDU Guard on a trunk or switch port where it doesn't belong.
Fix:
- Remove BPDU Guard:
SW1(config)# interface Po1 SW1(config-if)# no spanning-tree bpduguard enable - Recover the port:
SW1# clear errdisable interface Po1 - Verify the port is up:
SW1# show interfaces Po1 status
Symptom: Port Keeps Errdisabling Due to Loop Guard, But It's a Point-to-Point Link
Cause: The remote switch is not sending BPDUs (or they're being lost), triggering Loop Guard repeatedly.
Fix:
- Verify the remote switch is operational:
SW2# show spanning-tree | include "This bridge is the root" - Check BPDU transmission on the remote interface:
SW2# debug spanning-tree events - If BPDUs are not being sent, restart spanning tree on the remote switch:
SW2(config)# no spanning-tree vlan 10 SW2(config)# spanning-tree vlan 10 - If Link Layer issues exist, check cable/optics and replace if necessary.
Symptom: Root Guard Continuously Errdisables, Preventing a More Superior Switch from Being Root
Cause: Root Guard is too restrictive and preventing intended root changes.
Fix:
- Remove Root Guard:
SW1(config)# interface Po1 SW1(config-if)# no spanning-tree guard root - Allow the new root election by adjusting priorities appropriately:
SW1(config)# spanning-tree vlan 10 priority 8192 SW5(config)# spanning-tree vlan 10 priority 4096
Production Deployment Checklist
- BPDU Guard: Enable only on access ports where user devices connect
- Root Guard: Enable on backup root links, not on the root itself
- Loop Guard: Enable only on point-to-point trunks (port-channels), never on hubs or access networks
- Auto-Recovery: Always configure for STP guards to allow self-healing in case of transient issues
- Monitoring: Watch syslog for errdisable messages and investigate root causes immediately
What's Next
In the final troubleshooting article, we'll address convergence problems. You'll learn why 802.1D failover takes 50 seconds, how to diagnose slow convergence using timer values and port states, the legacy features (UplinkFast, BackboneFast), and the migration path to Rapid PVST+ for sub-second convergence.