Imagine a network where a single broadcast frame multiplies infinitely, saturating links and bringing down an entire campus in seconds. That is a spanning-tree loop, and it is the most destructive failure mode in switched Ethernet. On the CCNA 200-301 exam (objective 2.5), you must be able to diagnose and resolve these loops quickly. This chapter gives you the systematic troubleshooting methodology that separates a seasoned engineer from a panicked administrator.
Jump to a section
Picture a busy four-way intersection where every driver ignores yield signs and traffic lights. Cars enter from all directions simultaneously, creating a gridlock that spreads to adjacent streets. In a switched network, a loop acts like this intersection: a broadcast frame enters the loop and is forwarded by every switch in every direction, creating an exponential storm of copies. The switches' CPUs become overwhelmed processing endless frames, much like police officers at the intersection trying to direct an infinite stream of cars. Eventually, the network becomes unusable — switches drop legitimate traffic because their buffers overflow, and end devices time out. Spanning Tree Protocol (STP) is the traffic cop that blocks one of the roads, ensuring only one active path between any two points. When STP fails (due to misconfiguration, hardware fault, or software bug), the loop reappears. The engineer's job is to find which switch or port is malfunctioning and restore the logical block. This is not a theoretical problem — I have seen a single misconfigured PortFast port bring down a 500-switch campus in under 30 seconds.
What Is a Spanning Tree Loop?
A spanning tree loop occurs when a switched Ethernet network has multiple active Layer 2 paths between devices, violating the fundamental rule that switched networks must have a single logical path. Without STP, broadcast frames (e.g., ARP requests) are forwarded out all ports except the receiving port. If two switches are connected by two links, a broadcast frame from one switch is sent to the other, which then sends it back on the other link, creating an infinite loop. The frame count grows exponentially (broadcast storm), and switch CPUs become saturated processing the flood. Unicast frames with unknown MAC addresses also flood, amplifying the storm. Even without a broadcast, a unicast frame can loop indefinitely if the MAC table is unstable.
How STP Prevents Loops
STP (IEEE 802.1D) elects a root bridge and places redundant ports into a blocking state to create a loop-free tree topology. The algorithm uses Bridge Protocol Data Units (BPDUs) exchanged every 2 seconds (Hello time). Each switch selects one root port (best path to root) and each segment has one designated port. All other ports become alternate (blocked). The blocking port does not forward data frames but continues to receive BPDUs to remain aware of topology changes.
Default Timers and States
Hello Timer: 2 seconds (default)
Forward Delay: 15 seconds (default) – time spent in listening and learning states each
Max Age: 20 seconds (default) – time a switch waits before re-electing root if BPDUs stop
Port states: Blocking (20 sec max age) → Listening (15 sec) → Learning (15 sec) → Forwarding. Total convergence: 30-50 seconds.
Causes of STP Loops
Unidirectional link failure: A fiber break or faulty transceiver causes one direction of a link to fail while the other direction still works. The switch on the receiving end thinks the link is up but stops receiving BPDUs, eventually transitioning a blocking port to forwarding and creating a loop.
PortFast misconfiguration: PortFast is meant for end-device ports only. If enabled on a switch-to-switch link, the port skips STP states and goes immediately to forwarding, potentially creating a temporary loop if another switch is connected.
BPDU filter/guard misconfiguration: BPDU Guard shuts down a port if it receives a BPDU, preventing loops. If disabled or misconfigured, a rogue switch can be connected and cause a loop.
Software bugs or hardware faults: Rare but possible.
Verifying and Troubleshooting with IOS CLI
Use the following commands to detect and isolate loops:
show spanning-tree
show spanning-tree vlan 1
show interfaces status err-disabled
show logging | include STP|SPANTREE
show processes cpu | include STP
show interface <interface> | include input errors|output errors|CRCExample output for show spanning-tree vlan 1:
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 0011.2233.4455
This bridge is the root
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 0011.2233.4455
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi0/1 Desg FWD 4 128.1 P2p
Gi0/2 Desg FWD 4 128.2 P2p
Gi0/3 Altn BLK 4 128.3 P2pLook for ports in unexpected states (e.g., a port that should be blocking is forwarding). Also check for high CPU usage on the switch, which indicates a broadcast storm.
Interaction with Related Protocols
Rapid PVST+ (Cisco default): Per-VLAN RSTP, faster convergence (around 6 seconds). Uses proposal/agreement handshake. Troubleshooting is similar but states are discarding, learning, forwarding.
MST (Multiple Spanning Tree): Groups VLANs into instances, reducing BPDU overhead. Loops can occur within an instance if mapping is inconsistent.
UDLD (Unidirectional Link Detection): Detects unidirectional links and shuts them down, preventing loops. Should be enabled on fiber links.
Loopguard: Prevents alternate ports from transitioning to forwarding if BPDUs stop (e.g., due to unidirectional link).
BPDU Guard/Filter: Security features to prevent unauthorized switches from connecting.
Step-by-Step Loop Detection
Identify the symptoms: high CPU on switches, network slow or down, end devices losing connectivity, switch logs showing MAC flapping.
Check for high CPU with show processes cpu | include STP. If STP process is high, a loop is likely.
Look for MAC address flapping: show mac address-table | include <MAC> shows the same MAC appearing on multiple ports.
Use show spanning-tree to find ports in unexpected forwarding state.
Check for err-disabled ports: show interfaces status | include err-disabled – these may be caused by BPDU Guard shutting down a looped port.
Disable suspect ports manually to confirm loop resolves: interface gi0/1, shutdown. If network recovers, that port is part of the loop.
Enable UDLD and Loopguard to prevent future loops.
Identify Loop Symptoms
Begin by collecting evidence: users report slow or no connectivity, switches show high CPU utilization, and log messages indicate MAC address flapping (same MAC learned on multiple ports). Use `show processes cpu | include STP` to confirm the STP process is consuming excessive CPU. Also run `show interface summary` to see if traffic counters are incrementing abnormally fast. A broadcast storm will cause input and output rates to spike on all interfaces. Do not assume a loop yet — high CPU could also be due to a routing protocol issue or a denial-of-service attack, but in a pure Layer 2 environment, a loop is the prime suspect.
Check Spanning-Tree State
Run `show spanning-tree vlan <vlan-id>` on each switch in the path. Look for ports that are in the Forwarding state but should be Blocking (Alternate). For example, in a triangle topology, only one of the three links should be blocking; if two are blocking or all are forwarding, something is wrong. Also verify the root bridge: if a low-end switch is elected root, it may be overwhelmed and cause instability. Use `show spanning-tree root` to see the root for each VLAN. If the root is not the expected core switch, check bridge priorities.
Examine Interface Errors
Run `show interface <interface>` and look for CRC errors, runts, giants, and input errors. These often spike during a loop due to collisions and frame corruption. A unidirectional link may show no errors on one side but high errors on the other. Use `show interface <interface> | include errors` to get a quick summary. If errors are high, suspect a physical layer issue that could cause STP to fail (e.g., a fiber break that prevents BPDU receipt but keeps the link up).
Check for BPDU Guard Violations
Use `show interfaces status | include err-disabled` to see if any ports have been error-disabled by BPDU Guard. If a port is err-disabled due to BPDU Guard, it means a switch was connected to a PortFast-enabled port (intended for end devices). That switch may have caused a loop before BPDU Guard shut it down. Re-enable the port with `errdisable recovery cause bpduguard` or manually with `shutdown` / `no shutdown` after fixing the configuration.
Isolate the Loop by Shutting Down Ports
If the loop is active and you cannot quickly identify the culprit, start shutting down redundant links one by one. Begin with the least critical links (e.g., access layer uplinks). After each shutdown, check if the network recovers (CPU drops, connectivity returns). Use `shutdown` on the suspect interface, then `no shutdown` after recovery to restore it. Document which port caused the loop. This method is crude but effective in an emergency. For exam purposes, you will not have to do this live, but you should know the logic.
Implement Permanent Fix
Once the loop is isolated, determine the root cause. If it was a unidirectional link, replace the faulty cable or transceiver and enable UDLD globally (`udld enable`). If it was a PortFast misconfiguration, remove PortFast from switch-to-switch links (`no spanning-tree portfast`). If it was a BPDU Guard issue, ensure BPDU Guard is enabled on all access ports (`spanning-tree portfast bpduguard default`). Verify the fix by checking `show spanning-tree` to confirm the correct port is blocking. Then monitor CPU and logs for stability.
In a large enterprise campus network, spanning-tree loops are rare but catastrophic. One of the most common real-world scenarios is a unidirectional fiber link. I once worked on a network where a new fiber patch panel was installed, and one strand of a duplex fiber pair was broken. The switch at one end saw the link up (because the transmit side worked) but never received BPDUs from the other end. After 20 seconds (Max Age), the blocking port transitioned to forwarding, creating a loop that saturated the core uplinks. The fix was to enable UDLD globally, which detects such failures in under 3 seconds and err-disables the port. Another scenario: a junior administrator connected a new switch to an access port that had PortFast and BPDU Guard disabled. The new switch had a lower bridge priority, became root, and its redundant uplinks created a loop. The symptom was intermittent connectivity across the entire building. The fix was to enable BPDU Guard on all access ports and use Root Guard on distribution switches to prevent unauthorized root bridges. Performance considerations: STP convergence time (30-50 seconds) is unacceptable for modern networks, so Rapid PVST+ or MST is used. In data centers, you might even use fabric technologies like VPC or stacking to eliminate loops altogether. Misconfiguration of these features (e.g., inconsistent MST region names) can itself cause loops. Always test changes in a lab first.
The CCNA 200-301 exam tests your ability to troubleshoot spanning-tree loops in objective 2.5 (Troubleshoot Layer 2 issues). Expect scenario-based questions where you are given symptoms (high CPU, MAC flapping, connectivity loss) and must choose the correct cause or fix. The most common wrong answers are:
"The switch has a routing loop" — Routing loops are Layer 3 (TTL expiry, routing table instability). STP loops are Layer 2 (no TTL, broadcast storms). Candidates confuse them because both cause high CPU.
"Enable PortFast on all ports to speed up convergence" — PortFast is for end devices only. Enabling it on switch links can cause loops. The correct fix is to enable Rapid PVST+ or use PortFast only on access ports.
"The problem is a duplex mismatch" — While duplex mismatch causes CRC errors and poor performance, it does not directly cause a spanning-tree loop. A loop requires two active paths. Duplex mismatch is a separate issue.
"Increase the Max Age timer to prevent loops" — Increasing Max Age makes convergence slower, not faster. It does not prevent loops; it only delays the transition to forwarding. The correct approach is to use UDLD or Loopguard.
Specific values to memorize: Hello=2s, Forward Delay=15s, Max Age=20s. For RSTP, convergence is about 6 seconds (3x Hello). Know that show spanning-tree output shows Role (Root, Desg, Altn) and State (FWD, BLK). A port in Altn BLK is correct; a port in Desg BLK or Altn FWD indicates a problem.
Decision rule: If symptoms include broadcast storm (high CPU, traffic counters increasing on all ports), suspect a Layer 2 loop. Use show spanning-tree to find a port that should be blocking but is forwarding. Then check for unidirectional link (use UDLD) or configuration error (PortFast on trunk).
A spanning-tree loop occurs when there are multiple active Layer 2 paths and STP fails to block the redundant path.
Default STP timers: Hello=2s, Forward Delay=15s, Max Age=20s.
Symptoms of a loop: high CPU on switches, MAC flapping, broadcast storm, and connectivity loss.
Use 'show spanning-tree' to check port roles and states; a port in Altn FWD indicates a problem.
Unidirectional link failure is a common cause of STP loops; enable UDLD on fiber links.
PortFast should only be enabled on access ports (end devices); never on switch-to-switch links.
BPDU Guard err-disables a port if a BPDU is received, preventing loops from rogue switches.
These come up on the exam all the time. Here's how to tell them apart.
STP (802.1D)
Convergence time: 30-50 seconds (listening+learning+blocking)
Port states: Blocking, Listening, Learning, Forwarding, Disabled
Uses timer-based convergence (Forward Delay, Max Age)
No edge port concept; all ports go through STP states
BPDU version: 802.1D (Configuration BPDUs)
RSTP (802.1w)
Convergence time: ~6 seconds (proposal/agreement handshake)
Port states: Discarding, Learning, Forwarding (only three)
Uses handshake mechanism for rapid transition
Edge ports (PortFast) skip to forwarding immediately
BPDU version: 802.1w (RSTP BPDUs, more flags)
Mistake
A spanning-tree loop is the same as a routing loop.
Correct
A spanning-tree loop occurs at Layer 2 with no TTL, causing frames to loop indefinitely. A routing loop occurs at Layer 3 with TTL decrementing, eventually dropping packets. Both cause high CPU but have different fixes.
Candidates often conflate Layer 2 and Layer 3 loops because both involve redundant paths and high CPU.
Mistake
Enabling PortFast on all ports speeds up convergence and prevents loops.
Correct
PortFast bypasses STP states on access ports. If used on switch-to-switch links, it can cause loops. The correct way to speed convergence is to use Rapid PVST+ (RSTP).
PortFast sounds like a performance improvement, so candidates think it is always beneficial.
Mistake
A duplex mismatch causes a spanning-tree loop.
Correct
Duplex mismatch causes frame errors and poor performance but does not create a loop. A loop requires two active Layer 2 paths. Duplex mismatch is a separate issue.
Both can cause connectivity issues, so candidates incorrectly assume they are related.
Mistake
Increasing the Max Age timer prevents loops.
Correct
Max Age determines how long a switch waits before re-electing a root if BPDUs stop. Increasing it delays convergence, making loops more likely to persist. Loop prevention requires proper STP configuration, UDLD, or Loopguard.
Candidates think larger timers give more stability, but they actually slow down the detection of failures.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Symptoms include: high CPU usage on switches (especially the STP process), MAC address flapping (same MAC learned on multiple ports), broadcast storms (traffic counters increasing rapidly on all interfaces), and end devices losing connectivity. Use `show processes cpu | include STP` to see if STP is consuming CPU. Also check `show mac address-table | include <MAC>` for flapping. If you see a port in forwarding that should be blocking, that is a strong indicator.
A broadcast storm is a symptom of a spanning-tree loop. When a loop exists, broadcast frames (and unknown unicast frames) are forwarded repeatedly, multiplying exponentially. This causes a storm that saturates links and CPU. So the loop is the cause, the storm is the effect. You can have a broadcast storm without a loop (e.g., a malfunctioning NIC), but in switched networks, a loop is the most common cause.
Use STP (or RSTP) with proper configuration: ensure the root bridge is the core switch (set priority low, e.g., 0 or 4096). Enable BPDU Guard on all access ports to prevent rogue switches. Enable PortFast only on end-device ports. Enable UDLD on fiber links to detect unidirectional failures. Use Loopguard on all alternate ports to prevent them from transitioning to forwarding if BPDUs stop. Also, use Rapid PVST+ for faster convergence.
In a unidirectional link, one direction of communication fails (e.g., a broken fiber strand). The switch on the receiving end still sees the link as up (because its own transmit works), but it stops receiving BPDUs from the neighbor. After Max Age (20 seconds), the switch assumes the neighbor is gone and transitions its alternate port to forwarding. If the neighbor still thinks the link is up and is forwarding, a loop is created. UDLD detects this by sending probes and expecting acknowledgments.
BPDU Guard err-disables a port if a BPDU is received on a PortFast-enabled port. It is a security feature to prevent loops. BPDU Filter, on the other hand, prevents the switch from sending or receiving BPDUs on a port. It can be used on access ports to reduce BPDU traffic, but it can also cause loops if a switch is connected. Cisco recommends using BPDU Guard rather than BPDU Filter for security.
First, determine why a BPDU was received on that port. If a switch was accidentally connected, disconnect it or configure the port as a trunk. Then re-enable the port manually: `interface gi0/1`, `shutdown`, `no shutdown`. Alternatively, you can configure automatic recovery: `errdisable recovery cause bpduguard` and `errdisable recovery interval 300` (seconds). After recovery, verify the port is up and in the correct STP state.
MAC flapping occurs when a switch learns the same MAC address on different ports in rapid succession, indicating that frames from that device are arriving on multiple interfaces. This is a classic sign of a loop. Use `show mac address-table | include <MAC>` to see which ports the MAC is learned on. If it alternates between ports, you have flapping. Use `show mac address-table flapping` (if supported) to see which MACs are flapping and on which ports.
You've just covered Troubleshoot: Spanning Tree Loop — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?