RSTP Root in the Access Layer Plus an Undocumented Loop
A three-floor campus runs RSTP throughout. Each access switch is dual-homed to distribution switches SW-D1 and SW-D2, and the two floor-3 access switches are also joined by an undocumented patch lead. SW-F3-Access carries bridge priority 4096 and is the root bridge for every VLAN; both distribution switches still use the default 32768. Wall ports are not configured as edge ports anywhere. Users report 30–60 second freezes whenever a laptop is plugged into a wall socket, and the NMS shows MAC address flaps between two access switches. After a recent incident an engineer proposed enabling BPDU filter on all access-facing ports to stop the flapping.
1. Explain the freezes and the MAC flaps from the current topology and configuration. Distinguish the two separate faults.
Read the worked answer
There are two independent faults that reinforce each other.
Fault 1 - the root bridge is in the wrong place. SW-F3-Access has priority 4096, the lowest in the network, so it wins the election and becomes root for all VLANs. Every path in the topology is now computed relative to a floor-3 access switch. Its uplinks become designated/forwarding toward the distribution layer and one of the distribution uplinks is blocked. Traffic between floors is hairpinned through an access switch with a small forwarding capacity and a single power supply.
Fault 2 - no edge ports. Wall ports are ordinary RSTP ports. Every laptop link-up/down generates a topology change, and because the root is an access switch, the TC propagates to the entire network. Each TC flushes MAC tables everywhere, so traffic is flooded while the tables re-learn - the 30–60 s freeze. The frequent flushing is also what the NMS reports as MAC flaps.
Fault 3 - the undocumented patch lead. It creates a redundant path between two access switches. RSTP blocks one end, but the blocked port is on the access-to-access link, not on the intended distribution path, because root placement is wrong. Any instability on that lead produces repeated reconvergence on top of the TC storm.
Confirm with display stp root (root ID is the floor-3 switch), display stp brief (which port is ALTE/DISCARDING), and check whether the blocked port sits on the access-to-access link.
2. Give the concrete configuration plan, in the correct order, with the risk of each step.
Read the worked answer
Order matters: fix root placement first, because every other decision depends on which ports should be blocking.
- Make the distribution layer root. On SW-D1:
stp root primary(priority 0); on SW-D2:stp root secondary(priority 4096). Access switches keep 32768 or are raised. Risk: a brief reconvergence on every VLAN; schedule it in a window. - Confirm the intended blocking point. After the election,
display stp briefshould show the access-to-access link (and one uplink on the secondary side) as DISCARDING/ALTE. If it does not, the physical topology differs from the documentation. - Remove or document the patch lead. Once STP is clean, the redundant access-to-access link serves no design purpose; leave it only if you add
stp loop-protectionon the relevant ports so a unidirectional fault cannot create a loop. - Turn wall ports into edge ports.
stp edged-port enableon access-facing interfaces - these no longer generate TCs. Risk: a loop on such a port is not detected by STP, so it must be paired with protection. - Enable BPDU protection globally (
stp bpdu-protection) so an edge port receiving a BPDU goes to ERROR DOWN rather than forming a loop. Adderror-down auto-recovery cause bpdu-protection interval 300so a misconnected port recovers without a truck roll. - Rate-limit TC processing with
stp tc-protection(and a sensible threshold) as a safety net against future storms.
Verify: replug a laptop and confirm no TC counter increment (display stp tc-bpdu statistics) and no MAC flush on the distribution switches.
3. Evaluate the proposal to enable BPDU filter on all access-facing ports. What does the engineer actually want, and what would this break?
Read the worked answer
The engineer is treating the symptom. BPDU filter does not stop topology changes; it stops BPDUs being sent and received on a port. On an access port that means the switch neither sends its own BPDUs nor processes any received ones.
The consequences are dangerous in exactly this network:
- If someone loops two filtered wall ports together (or connects an unmanaged switch that loops), STP on those ports is effectively blind. The loop is forwarded at line rate and the broadcast storm takes down the floor - the opposite of the intended fix.
- Filtered ports still forward the BPDUs of any switch behind them as data, so a rogue switch can become root and the real root never learns about it.
- The freezes are caused by TCs from non-edge ports and by wrong root placement; BPDU filter addresses neither.
The correct control set is: edge ports for end devices (which removes the TC source), BPDU guard on those same ports (which disables the port if a BPDU ever arrives, catching loops and rogue switches), and stp loop-protection/root-protection on the switch-to-switch ports where appropriate. BPDU filter is only appropriate on a port facing a device you fully control and deliberately want outside STP - which is not a user wall port.