STP/RSTP Loop Prevention and Bridge Roles
Key Takeaways
- Spanning Tree Protocol prevents Layer 2 loops by logically blocking redundant paths while keeping them as backups.
- RSTP (802.1w) converges in seconds versus 30-50 seconds for classic STP (802.1D).
- The root bridge is the lowest Bridge ID (priority + MAC); place it on a core/distribution switch on purpose.
- Port roles (root, designated, alternate/backup) and states explain why one link forwards and another blocks.
- Loop symptoms include broadcast storms, MAC table flapping, high CPU, and switch-wide outages.
Why STP Exists
Ethernet frames have no Time To Live (TTL) field like IP packets, so a Layer 2 loop never self-terminates. With redundant switch links and no loop control, a single broadcast frame circulates forever and multiplies - a broadcast storm - until the network collapses. Spanning Tree Protocol (STP) builds a single loop-free logical tree across physically redundant switches.
| Problem | Result without STP |
|---|---|
| Redundant switch links | Frames loop indefinitely |
| Broadcast/unknown unicast | Storm consumes bandwidth and CPU |
| MAC learned on two ports | MAC address table flapping |
| Flooding | Switching domain saturates |
STP lets you cable redundant paths for resilience while keeping only one active; if the active path dies, a blocked path transitions to forwarding and restores connectivity automatically.
STP vs RSTP
| Feature | STP (802.1D) | RSTP (802.1w) |
|---|---|---|
| Purpose | Loop prevention | Loop prevention, faster |
| Convergence | 30-50 seconds | typically 1-6 seconds |
| Port states | 5 (disabled, blocking, listening, learning, forwarding) | 3 (discarding, learning, forwarding) |
| Port roles | root, designated, blocked | root, designated, alternate, backup |
When a scenario asks for the fastest Layer 2 convergence and devices support it, RSTP is the modern answer. RSTP is backward compatible and falls back to 802.1D behavior on legacy segments.
Bridge ID and Root Bridge Election
Switches elect one root bridge as the tree's reference point. The decision uses the Bridge ID, which is the 2-byte bridge priority (default 32768, set in increments of 4096) plus the switch MAC address. The lowest Bridge ID wins; if priorities tie, the lowest MAC breaks the tie.
| Factor | Selection impact |
|---|---|
| Bridge priority | Lower is preferred (e.g., 4096 < 32768) |
| MAC address | Tie-breaker when priorities match |
| Root placement | Should be a central, stable core/distribution switch |
| Unplanned root | An old closet switch with a low MAC can win, causing bad paths |
Worked example: A new access switch in a wiring closet has an older, numerically lower MAC and wins the root election by default. Traffic now hairpins through the closet, and key uplinks block. The correct fix is to set the intended core switch to a lower priority (e.g., spanning-tree vlan 1 priority 4096) so it becomes root - not to disable STP.
Port Roles, States, and Edge Features
| Role / state | Meaning |
|---|---|
| Root port | Best single path from a non-root switch toward root |
| Designated port | Forwarding port elected for each segment |
| Alternate port | Backup to the root port (RSTP) |
| Blocking / discarding | Receives BPDUs but forwards no data - loop prevention |
| Forwarding | Sends and receives normal traffic |
| Edge port (PortFast) | Endpoint-facing port that skips listening/learning |
PortFast speeds host ports to forwarding immediately; pair it with BPDU Guard, which err-disables a PortFast port if it ever receives a BPDU - a sign someone plugged a switch into an edge port and could create a loop.
Recognizing a Loop
| Symptom | Why it points to a loop |
|---|---|
| Network-wide slowness after adding a switch | New redundant path created a storm |
| Same MAC bounces between ports | MAC table flapping from looping frames |
| Switch CPU spikes | Control plane drowning in Layer 2 churn |
| All VLANs on a switch unstable | Trunk loop affecting every VLAN |
| Link LEDs blink solidly, little useful data | Flooding/storm condition |
PBQ Procedure for Redundant Links
- Identify and confirm the intended root bridge (lowest priority on the core).
- Confirm every switch runs compatible STP/RSTP settings.
- Expect exactly one redundant path to block/discard - that is normal.
- Apply PortFast + BPDU Guard only on endpoint-facing ports.
- Never disable STP to force a blocked link to forward.
BPDUs and Protection Features
Switches exchange BPDUs (Bridge Protocol Data Units) every 2 seconds (the default hello timer) to maintain the tree. Two protection features show up on the exam:
| Feature | What it does |
|---|---|
| BPDU Guard | Err-disables a PortFast/edge port that receives any BPDU |
| Root Guard | Prevents a downstream switch from becoming root on that port |
| Loop Guard | Blocks a port that stops receiving expected BPDUs |
BPDU Guard is the most-tested: if a user plugs an unmanaged switch into a PortFast wall jack, BPDU Guard shuts the port to stop a loop before it forms - which is why a port may show err-disabled with a BPDU-guard reason.
Common Traps
| Trap | Better reasoning |
|---|---|
| Assume a blocking port is broken | It is preventing a loop |
| Disable STP to use an idle link | That can trigger a broadcast storm |
| Let an access switch be root | Set priority so the core wins election |
| PortFast on switch-to-switch links | Edge features belong on host ports only |
| Troubleshoot Layer 3 during a storm | Stabilize Layer 2 first, then test routing |
During an active storm, physically remove the suspected redundant link or shut the offending port to break the loop, then correct the design - chasing pings or routes while frames circulate wastes time. Once the storm clears, re-enable redundancy, set the root priority on the core, and confirm exactly one alternate port returns to discarding.
What is the primary purpose of Spanning Tree Protocol?
Which switch becomes the STP root bridge?
Which symptoms commonly suggest a Layer 2 loop? Select two.
Select all that apply