Lesson text for this page (click to expand)

STP Spanning Tree

Lessons (6, study in order)

Lesson 1 · Why STP is needed

Beginner · about 8 min

Goal: Pick up where the L2 module left off, and see clearly the tension STP has to resolve.

First, recap the problem

In the L2 module you've already seen:

the moment a topology has a loop, a broadcast frame just circulates forever, with copies doubling exponentially
because the Ethernet frame header has no TTL.

The result is three symptoms hitting at once: a broadcast storm + MAC table flapping + CPU pegged,
and you can't even log into the management port — someone has to walk into the datacenter and unplug a cable.

★ STP is the standard answer to exactly this problem.

★★ But think through the tension first

A lot of people's first reaction is "then just don't connect a loop." That instinct is wrong,
because redundant links are a good thing — the whole point of plugging in a second cable is "if one breaks, the other takes over."

Removing redundancy just trades "a single point of failure" for "no loop" — not a trade worth making.

★★★ So the real requirement is: have redundancy, but only use one path at a time.
That's exactly what STP does:
· Computes a spanning tree across all links (a tree is loop-free by nature)
· Blocks the extra links (no data forwarding, but keeps listening)
· If the primary link goes down, the blocked port takes over automatically

★ "Blocked" doesn't mean "disabled"

This is the easiest thing to misunderstand. A blocked port:

· ❌ forwards no user data frames → so the loop is broken
· ✅ but still receives BPDUs → so it can keep watching the topology for changes

It's exactly because it's always listening that it can take over the moment the primary link fails.
If it were truly disabled, the redundancy would've been pointless to add.

Hands-on: watch a tree take shape

Go to the Topology & Bridge ID page. The current scenario is a triangle loop of three switches.

★ Look at the canvas: one link is drawn as a red dashed line — that's the blocked one.
Count it: 3 devices, 3 links, block 1 and 2 remain —
exactly "node count − 1", which is a tree.

Key takeaways

  • ★★★ The tension STP resolves: redundancy is good, but using two at once is a loop
  • The answer: compute a spanning tree, block the extra links
  • Blocked ≠ disabled: no data forwarding, but still receives BPDUs — so it can take over
  • The result is necessarily loop-free, because a tree's definition is exactly "edges = nodes − 1"

Lesson 2 · ★★ Electing the root bridge: the classic incident lives right here

Beginner · about 10 min

Goal: Understand how bridge IDs compare, and why "leaving priority unconfigured" causes trouble.

Bridge ID = priority + MAC

STP's first step is electing a single, unique root bridge, and the entire tree grows outward from it.

What's compared is the bridge ID, 8 bytes total:

Priority (2 bytes) + MAC address (6 bytes)

The rule is simple: treat it as one big number, lowest wins
in other words, "compare priority first, and only compare MAC if priority ties."

★ Priority defaults to 32768, and must be a multiple of 4096
(the low 12 bits were later claimed by the System ID extension, used to support one tree per VLAN).

★★★ And that's how this incident happens

If the whole network is left at the default priority, every device is at 32768 — priority can't break the tie,
so it comes down to the second field: MAC address.

And a MAC address is usually correlated with a device's manufacture year.

★★ The result is often: the oldest, weakest, most out-of-the-way access switch in the datacenter ends up as the root bridge
and nobody ever made that decision.

⚠️ The consequences are subtle, because the network still works:
· All cross-switch traffic detours through that weak device, taking an unnecessarily long path
· Its backplane and CPU become the whole network's bottleneck
· If it ever reboots, the entire network reconverges (tens of seconds of outage)

★ This is the classic "monitoring shows all green, it's just slow" problem — you'll never notice unless you actively check.

Hands-on: watch the root bridge land on a weak device

The current scenario is ② Wrong root bridge elected: core + aggregation + two access switches, all at the default priority.

Go to the Root Election page and look at "why it won" — it will tell you plainly that the root bridge was chosen purely by comparing MAC addresses, and the winner is that Acc1-Legacy device.

★ Then switch to the ③ Root bridge planned properly scenario for comparison: the exact same topology, except the core is set to 4096 and the backup core to 8192 — the root bridge immediately snaps back to where it should be.

★ Standard real-world practice

Primary core 4096, backup core 8192, access layer stays at the default 32768.

This achieves three things:
· The root bridge is uniquely determined, not left to the luck of comparing MACs
· If the primary core dies, the root bridge falls to the backup core (rather than randomly landing on some access device)
· A newly added access device can never steal the root bridge role (its default value is the highest)

⚠️ One pitfall along the way: don't set priority to 0.
Once it's 0, there's no room left below it for a device with an even lower priority — leave some headroom.

