Root Bridge Moved to the Access Layer
Three EX3400 switches are cabled in a triangle: SW-CORE connects to both SW-A and SW-B, and SW-A and SW-B are also linked to each other. All links are 1 Gbps and all VLANs use the default RSTP instance. The design intent is that SW-CORE is the root bridge. During a migration last year an engineer set bridge-priority 4096 on SW-B so that it would beat a legacy switch that has since been decommissioned; the setting was never removed. Monitoring now reports SW-B as the root bridge. Traffic from 40 PCs on SW-A to their gateway on SW-CORE travels SW-A to SW-B to SW-CORE over the single inter-switch link, which runs at 80% utilization. Ports facing the PCs are configured as ordinary RSTP ports. Last week a user connected a small unmanaged switch to a wall port and the whole access stack went through a spanning-tree reconvergence.
1. Why is SW-B the root bridge, and why does the SW-A-to-SW-CORE path now traverse SW-B?
Read the worked answer
Root election is lowest bridge ID, and bridge ID is priority then MAC. SW-B is 4096, everyone else is the default 32768, so SW-B wins before the MAC tie-break is ever consulted.
Once SW-B is root, SW-A's root port is selected by lowest root path cost to SW-B. SW-A has two candidates: the direct link to SW-B (one hop) and the link to SW-CORE (two hops, since SW-CORE is no longer root). The direct link wins, so the SW-A-to-SW-CORE link is placed in the discarding/alternate state.
Every frame from a PC on SW-A to its gateway must therefore go SW-A to SW-B to SW-CORE. That also means the SW-A/SW-B link is now on the only path for 40 users' default-gateway traffic, which is why it sits at 80%: the direct SW-A-to-SW-CORE link that was designed to carry that traffic is idle.
2. How do you restore SW-CORE as root with minimal disruption, and what do you verify during the change?
Read the worked answer
RSTP root election is not sticky: a switch that receives a superior BPDU reacts to it on the next BPDU exchange. So the fix is a priority change, not a clear command.
- Set SW-CORE to a value lower than every access switch, e.g.
set protocols rstp bridge-priority 4096- and give SW-B a distinct but higher value (8192) if you want a deterministic secondary root rather than a MAC tie-break. - Change SW-CORE first, in a maintenance window. As soon as SW-B sees the superior BPDU it stops being root, and the SW-A-to-SW-CORE link moves from alternate to root port.
- Verify with
show spanning-tree bridge(root ID should be SW-CORE's) andshow spanning-tree interfaceon SW-A (the SW-CORE facing port should be forwarding, the SW-B facing port discarding or alternate). - Confirm the inter-switch link utilization drops and that no port went to blocking unexpectedly.
The disruption risk is short but real: the change forces a topology change and a flush of MAC learning, so expect a brief flooding burst.
3. The unmanaged switch incident. What port-level protection should be on the PC-facing ports, and what is the trade-off?
Read the worked answer
Two separate things belong on PC-facing ports:
- Edge designation, so the port skips the listening/learning delay and goes straight to forwarding. This is the performance half.
- BPDU protection on those edge ports, so a BPDU arriving there err-disables the port instead of allowing an external switch to participate in the topology. Junos exposes this as an edge-port BPDU block (protocols rstp / layer2-control bpdu-block, exact syntax depends on ELS vs non-ELS).
With both, the user's unmanaged switch creates a loop that is contained to one err-disabled port instead of a whole-stack reconvergence. An auto-recovery timer avoids leaving the port down permanently.
The trade-off is that these settings are only safe where no legitimate switch will ever appear. If a downstream managed switch, an AP in bridge mode, or a VM host running bridging sits on the port, BPDU protection will shut it down and edge designation will hide a real loop from STP. On any port that could face another switch, use root guard instead, which blocks only a superior BPDU rather than any BPDU.