Understanding Root Bridge Election Failures
The root bridge is the topological center of spanning tree. All other switches calculate the shortest path to reach it. If the wrong switch becomes root, traffic takes inefficient paths, links that should carry traffic sit idle, and convergence times increase dramatically.
Root bridge elections fail for simple reasons: a new switch joins the network with a lower priority, or existing priorities aren't configured correctly. When this happens, all switches must recalculate their topology, triggering topology change notifications (TCNs) that flood the network and age out MAC addresses prematurely.
Lab Topology: Root Bridge Election
SW1 (Initially root, priority 32768 default)
├─ Po1 ── SW2 (priority 32768, backup root intended)
└─ Gi0/2 ── SW3 (priority 32768)
└─ Gi0/1 ── SW4 (NEW switch added, priority 32768 default)
When SW4 joins, all switches with default priority 32768 will cause an election. The switch with the lowest bridge ID (priority + MAC address) becomes root.
Identifying the Current Root Bridge
Quick Method: Show Spanning Tree
SW1# show spanning-tree vlan 10
VLAN0010
Spanning tree enabled protocol rspt
Root ID Priority 32768
Address aabb.cc00.0410
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32768 (priority 32768 sys-id-ext 10)
Address aabb.cc00.0410
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
The Root ID shows the MAC address aabb.cc00.0410. If "This bridge is the root" appears, the local switch is the root. Otherwise, the root is a remote switch.
Compare the root's MAC address:
SW1# show running-config | include version
Catalyst 9300 Software Version 17.6.3, RELEASE SOFTWARE (fc4)
SW1# show version | include System Serial
System Serial Number : JXXXXXXX
Now check other switches:
SW2# show spanning-tree vlan 10 | include Root
Root ID Priority 32768
Address aabb.cc00.0410
SW2# show version | include System Serial
System Serial Number : JYYYYYYY
SW4# show spanning-tree vlan 10 | include Root
Root ID Priority 32768
Address aabb.cc00.0410
All show the same root MAC. That's SW1's MAC, so SW1 is the root. But is this the intended switch?
Determining if the Root is "Wrong"
A root is "wrong" if it wasn't chosen intentionally or if a better switch should be root (e.g., a more powerful core switch with higher redundancy).
Check the topology logic:
SW1# show spanning-tree vlan 10
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
SW2# show spanning-tree vlan 10
Interface Role PortPri.Nbr Status Cost PortCost Vlans
-------------- ---- ----------- ------ ----------- -------- ------
Po1 Root P2Se.1 FWD 19000 19000 10
SW3# show spanning-tree vlan 10
Interface Role PortPri.Nbr Status Cost PortCost Vlans
-------------- ---- ----------- ------ ----------- -------- ------
Gi0/0 Root P2Se.1 FWD 4 4 10
Gi0/1 Altn P2Se.2 BLK 4 4 10
SW4# show spanning-tree vlan 10
Interface Role PortPri.Nbr Status Cost PortCost Vlans
-------------- ---- ----------- ------ ----------- -------- ------
Gi0/0 Root P2Se.1 FWD 4 4 10
Observation: All root ports point back to SW1. This is correct if SW1 is intended to be the core. But if SW1 is an access-layer switch and SW2 is the core, this is backward.
Common Root Bridge Misconfiguration Scenarios
Scenario 1: New Switch Arrives with Default Priority, Lower MAC
A Catalyst 9300 (SW4) is added to the network. It has default priority 32768 and a MAC address lower than the intended root.
SW1 (Root, priority 32768, MAC aabb.cc00.0410)
SW2 (priority 32768, MAC aabb.cc00.0420)
SW4 (NEW, priority 32768, MAC aabb.cc00.0404) <- LOWER MAC!
Bridge ID calculation:
- SW1: 32768 + aabb.cc00.0410 → ID: 8000.aabb.cc00.0410
- SW2: 32768 + aabb.cc00.0420 → ID: 8000.aabb.cc00.0420
- SW4: 32768 + aabb.cc00.0404 → ID: 8000.aabb.cc00.0404
SW4 wins! Its bridge ID (8000.aabb.cc00.0404) is lower than SW1's (8000.aabb.cc00.0410). Despite being a new edge device, SW4 becomes the root bridge.
SW1# show spanning-tree vlan 10
Root ID Priority 32768
Address aabb.cc00.0404 (SW4, NOT US!)
Why this is wrong:
- SW4 is likely an access-layer switch with lower processing power
- All traffic now flows through SW4, bottlenecking the edge
- Redundancy is compromised; if SW4 fails, there's no backup root
Fix: Apply Priority to Intended Root
Designate SW1 as the root:
SW1(config)# spanning-tree vlan 10 priority 4096
SW1(config)# exit
Alternatively, use the root primary macro (simpler):
SW1(config)# spanning-tree vlan 10 root primary
SW1(config)# exit
Verify:
SW1# show spanning-tree vlan 10 | include "Root ID"
Root ID Priority 4096
Address aabb.cc00.0410
SW1# show running-config | include spanning-tree
spanning-tree vlan 10 priority 4096
SW4# show spanning-tree vlan 10 | include "Root ID"
Root ID Priority 4096
Address aabb.cc00.0410
All switches now report SW1 (aabb.cc00.0410) as root with priority 4096. The election is correct.
Scenario 2: Two Switches Claim to be Root (Bridge ID Corruption)
Rarely, two switches report themselves as root simultaneously:
SW1# show spanning-tree vlan 10 | include "This bridge is the root"
This bridge is the root
SW2# show spanning-tree vlan 10 | include "This bridge is the root"
This bridge is the root
This indicates:
- Bridging loop (topology confusion)
- Corrupted bridge ID on one switch
- Failure to receive BPDUs from the other root
Immediate fix: Clear spanning tree state and let it reconverge.
SW1# clear spanning-tree detected-protocols
This forces SW1 to resend BPDUs and listen for remote BPDUs. Both switches will participate in re-election.
If the problem persists:
SW1(config)# no spanning-tree vlan 10
SW1(config)# spanning-tree vlan 10
SW1(config)# exit
This removes and re-adds VLAN 10's spanning tree configuration, clearing any stale state.
Scenario 3: Root Priority Set Too High (Not Low Enough)
An administrator sets the root priority to 8192, but another switch has a lower MAC with priority 16384:
SW1: Priority 8192 + MAC aabb.cc00.0410 → ID: 2000.aabb.cc00.0410
SW2: Priority 16384 + MAC aabb.cc00.0400 → ID: 4000.aabb.cc00.0400
SW1 still wins (2000 < 4000), so this is correct. But if another switch with an even lower MAC and default priority (32768) is added:
SW3: Priority 32768 + MAC aabb.cc00.0350 → ID: 8000.aabb.cc00.0350
SW1 is still root (2000 < 8000). Safe.
However, if the intent was to make SW2 root but the administrator set it to 16384 instead of 4096:
SW2(config)# spanning-tree vlan 10 priority 16384
SW1 (priority 8192) will still win. The correct approach:
SW2(config)# spanning-tree vlan 10 root primary
Or explicitly:
SW2(config)# spanning-tree vlan 10 priority 4096
Verify SW2 is now root:
SW2# show spanning-tree vlan 10 | include "This bridge is the root"
This bridge is the root
Detecting and Addressing Topology Change Notification Storms
When the root bridge changes, all switches receive a Topology Change Notification (TCN). The switches then flush their MAC address tables and rebuild them by learning frames again. This is correct behavior for a true topology change, but excessive TCNs indicate instability.
Symptom: TCN Storm (Frequent Topology Changes)
Watch syslog for repeated TCN messages:
*Mar 25 14:32:05.123: %SPANTREE-6-RECV_TCNOTIFICATION: Received topology change notice on port Po1, instance VLAN0010
*Mar 25 14:32:06.456: %SPANTREE-6-RECV_TCNOTIFICATION: Received topology change notice on port Po1, instance VLAN0010
*Mar 25 14:32:07.789: %SPANTREE-6-RECV_TCNOTIFICATION: Received topology change notice on port Po1, instance VLAN0010
*Mar 25 14:32:08.345: %SPANTREE-6-RECV_TCNOTIFICATION: Received topology change notice on port Po1, instance VLAN0010
Four TCNs in 4 seconds. Normal operation has TCNs only when links genuinely change. This frequency indicates a problem.
Root Cause Analysis for TCN Storms
TCNs are generated when:
- A non-root bridge receives a superior BPDU (suggesting the root has changed)
- A port transitions from FWD to BLK or vice versa
If TCNs are repeating, one of these is happening repeatedly:
Cause 1: Flapping Port
A port goes down and up repeatedly:
*Mar 25 14:32:05.123: %LINK-3-UPDOWN: Interface Gi0/1, changed state to down
*Mar 25 14:32:06.456: %SPANTREE-6-RECV_TCNOTIFICATION: Received topology change notice...
*Mar 25 14:32:07.123: %LINK-3-UPDOWN: Interface Gi0/1, changed state to up
*Mar 25 14:32:08.456: %SPANTREE-6-RECV_TCNOTIFICATION: Received topology change notice...
Fix: Check the physical link:
show interfaces Gi0/1 | include errors
High errors indicate a faulty cable. Replace it.
Cause 2: Root Bridge Alternating
Two switches are contending for root, and BPDUs from each arrive at different times, making the other think it's the better root:
*Mar 25 14:32:05.123: %SPANTREE-7-PORT_STATE_CHANGE: Port Po1 instance VLAN0010 moved to blocking state.
*Mar 25 14:32:06.456: %SPANTREE-7-PORT_STATE_CHANGE: Port Po1 instance VLAN0010 moved to forwarding state.
*Mar 25 14:32:07.789: %SPANTREE-7-PORT_STATE_CHANGE: Port Po1 instance VLAN0010 moved to blocking state.
Fix: Explicitly set root priorities on both switches to prevent election oscillation:
SW1(config)# spanning-tree vlan 10 root primary
SW2(config)# spanning-tree vlan 10 root secondary
These macros automatically set SW1 to 4096 (primary) and SW2 to 8192 (secondary), ensuring a stable election.
Cause 3: Bridge ID Mismatch on Looped Switch
If a switch that shouldn't have multiple spanning tree instances somehow does (e.g., due to VLAN configuration error), it might alternate between seeing different roots:
SW4# show spanning-tree summary
Switch is in rapid-pvst mode
Root bridge for: VLAN0010, VLAN0020
SW4 claims to be the root for both VLANs, but SW1 is supposed to be. This confuses other switches.
Fix: Check which VLANs should have SW4 as root (probably none). Remove the configuration:
SW4(config)# no spanning-tree vlan 10 priority
SW4(config)# no spanning-tree vlan 20 priority
This removes any manual priority settings and resets SW4 to default (32768), allowing the intended root to win.
Using Debug Commands to Monitor Root Changes
Enable Debug Spanning Tree Events
SW1# debug spanning-tree events
Spanning Tree event debugging is on
Watch the live output as you trigger a root change:
*Mar 25 14:40:10.234: STP[10]: Topology change! hello time 2 max age 20
*Mar 25 14:40:10.345: STP[10]: Rcv superior bpdu on port Po1 instance 10
*Mar 25 14:40:10.456: STP[10]: Setting root hello time from 2 to 2
*Mar 25 14:40:10.567: STP[10]: Transiting from backup to non-backup role
*Mar 25 14:40:11.234: STP[10]: Rcv a config BPDU on port Po1 instance 10
*Mar 25 14:40:12.456: STP[10]: Hello + TCN (send) on port Po1 instance 10
Key messages:
- "Rcv superior bpdu on port Po1" → Remote BPDU is better. Topology may change.
- "Transiting from backup to non-backup role" → This switch's role is changing. Topology change imminent.
- "Hello + TCN (send) on port Po1" → Sending topology change notification to neighbors.
Disable Debug When Done
SW1# undebug spanning-tree events
Or simply:
SW1# undebug all
Verification After Fixing Root Bridge Issue
Confirm New Root
SW1# show spanning-tree vlan 10,20,30 | include "This bridge is the root"
This bridge is the root
This bridge is the root
This bridge is the root
SW1 is the root for all three VLANs. Correct.
Verify Topology Converges
SW1# show spanning-tree vlan 10
VLAN0010
Spanning tree enabled protocol rspt
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
SW2# show spanning-tree vlan 10
VLAN0010
Root ID Priority 4096
Address 0023.47a1.ef80
Bridge ID Priority 8192 (priority 8192 sys-id-ext 10)
Address aabb.cc00.2010
Interface Role PortPri.Nbr Status Cost PortCost Vlans
-------------- ---- ----------- ------ ----------- -------- ------
Po1 Root P2Se.1 FWD 19000 19000 10
All switches report the same root. Root ports are clear. No loops. Topology is stable.
Check TCN Frequency
Monitor syslog for 30 seconds. Normal operation should show zero TCN messages during that window (unless a genuine link change occurs).
show log | include "RECV_TCNOTIFICATION"
If multiple TCNs appear in a short time, investigate further.
Troubleshooting Symptom → Cause → Fix
Symptom: Newly Added Switch Becomes Root Unexpectedly
Cause: The new switch has a lower MAC address than the intended root, and both have the same (default) priority.
Fix:
- Identify the intended root:
show spanning-tree vlan 10 | include Root - If this is not the intended switch, apply root primary on the correct switch:
SW1(config)# spanning-tree vlan 10 root primary - Verify:
show spanning-tree vlan 10 | include Root
Symptom: Root Port Keeps Changing, TCNs Every 30 Seconds
Cause: Flapping link between the current root and a backup switch, or periodic priority election due to missing explicit configuration.
Fix:
- Check for link errors:
show interfaces | include errors - If errors are high, replace the cable.
- Set root primary and secondary explicitly:
SW1(config)# spanning-tree vlan 10 root primary SW2(config)# spanning-tree vlan 10 root secondary - Monitor for TCNs:
show log | include TCNOTIFICATION
Symptom: Two Switches Claim to be Root (show spanning-tree says "This bridge is the root" on Two Different Switches)
Cause: Bridging loop, corrupted MAC table, or stale BPDU cache.
Fix:
- On one of the non-intended root switches, clear spanning tree:
clear spanning-tree detected-protocols - Verify the intended root is elected:
show spanning-tree vlan 10 | include Root - If the problem persists, reload the affected switch (last resort):
reload in 2
What's Next
In the next article, we'll explore errdisable states caused by spanning tree guard features (BPDU Guard, Root Guard, Loop Guard). You'll learn to identify which guard triggered an errdisable, understand when each guard should be enabled, and configure automatic recovery.