Key takeaways

  • Bridge ID = priority (2B) + MAC (6B), compared as one whole number, lowest wins
  • Priority defaults to 32768, must be a multiple of 4096
  • ★★★ All defaults → comes down to MAC → the oldest weak device becomes the root, and nobody ever decided that
  • ★ Standard practice: primary core 4096, backup core 8192, access layer at the default

Lesson 3 · Port roles: how the tree grows

Beginner · about 10 min

Goal: Derive the entire tree from just two sentences.

★ The whole rulebook fits in two sentences

① Every non-root switch has exactly one root port.
② Every link has exactly one designated port.

Every other port gets blocked. That's the entire algorithm — the whole tree follows from these two sentences.

★ Why is the result necessarily a tree? Because every non-root device has exactly one edge pointing upward (its root port),
N devices, N−1 edges — exactly the definition of a tree.

How a root port is chosen (a three-level comparison)

Root port = the port pointing toward the root bridge. Compared in order, stop at the first tiebreak:

Lowest path cost to the root
② Same cost → lowest peer bridge ID
③ Still tied → lowest peer port ID

★ Path cost is set by link speed (802.1D short format):
· 10M → 100 · 100M → 19 · 1G → 4 · 10G → 2

⚠️ Note cost accumulates, and it's always the incoming port's cost that gets added —
every time a BPDU crosses a link, the receiver adds that link's cost.

How a designated port is chosen

Designated port = the end of a link responsible for sending BPDUs downstream.

How it's chosen: whichever end of the link is closer to the root (lower path cost) wins;
same cost → the end with the lower bridge ID.

★ Two useful corollaries:
· Every port on the root bridge is a designated port (its cost to the root is 0, nothing is closer)
· If one end is the root port, the other end is necessarily the designated port

Hands-on: see "why" for each port

Go to the Port Roles page. Every port in the table has a column called "why this role"
it spells out the actual numbers from that three-level comparison above.

★ Focus especially on the blocked port: it won neither the root port on its own device, nor the designated port on its own link.

Key takeaways

  • Every non-root device has one root port; every link has one designated port; everything else is blocked
  • Root port, a three-level comparison: path cost → peer bridge ID → peer port ID
  • Designated port: whichever end is closer to the root, tiebreak on bridge ID
  • Path cost: 10M=100 / 100M=19 / 1G=4 / 10G=2, and it accumulates

Lesson 4 · ★★★ How long does convergence take: 30 seconds or 50

Troubleshooting · about 12 min

Goal: See classic STP's most fatal flaw — and the direct reason it got phased out.

Four port states, two 15-second waits

For a blocked port to become forwarding, it must walk through, in order:

Blocking → Listening (15s) → Learning (15s) → Forwarding

Why wait? Two reasons, both legitimate:
· Listening — waiting for topology information to finish propagating. Forward without waiting, and you could get a transient loop where "I think I should forward, and my neighbor thinks so too"
· Learning — quietly learning the MAC table first. Start forwarding with an empty table, and the first batch of frames all get flooded — too big an impact

★ But legitimate doesn't mean acceptable — it adds up to 30 seconds.

★★ And an indirect failure adds another 20

The key difference is whether this device knows something went wrong:

· Direct failure — what went down is its own port, the physical layer reports it down instantly → no waiting, straight into the state machine → 30 seconds
· Indirect failure — what went down is a link elsewhere; it has no idea.
It can only infer it from "huh, I haven't received a BPDU in a while," and that requires waiting through MaxAge = 20 seconds50 seconds total

⚠️ Those 20 seconds are pure waste: the failure already happened, but nobody knew.

★★★ What 50 seconds actually means (not just "a bit slow")

· Massive TCP connection timeouts and reconnects — default retransmit backoff was long since exceeded
· Voice / video calls all drop, requiring rejoining
· Database connection pools drain empty, applications start throwing errors
· ★★ Clusters misjudge node failures — heartbeat timeouts trigger an unnecessary failover, and the failover itself costs even more time

★★★ The most damaging part: the fault itself may have lasted only 1 second (a brief link flap that resolved on its own),
but STP's convergence kept the service down for 50 seconds —
the protocol's recovery process did more damage than the fault itself.

Hands-on: break a link once and watch the clock

Go to the Convergence page, pick a link that's currently forwarding, and click "Start simulation."

★ Watch the timeline: how many seconds each phase takes, and during which phases service is actually down.
★★ Then switch the protocol to RSTP in the top-left, and break the same link again — compare that number.

Key takeaways

  • Blocking → Listening (15s) → Learning (15s) → Forwarding
  • Direct failure 30 seconds, indirect failure 50 seconds (an extra 20-second MaxAge wait)
  • ★★★ The consequences go beyond "slow": TCP disconnects, voice/video all drop, clusters misjudge and trigger a failover
  • The most damaging part is that the protocol's recovery process hurts more than the fault itself

