skip to content

In a campus spanning tree where an old access switch won the root election, what happens to traffic between the distribution switches, and how do you fix it?

level: seniorimportance: should knowfreq 30%

answer

  1. the tree hangs from the root
  2. fast link idle, slow links busy
  3. the root also sets the timers
  4. a primary and a secondary, on purpose

basics

~20 s

Every forwarding path radiates from the root, so traffic between the distribution switches detours through the access switch's uplinks while their direct link blocks. Fix it by giving the distribution switches the two lowest bridge priorities, as primary and secondary root.

solid answer

~50 s

Spanning tree builds one loop-free tree hanging from the root, so the links on the root's paths carry traffic and redundant ones block. With an access switch as root, each distribution switch reaches it most cheaply through its own uplink to that closet, so the direct inter-distribution link is blocked at one end and traffic between the two distribution switches crosses the access switch and its thinner uplinks. That closet becomes a choke point and a fragile one: if it reboots, the whole domain re-elects. The root also imposes its Hello Time, Max Age and Forward Delay on every bridge (RFC 4188). The fix is to give the intended primary root the lowest priority, say 24,576, and the secondary the next, 28,672, so no default 32,768 switch can win and the root sits at distribution or core.

go deeper

for a junior

Recall that all spanning-tree traffic flows along a tree hanging from the root, so a badly placed root drags traffic through the wrong switch.

for a middle

Trace why an access-switch root leaves the inter-distribution link blocked, using path costs, and explain the primary and secondary priority values that move the root.

for a senior

Diagnose the symptom from traffic patterns and the reported root ID, plan the move with its reconvergence cost, and point out that the root also dictates the domain's timers.

for a principal

Treat root placement as part of a campus standard alongside per-tree load sharing, and question how large a layer-2 domain should be when one switch's placement shapes all of it.

## The scenario A campus has two distribution switches, **DIST-1** and **DIST-2**, joined by a 10 Gb/s link. Eight access closets, **ACC-1** to **ACC-8**, each have a 1 Gb/s uplink to both distribution switches. Nobody set a bridge priority, so all ten switches carry the IEEE default, 32,768, and the lowest MAC address decides the root. That turns out to be **ACC-7**, the oldest switch, in a closet. Path costs below use the IEEE 802.1D-1998 short values, which are the IEEE's and not an RFC's: **4** for a 1 Gb/s link and **2** for a 10 Gb/s link. ## How the tree forms around the wrong root Each switch finds its cheapest path to the root, and the protocol blocks enough redundant ports to leave exactly one path; the port-by-port rules are a separate topic, so only the outcome is traced here. 1. **DIST-1** reaches ACC-7 directly over its uplink at cost 4. Going via DIST-2 would cost 2 + 4 = 6, so the direct uplink wins. 2. **DIST-2** does the same: cost 4 direct, 6 via DIST-1. 3. The **DIST-1 to DIST-2 link** is on neither switch's best path to the root, so one end of it blocks. The 10 Gb/s link carries no traffic. 4. **Every other access switch** sees cost 4 + 4 = 8 through either distribution switch. The tie goes to the distribution switch with the lower bridge ID, so all of them forward through the same one, and their uplinks to the other block. | Path | With ACC-7 as root | With DIST-1 as root | |---|---|---| | DIST-1 to DIST-2 | via ACC-7, two 1 Gb/s hops, cost 8 | direct 10 Gb/s link, cost 2 | | ACC-1 to a server behind DIST-2 | ACC-1, DIST-1, ACC-7, DIST-2 | ACC-1, DIST-1, DIST-2 | | Load on ACC-7's uplinks | all inter-distribution traffic | its own users only | ## What it costs - **Bandwidth.** Traffic that should cross a 10 Gb/s link is squeezed through two 1 Gb/s closet uplinks. - **Latency and hops.** Frames between distribution switches take an extra switch hop through the closet. - **Failure domain.** If ACC-7 reboots, loses power or is replaced, the root disappears and the whole domain re-elects, recomputes every path and reconverges, an outage for everyone, not just that closet. - **Timers.** RFC 4188 says the Hello Time, Max Age and Forward Delay a bridge is configured with are the values "all bridges use" when that bridge is root. Odd timer settings on a forgotten switch become the whole domain's behaviour. - **Troubleshooting.** The traffic pattern makes no sense on the design diagram, so problems are slow to diagnose. ## Moving the root 1. Choose the **primary** root (DIST-1) and the **secondary** (DIST-2), the switches where the links converge. 2. Set DIST-1's priority to **24,576** and DIST-2's to **28,672**. Both are on the 4,096 grid and both beat the default 32,768, so neither ACC-7 nor any new default switch can win, and if DIST-1 fails, DIST-2 takes over rather than the lowest MAC address in the building. 3. Expect a **reconvergence event**: changing the root makes every bridge recompute its paths, and under 802.1D ports that must start forwarding wait through listening and learning, about 30 seconds at the IEEE default Forward Delay. Do it in a maintenance window. 4. **Verify**: every switch should report DIST-1's bridge ID as its root (`dot1dStpDesignatedRoot` in RFC 4188), and the DIST-1 to DIST-2 link should now forward. After the change, DIST-2 reaches the root over the 10 Gb/s link at cost 2 instead of 4 + 4 = 8 through a closet; each access switch forwards through its DIST-1 uplink at cost 4, against 4 + 2 = 6 through DIST-2, and blocks its DIST-2 uplink. ## Why the root belongs at distribution or core - It is where the fastest links and most paths meet, so the tree's active links are the ones built for the load. - It is the most robust hardware, usually with redundant power, so the root changes least often. - With a separate tree per VLAN or per instance, the two distribution switches can each be primary root for half of the trees, so both uplinks of each closet carry traffic; that refinement belongs to per-VLAN and multiple spanning tree design.

  • Why set a secondary root explicitly instead of letting the election choose a backup?
    If only the primary is tuned, its failure hands the election back to the defaults, and the lowest MAC address, perhaps the same old closet switch, wins again. Setting the second distribution switch one step above the primary, for example 28,672 against 24,576, makes it the certain successor while it stays below the 32,768 default every other switch carries.
  • Will moving the root disrupt traffic, and when should you do it?
    Yes. A new root makes every bridge recompute its paths. Under 802.1D, ports that must start forwarding pass through listening and learning, about 30 seconds at the IEEE default Forward Delay, and the topology change shortens MAC table ageing, so frames flood for a while. Schedule it in a maintenance window and verify afterwards that every switch reports the new root.
  • Do the new priorities stop any other switch from ever becoming root?
    No. They only raise the bar: a switch must now be configured with an even lower priority, or match the primary's priority with a lower MAC address, to win. Keeping a misconfigured or hostile switch from taking the root needs a guard on the ports where a root should never appear, a separate protection feature.

saying these in an interview costs you the question

  • Root placement only affects BPDUs, not where data traffic flows.
  • Spanning tree automatically elects the most central or fastest switch as root.
  • Tuning only the primary root is enough; the backup will sort itself out.
  • Each switch uses its own Hello and Forward Delay settings whatever the root is.
  • The root can be moved during business hours with no traffic impact.