> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # Troubleshooting Errdisable and STP Guard Features - URL: https://www.pinglabz.com/troubleshoot-errdisable-stp-guard/ - Published: 2026-03-27T05:16:13.000Z - Updated: 2026-08-24T17:12:34.000Z - Description: STP guard features protect your network topology, but misconfigured guards cause legitimate ports to shut down. This article covers all three guards (BPDU Guard, Root Guard, Loop Guard), how to identify which one triggered, interpret syslog messages, and implement proper auto-recovery. - Author: Jaime - Tags: STP, #Import 2026-08-01 19:54 ## 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**. New to STP? Start with the [full spanning-tree guide](https://www.pinglabz.com/spanning-tree-protocol/), then come back here for the deep dive. 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. ## First, the correction that changes everything below Only one of the three STP guards puts a port into err-disable. BPDU Guard does. Root Guard and Loop Guard do not: they put the port into a spanning-tree inconsistent state (root-inconsistent and loop-inconsistent respectively), which blocks the port for the affected VLANs but leaves it up, and which clears itself automatically the moment the triggering condition stops. That difference decides which commands you use to diagnose and recover, so it is worth proving rather than asserting. The err-disable subsystem itself tells you. Ask a Catalyst which causes it can recover from and neither guard is in the list: ``` SW1# show errdisable recovery ErrDisable Reason Timer Status bpduguard Disabled link-flap Disabled psecure-violation Disabled udld Disabled ``` And the config parser refuses the two commands you would need if Root Guard and Loop Guard really did err-disable a port: ``` SW1(config)# errdisable recovery cause rootguard ^ % Invalid input detected at '^' marker. SW1(config)# errdisable recovery cause loopguard ^ % Invalid input detected at '^' marker. SW1(config)# errdisable recovery cause bpduguard SW1(config)# ``` Captured on an IOS XE 17.18.2 Catalyst in the PingLabz lab. bpduguard is accepted; the other two do not exist as err-disable causes because those guards never trigger err-disable. So the recovery model splits in two: - BPDU Guard: the port goes err-disable (down/down). It stays down until you clear it manually with clear errdisable interface, bounce it with shutdown / no shutdown, or configure errdisable recovery cause bpduguard. - Root Guard: the port goes root-inconsistent and blocks for the affected VLANs. You do not clear it. When the superior BPDUs stop arriving, the port returns to forwarding on its own. - Loop Guard: the port goes loop-inconsistent and blocks. Same deal: when BPDUs are received again, the port recovers by itself. The command that finds both inconsistent states is not an err-disable command at all: ``` SW1# show spanning-tree inconsistentports Name Interface Inconsistency -------------------- ------------------------------ ------------------ Number of inconsistent ports (segments) in the system : 0 ``` Zero here because nothing is currently violating. When Root Guard fires you get a row reading Root Inconsistent, and when Loop Guard fires, Loop Inconsistent. Confirm which guard is armed on a port with the interface detail view: ``` SW1# show spanning-tree interface Ethernet0/0 detail | include guard Root guard is enabled on the port SW1# show spanning-tree interface Ethernet0/1 detail | include guard Loop guard is enabled on the port ``` Keep that split in mind for the scenarios that follow: where the text below says a Root Guard or Loop Guard violation err-disables a port, the real behavior is the inconsistent state described here, and the recovery is automatic rather than a clear errdisable command. ## 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:** 1. Enable BPDU Guard on an access port 2. If the port receives a BPDU, it immediately goes errdisable 3. 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:** 1. Enable Root Guard on a designated port (e.g., link to a backup switch) 2. If a superior BPDU arrives (indicating a switch with a lower bridge ID is trying to be root), the port goes root-inconsistent and blocks 3. 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:** 1. Enable Loop Guard on a port 2. The port monitors for incoming BPDUs from the upstream switch 3. If BPDUs stop arriving (but the link is still up), the port suspects a unidirectional link failure 4. 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 psecure-violation Gi2/0 err-disabled link-flap ``` Three ports are err-disabled: Gi0/0 by BPDU Guard, Gi1/0 by a port-security violation, Gi2/0 by link-flap. Note what is not here. A Root Guard or Loop Guard violation never shows up in this output, because neither one err-disables a port. ### 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 [bpduguard]: 300 seconds ``` The port will recover after 300 seconds. ## Guard 2: Root Guard and the Root-Inconsistent State ### 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 root-inconsistent and stops forwarding for the affected VLANs. This is correct: Root Guard protected the topology by refusing to let the new switch take the root role. You will find it with show spanning-tree inconsistentports, not in show interfaces status err-disabled, and it clears itself once SW4's superior BPDUs stop. ### 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. Root Guard on that port has nothing superior to reject from its own switch, so in practice this misconfiguration does not instantly break the link the way BPDU Guard on a trunk does. What it does is arm the port to block any legitimate future root election through it, which is the real damage: ``` *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 ``` **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 and the Loop-Inconsistent State ### 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 loop-inconsistent and stops forwarding 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 as a unidirectional failure and puts the port into the loop-inconsistent state: ``` *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 Reason Timer Status bpduguard Enabled link-flap Disabled psecure-violation Disabled udld Disabled ``` The bpduguard recovery timer is set to 300 seconds (5 minutes), so a port err-disabled by BPDU Guard comes back automatically after five minutes. Root Guard and Loop Guard need no entry here because their inconsistent states clear on their own. ### Identify All Currently Errdisabled Ports ``` SW1# show interfaces status err-disabled Port Name Status Reason -----------+-------------------+-----------+-------------------- Gi0/0 err-disabled bpduguard SW1# show spanning-tree inconsistentports Name Interface Inconsistency -------------------- ------------------------------ ------------------ VLAN0010 Port-Channel1 Root Inconsistent VLAN0010 GigabitEthernet0/1 Loop Inconsistent Number of inconsistent ports (segments) in the system : 2 ``` Three ports, all from genuine err-disable causes. 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:** 1. Verify Gi0/0 is an access port where BPDUs should never arrive 2. Check what's connected: Is it a user device or a switch? 3. If it should be a switch, remove BPDU Guard 4. 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:** 1. Verify Root Guard is intentionally enabled on Po1 2. Check the remote switch's priority 3. If the remote switch should be root, remove Root Guard or lower its priority 4. 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:** 1. Verify Po1 is a point-to-point link (not shared media) 2. Check if the remote switch is sending BPDUs 3. If BPDUs are missing, investigate unidirectional link failure (check hardware/fiber) 4. 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 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 Reason Timer Status bpduguard Enabled Timer interval: 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. Everything above stays inside the three STP guards, but err-disable itself is far wider: port security, UDLD, storm control, link-flap and a couple of dozen more causes can put a port in the identical state. [The full cause list and how the recovery timer actually behaves](https://www.pinglabz.com/errdisable-recovery-cisco/) is where that taxonomy and the recovery mechanism live. ## 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:** Verify the port is up: ``` SW1# show interfaces Po1 status ``` Recover the port: ``` SW1# clear errdisable interface Po1 ``` Remove BPDU Guard: ``` SW1(config)# interface Po1 SW1(config-if)# no spanning-tree bpduguard enable ``` ### Symptom: Port Keeps Going Loop-Inconsistent, But It Is a Point-to-Point Link **Cause:** The remote switch is not sending BPDUs (or they're being lost), triggering Loop Guard repeatedly. **Fix:** 1. If Link Layer issues exist, check cable/optics and replace if necessary. 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 ``` Check BPDU transmission on the remote interface: ``` SW2# debug spanning-tree events ``` Verify the remote switch is operational: ``` SW2# show spanning-tree | include "This bridge is the root" ``` ### Symptom: Root Guard Keeps Blocking, Preventing a More Superior Switch from Being Root **Cause:** Root Guard is too restrictive and preventing intended root changes. **Fix:** 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 ``` Remove Root Guard: ``` SW1(config)# interface Po1 SW1(config-if)# no spanning-tree guard root ``` ## 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: configure errdisable recovery cause bpduguard so BPDU Guard self-heals; Root Guard and Loop Guard need no recovery config because their inconsistent states clear on their own**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. ## Related STP Articles - [BPDU Guard Configuration: Protecting Your STP Topology](https://www.pinglabz.com/bpdu-guard-configuration-cisco/) - [Root Guard and Loop Guard: STP Stability Features Explained and Configured](https://www.pinglabz.com/root-guard-loop-guard-cisco-configuration/) - [Troubleshooting STP Loops and Broadcast Storms on Cisco Switches](https://www.pinglabz.com/troubleshoot-stp-loops-broadcast-storms/) - [STP Toolkit Reference: Every show and debug Command You Need](https://www.pinglabz.com/stp-show-debug-commands-reference/) ### References - [IEEE 802.1D - MAC Bridges (incorporates RSTP)](https://standards.ieee.org/ieee/802.1D/3387/?ref=pinglabz.com) - [Cisco Spanning Tree Protocol technology documentation](https://www.cisco.com/c/en/us/tech/lan-switching/spanning-tree-protocol/index.html?ref=pinglabz.com) Build this yourself, on real gear The PingLabz lab library: 74 hands-on labs on real Cisco IOS XE in Cisco Modeling Labs. Seven are free, no card required. [Browse the labs](https://www.pinglabz.com/labs/)