Lesson 5 · RSTP: turning 50 seconds into 1

Intermediate · about 10 min

Goal: Understand what makes RSTP converge quickly — and why there's no reason to still run classic STP.

★★ Three improvements

① Proposal / Agreement mechanism
Two devices shake hands directly to confirm "can I forward now?" "Yes" —
no more "waiting for a timer to expire." This is the core improvement.

② Alternate Port
★ RSTP splits the blocking role further, pre-computing a backup:
the moment the root port dies, the alternate port instantly promotes to root port — no recomputation needed.

③ Edge Port
Ports facing end devices go straight into forwarding, skipping the 30-second wait.
Because the other end is a PC, it can never be part of a loop, so there's no need to wait.

★ Edge ports must have BPDU protection configured

An edge port skips every check, so it carries one risk:

if a BPDU is ever received on this port, someone plugged in a rogue switch here.

⚠️ This is the most common real-world source of loops — an employee brings in their own small switch, someone chains a dumb switch in a conference room.
Worse still: if the rogue device has a lower MAC, it could even steal the root bridge role, flipping the entire network's topology.

★ So an edge port must always have BPDU protection configured:
the moment a BPDU is received, shut that port down immediately, stopping the risk at the source.

★★ These two commands are standard practice on real networks — the kind that "will cause trouble if left unconfigured":
stp edged-port enable + stp bpdu-protection

Hands-on: same fault, two protocols

Go to the Convergence page:
① First break a link under STP, note the number of seconds
② Switch the protocol to RSTP, break the same link

★ Compare the two numbers — that's the entire benefit of upgrading to RSTP.

Key takeaways

  • RSTP relies on three things: Proposal/Agreement handshake, Alternate Port, Edge Port
  • Convergence drops from 30-50 seconds to under 1 second
  • ★ Edge ports must have BPDU protection configured — rogue switches are the most common source of loops
  • ★★ On real networks there's no reason whatsoever to still run classic STP — it's a pure win

Lesson 6 · ★★ STP's cost, and why datacenters abandoned it

Intermediate · about 10 min

Goal: See STP's inherent cost clearly, and the alternative answer modern architectures give.

★ The cost: half the bandwidth paid for but unusable

STP breaks a loop by blocking, and a blocked link carries literally zero bytes most of the time.

A dual-uplink access switch with two 1G uplinks connected:
STP blocks one → the actually usable uplink is only 1G, not 2G.

⚠️ Yet the money's spent regardless: optics, ports, cabling, rack space, power — none of it was saved.

★ Go to the Port Roles page and look at the "blocked bandwidth" statistic — it quantifies exactly this.

L2-internal ways to mitigate it

· Link aggregation (Eth-Trunk / Port-Channel)
Bundle multiple cables into one logical link, so STP treats it as a single link — both cables get to forward. ★ This is the most commonly used approach

· Stacking / M-LAG
Make two physical devices look like one to STP — uplinks can be dual-active

★ But note these all route around STP rather than improving it. L2's fundamental constraint hasn't changed: it must be loop-free.

★★★ The datacenter's answer: replace layer 2 entirely

Modern datacenters (spine-leaf) take a more thorough approach: don't solve the problem at this layer at all.

They make the fabric's interior L3, and use ECMP:

| | STP (layer 2) | L3 + ECMP |
|---|---|---|
| Redundant links | blocked | all forward |
| Bandwidth utilization | half idle | 100% |
| Adding bandwidth | more just means more blocked | plug in one more spine, get one more path |
| Convergence | seconds | milliseconds (routing protocol) |

★ The cost is that the layer-2 semantics business needs (VM migration, same subnet) have to be built on top of L3 via VXLAN.

★★ Go see that full comparison on the "Architecture comparison" page of the Datacenter Spine-Leaf module — that page covers exactly this.

★ Finally, keep STP and SPF straight

These two abbreviations are one letter apart, but completely different things, and this project has both:

| | STP | SPF |
|---|---|---|
| Full name | Spanning Tree | Shortest Path First |
| Layer | Layer 2 | Layer 3 |
| Computes | a tree | the shortest path to every destination |
| Redundant links | blocked | all usable (+ECMP shares load) |
| Who uses it | Switches | OSPF / IS-IS |

★ To see SPF's implementation, go to the OSPF or IS-IS module.

Key takeaways

  • ★ STP's inherent cost: blocked links are paid for but unusable
  • L2 mitigations: link aggregation, stacking / M-LAG (both route around STP, not improve it)
  • ★★★ The datacenter's answer: switch to L3 + ECMP, every link forwards
  • ⚠️ STP ≠ SPF: one is a layer-2 spanning tree (blocks redundancy), the other is a layer-3 shortest path (everything usable)