Recognizing an Active STP Loop
An STP loop is catastrophic. Traffic that should be blocked by spanning tree floods every link on the network simultaneously. Frames multiply exponentially as they traverse identical paths in both directions. The result is a broadcast storm that consumes all available bandwidth and CPU, rendering the network unusable in seconds.
Understanding how to recognize a loop in real time, diagnose the underlying cause, and apply containment is a critical skill for any network engineer.
Symptom Set 1: Network-Wide Indicators of a Loop
Symptom: Sudden Spike in CPU and Memory on All Switches
When a loop forms, all switches begin forwarding frames that should have been dropped. Control plane CPUs max out processing flooded traffic.
Observable behavior:
show processes cpushows CPU at 99–100% for extended periods- Interfaces are consistently in "up/up" state with high bit rates
- SSH/Telnet becomes unresponsive or times out frequently
Example output during a loop:
SW1# show processes cpu
CPU utilization for five seconds: 98%; one minute: 92%; five minutes: 88%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Task
1 3210 456 7040 0.00% 0.00% 0.00% 0 init
2 234510 5678923 41280 2.34% 2.10% 2.05% 0 CiscoSpan Tree
3 876543 23456789 37300 38.50% 35.20% 32.10% 0 IP IO
The CiscoSpan Tree process and IP IO are consuming disproportionate resources, indicating rapid BPDU processing and frame forwarding at scale.
Symptom: MAC Address Table Flapping
The MAC address table becomes unstable as frames arrive on different ports within milliseconds. A single source MAC appears on multiple ports almost simultaneously.
Example of flapping observed in real time:
SW1# show mac address-table dynamic vlan 10 | include 0001.0001.0001
VLAN 10: 0001.0001.0001 Gi0/0 (Age: 0 sec)
<Wait 1 second>
SW1# show mac address-table dynamic vlan 10 | include 0001.0001.0001
VLAN 10: 0001.0001.0001 Gi0/2 (Age: 0 sec)
<Wait 1 second>
SW1# show mac address-table dynamic vlan 10 | include 0001.0001.0001
VLAN 10: 0001.0001.0001 Gi0/1 (Age: 0 sec)
The age is always 0 seconds because the MAC is being "learned" multiple times per second on different ports. This indicates the device is reachable from multiple directions—a classic loop symptom.
Syslog will reflect this:
*Mar 25 14:32:10.456: %SW_MATM-4-MACFLAP_NOTIF: Host 0001.0001.0001 in vlan 10 is flapping between port Gi0/0 and Gi0/2
*Mar 25 14:32:11.123: %SW_MATM-4-MACFLAP_NOTIF: Host 0001.0001.0001 in vlan 10 is flapping between port Gi0/1 and Gi0/0
Symptom: Exponential Growth in Interface Counters
Every interface forwarding traffic related to the loop shows rapidly increasing byte and frame counts.
Check immediately during suspected loop:
SW1# show interfaces | include "input rate|output rate"
5 minute input rate 482934821 bits/sec, 45234 packets/sec
5 minute output rate 876234871 bits/sec, 89234 packets/sec
5 minute input rate 623948234 bits/sec, 67345 packets/sec
5 minute output rate 723847203 bits/sec, 71234 packets/sec
Normal trunk interfaces see rates of 10–1000 Mbps. Rates exceeding 500 Mbps sustained (on non-backbone links) indicate looped traffic.
Check specific interfaces:
SW1# show interfaces Gi0/0
...
5 minute input rate 873456234 bits/sec, 89234 packets/sec
5 minute output rate 923456873 bits/sec, 92348 packets/sec
Received: 12394872394 bytes, 5423876 packets, 3423 broadcasts, 0 runts
Dropped: 5634 packets
Transmit: 23487629384 bytes, 8934872 packets, 2384 broadcasts
5-minute input rate shows 834 Mbps!
Step 1: Verify STP Status During a Loop
Before assuming a loop, verify that STP is actually running and hasn't been disabled.
Check STP is Enabled
SW1# show spanning-tree summary
Switch is in rapid-pvst mode
Root bridge for: (unknown - possibly none)
If no VLANs list root bridge, STP may be disabled or broken. Verify:
SW1# show spanning-tree
VLAN0001
Spanning tree disabled
VLAN0010
Spanning tree enabled protocol rstp
Root ID Priority 32768
Address 0023.47a1.ef80
Bridge ID Priority 32768 (priority 32768 sys-id-ext 10)
Address 0023.47a1.ef80
Interface Role PortPri.Nbr Status Cost PortCost Vlans
-------------- ---- ----------- ------ ----------- -------- ------
Po1 Root P2Se.1 FWD 19000 19000 10
Gi0/2 Desg P2Se.2 FWD 4 4 10
STP is enabled for VLAN 10. Check all VLANs. If any VLAN shows all ports in "FWD" (forwarding), investigate further.
Check Port States
During normal operation, per VLAN, you should see:
- One root port (closest to root bridge)
- Designated ports (normally forwarding on the path to non-root switches)
- Blocked or alternative ports (on non-designated segments)
If you see multiple "FWD" ports on a single VLAN that shouldn't both be forwarding, a loop likely exists.
Step 2: Identify the Loop Path Using show commands
Find Which Ports Are Forwarding
SW1# show spanning-tree vlan 10 | include FWD
Po1 Root P2Se.1 FWD 19000 19000 10
Gi0/2 Desg P2Se.2 FWD 4 4 10
SW2# show spanning-tree vlan 10 | include FWD
Po1 Root P2Se.1 FWD 19000 19000 10
SW3# show spanning-tree vlan 10 | include FWD
Gi0/0 Desg P2Se.1 FWD 4 4 10
Gi0/1 Desg P2Se.2 FWD 4 4 10
Critical observation: SW3 has TWO designated ports in FWD state. Both Gi0/0 and Gi0/1 are forwarding. Normally, a non-root switch should have one root port and one or more designated ports. If two ports are forwarding on the same VLAN toward the same root, frames can loop between them.
Check MAC Address Flapping
During the loop, observe one data stream source:
SW1# show mac address-table dynamic vlan 10 | include 0001.0001.0001
VLAN 10: 0001.0001.0001 Po1 (Age: 0 sec)
<Wait 2 seconds>
SW1# show mac address-table dynamic vlan 10 | include 0001.0001.0001
VLAN 10: 0001.0001.0001 Gi0/2 (Age: 0 sec)
The MAC is learning on different ports. Check all switches:
SW2# show mac address-table dynamic vlan 10 | include 0001.0001.0001
VLAN 10: 0001.0001.0001 Po1 (Age: 0 sec)
SW3# show mac address-table dynamic vlan 10 | include 0001.0001.0001
VLAN 10: 0001.0001.0001 Gi0/1 (Age: 0 sec)
The source 0001.0001.0001 is arriving on SW1's Po1 from SW2's Po1, and also arriving on SW3's Gi0/1. Two paths exist for the same source. This indicates a topology where frames can take multiple paths—a loop.
Capture Loop Path
Based on the above output, the loop is:
0001.0001.0001 (at SW2 Gi0/x)
↓
SW2-Po1 ──→ SW1-Po1 (learns on Po1)
↓
SW1-Gi0/2 ──→ SW3-Gi0/0 (redundant path)
↓
SW3-Gi0/1 ──→ SW2-Po1 (back to SW2, frame loops again)
This is a triangular topology with all three inter-switch links forwarding. STP should have blocked one of them (typically SW3-Gi0/1 or SW3-Gi0/0).
Step 3: Diagnose Root Cause
Root Cause 1: STP Not Running or Disabled on One Switch
SW3# show spanning-tree
VLAN0010
Spanning tree disabled
Why it happened:
- Administrator disabled STP on SW3 by mistake
- SW3 was isolated for maintenance and not re-enabled
- Configuration copy from another switch overwrote STP settings
Fix:
SW3(config)# spanning-tree mode rapid-pvst
Verify:
SW3# show spanning-tree vlan 10
VLAN0010
Spanning tree enabled protocol rstp
Root Cause 2: Bridge Priority Misconfiguration Creating Wrong Root
SW1# show spanning-tree vlan 10
Root ID Priority 4096
Address 0023.47a1.ef80
Bridge ID Priority 4096
Address 0023.47a1.ef80
SW3# show spanning-tree vlan 10
Root ID Priority 4096
Address 0023.47a1.ef80
Bridge ID Priority 4096
Address 0023.47a1.ef80
SW1 and SW3 report the same root with the same bridge ID. This is impossible unless SW3 is claiming to be SW1 (bridge spoof) or the MAC addresses are somehow identical (corruption). More likely: SW3 was accidentally set to the same priority as the root, creating instability.
Fix:
SW3(config)# spanning-tree vlan 10 priority 8192
Verify the root is a single switch:
SW3# show spanning-tree vlan 10 | include "Root ID"
Root ID Priority 4096
Address 0023.47a1.ef80
SW1# show spanning-tree vlan 10 | include "Root ID"
Root ID Priority 4096
Address 0023.47a1.ef80
Only SW1 should report itself as the root. SW3 should show SW1's MAC in its Root ID.
Root Cause 3: BPDU Guard or Root Guard Blocking Legitimate BPDUs
If a critical interface has BPDU Guard or Root Guard enabled, it might reject BPDUs and go errdisable, taking the blocked port offline. This makes STP unable to maintain the topology.
SW1# show interfaces status err-disabled
Port Name Status Reason
Po1 err-disabled bpduguard
Why it happened:
- BPDU Guard was accidentally applied to a trunk interface (it's for access ports only)
- Root Guard was applied to a backup root interface when it shouldn't be
Fix:
SW1(config)# interface Po1
SW1(config-if)# no spanning-tree bpduguard enable
SW1(config-if)# no spanning-tree rootguard enable
SW1(config-if)# exit
SW1(config)# errdisable recovery cause bpduguard
SW1(config)# exit
SW1# clear errdisable interface Po1
Verify the port comes back up:
SW1# show interfaces Po1 status
Port Name Status Vlan
Po1 connected trunk
Root Cause 4: Port-Channel Misconfiguration
Member links of a port-channel might not all bundle, leaving some ports to forward independently:
SW1# show etherchannel 1 summary
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
1 Po1(SU) - Gi0/0(P) Gi0/1(P)
SW3# show etherchannel 1 summary
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
1 Po1(SU) - Gi0/0(P) Gi0/1(D)
SW3 has Gi0/1 in "D" (Down/Suspended). It's not bundled. STP treats Gi0/1 as a separate interface, and if all other links are blocked, Gi0/1 might forward, creating a loop path.
Fix:
SW3(config)# interface Gi0/1
SW3(config-if)# show run
speed 100
duplex half
channel-group 1 mode on
Mismatch! Gi0/1 is set to 100 Mbps, while Gi0/0 is auto (1000 Mbps). Fix:
SW3(config)# interface Gi0/1
SW3(config-if)# speed auto
SW3(config-if)# duplex auto
Verify bundling:
SW3# show etherchannel 1 summary
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
1 Po1(SU) - Gi0/0(P) Gi0/1(P)
Step 4: Immediate Mitigation with Storm Control
While you're diagnosing and fixing the root cause, use storm-control to limit broadcast flooding and keep the network stable.
Enable Storm Control on All Interfaces
SW1(config)# interface range Gi0/0-3,Po1
SW1(config-if-range)# storm-control broadcast level 5
SW1(config-if-range)# storm-control multicast level 10
SW1(config-if-range)# storm-control unknown-unicast level 10
SW1(config-if-range)# exit
These settings limit:
- Broadcast: 5% of port bandwidth
- Multicast: 10% of port bandwidth
- Unknown Unicast: 10% of port bandwidth (traffic destined to unknown MACs)
Action on threshold breach:
SW1(config)# interface range Gi0/0-3,Po1
SW1(config-if-range)# storm-control action shutdown
SW1(config-if-range)# exit
When threshold is exceeded, the interface goes errdisable. Set auto-recovery:
SW1(config)# errdisable recovery cause storm-control
SW1(config)# errdisable recovery interval 300
Interfaces will auto-recover after 300 seconds.
Verify Storm Control is Working
SW1# show storm-control
Interface Filter State Broadcast Multicast Unicast
----------- ----------- --------- --------- -------
Gi0/0 Forwarding 0 pps 0 pps 0 pps
Gi0/1 Forwarding 234 pps 5 pps 12 pps
Po1 Threshold 5432 pps 1234 pps 890 pps
Po1 is at threshold. If it continues to exceed limits, it will go errdisable.
Root Cause Analysis Checklist
Use this systematic approach to isolate the loop:
- Verify STP is running:
show spanning-tree - Check all port states: Confirm no unexpected forwarding ports
- Identify the loop path: Use
show mac address-tableto see where frames are arriving - Check bridge priorities: Ensure unique root election
- Verify BPDU Guard/Root Guard: Confirm no errdisable ports
- Inspect port-channels: Ensure all members are bundled
- Test with a single source: Generate traffic from a known device and track where it arrives
- Review recent changes: What was modified in the last 30 minutes?
Verification After Fix
After addressing the root cause, verify the network has converged:
SW1# show spanning-tree summary
Switch is in rapid-pvst mode
Root bridge for: VLAN0010, VLAN0020, VLAN0030
SW1# show spanning-tree vlan 10
VLAN0010
Root ID Priority 4096
Address 0023.47a1.ef80
This bridge is the root
Interface Role PortPri.Nbr Status Cost PortCost Vlans
-------------- ---- ----------- ------ ----------- -------- ------
Po1 Desg P2Se.128 FWD 19000 19000 10
Gi0/2 Desg P2Se.129 FWD 4 4 10
Check MAC address stability:
SW1# show mac address-table dynamic vlan 10 | include 0001.0001.0001
VLAN 10: 0001.0001.0001 Gi0/2 (Age: 10 sec)
<Wait 30 seconds>
SW1# show mac address-table dynamic vlan 10 | include 0001.0001.0001
VLAN 10: 0001.0001.0001 Gi0/2 (Age: 40 sec)
Age is increasing, and the port remains constant. The loop is healed.
Troubleshooting Symptom → Cause → Fix
Symptom: Network Floods Immediately After Configuration Change
Cause: A spanning tree setting was modified (priority, cost, or root change) without proper testing. STP reconverged but miscalculated the topology, leading to a loop.
Fix:
- Immediately revert the recent change:
SW1(config)# spanning-tree vlan 10 priority 32768 SW1(config)# exit - Verify the network stabilizes:
show spanning-tree vlan 10 show mac address-table dynamic - Incrementally re-apply changes with testing between each step.
Symptom: CPU Spikes Only on Specific Switch, Not Network-Wide
Cause: That switch is the source of the loop traffic (e.g., a device sending uncontrolled broadcast frames), or STP on that switch is generating excessive BPDUs.
Fix:
- Check interfaces for errors:
show interfaces | include errors - Identify the source of broadcasts:
debug spanning-tree events - If a specific interface is causing BPDUs, apply BPDU Guard:
interface Gi0/0 spanning-tree bpduguard enable
Symptom: Interface Enters Errdisable Due to Storm Control but Network Still Floods
Cause: Storm control kicked in too late, or the threshold is set too high. Or multiple loops exist, and blocking one path doesn't stop others.
Fix:
- Lower the storm control threshold:
interface range Gi0/0-3,Po1 no storm-control broadcast level 5 storm-control broadcast level 2 - Check for additional loops by examining all VLANs:
show spanning-tree | include FWD - If multiple VLANs show unexpected forwarding ports, address each separately.
What's Next
In the next article, we'll focus on root bridge issues. You'll learn how to identify an unexpected root, understand why a new switch can hijack the root election, detect TCN storms, and use debug commands to watch topology changes in real time.