Spanning Tree: Root Bridge Election
A misconfigured root bridge sends traffic the long way round. Diagnose it and fix it yourself, live, right below.
SW-CORE · SW-ACCESS-1 · SW-ACCESS-2
The problem
Three switches are wired in a triangle for redundancy. SW-CORE was meant to be the STP root bridge, but hosts behind SW-ACCESS-1 are seeing unusually high latency to the rest of the network, even though the direct link between SW-CORE and SW-ACCESS-1 is up and reports no errors.
What you'll practice
- Identify the current root bridge with show spanning-tree
- Understand root bridge election: lowest bridge priority, then lowest MAC address
- Correct a misconfigured priority so the intended switch becomes root
- Verify the topology reconverges and the expected port starts forwarding
The topology
A three-switch triangle: SW-CORE, the intended root, wired to two access switches, SW-ACCESS-1 and SW-ACCESS-2, which are also linked to each other for redundancy, plus a host behind each access switch. The minimal loop topology every STP lesson starts with.
Every other guided lab works exactly like this one, except the fix stays behind a free email unlock, and the full step-by-step goes to Learning Pass holders.
Frequently asked
Why does root bridge placement matter if all the links are up anyway?
The root bridge decides which port on every other switch blocks to prevent a loop. Put the wrong switch in that role and traffic takes a longer, more congested path even though nothing is technically down.
Is this a real spanning-tree bug or a toy example?
It's the most common real STP misconfiguration there is: someone (or a stale default) sets bridge priority away from the intended design, and the network keeps working, just slower and less predictably than it should.
Ready to run this lab yourself?
No setup, no image sourcing. Book a session or ask for a live demo.