Spanning Tree & Link-Layer Resilience
Redundant Ethernet paths become destructive loops unless bridges agree on a loop-free active topology. This entry derives STP/RSTP port roles, follows reconvergence after failure, separates spanning tree from link aggregation, and turns topology state into operational evidence.
Redundant links are valuable only when the forwarding system has a rule for using them. In a transparent bridged network, an uncontrolled cycle can circulate frames indefinitely because an Ethernet MAC header has no hop limit. Spanning-tree protocols preserve physical redundancy while selecting a loop-free active topology for ordinary data.
The tree is distributed control-plane state, not a property of the cables. A link can be electrically up and intentionally not forward user traffic; after failure, a previously non-forwarding port can become the recovery path.
Why one loop is enough #
Consider a broadcast or unknown-unicast frame entering a cycle of three bridges. Each bridge floods it to eligible ports except ingress. Copies return on different ports, are flooded again, and can multiply. Three effects reinforce one another:
- persistent replication: the frame has no link-layer TTL to expire it;
- duplicate delivery: endpoints can receive several copies of one original frame;
- unstable learning: the same source appears alternately on different ports, so FDB entries flap and even known unicast is misdirected.
Queue saturation and control-plane starvation then make the topology harder to recover. Rate limiting broadcast traffic may slow the collapse but does not make the cyclic forwarding graph correct.
Graphically, a spanning tree retains every bridge vertex and selects enough links to connect them without a cycle. For bridge vertices, the active simple tree has inter-bridge edges. Extra physical edges remain available but cannot all forward the same spanning-tree instance simultaneously.
The information in a BPDU #
Bridges exchange Bridge Protocol Data Units (BPDUs) that describe their current view of the tree. The comparison needs enough information to answer four ordered questions:
- Which bridge is the root?
- What is the path cost to that root?
- Which transmitting bridge offers that information?
- Which port breaks an otherwise equal comparison?
Bridge and port identifiers make the result deterministic. The numerically best advertised information wins according to the protocol's ordered comparison; the objective is not a global traffic optimization but agreement on one loop-free structure.
Root, port roles, and states #
For one spanning-tree instance:
- the root bridge is the elected reference point;
- each non-root bridge selects one root port, its best path toward the root;
- each LAN segment selects one designated port, the port offering that segment's best path toward the root;
- redundant paths become alternate or other non-forwarding roles until needed.
Role answers “what is this port's place in the topology?” State answers “what may it do now?” Rapid spanning tree uses the operational states:
| State | Learn source addresses? | Forward ordinary data? | Purpose |
|---|---|---|---|
| discarding | no | no | prevent a data loop while control information is processed |
| learning | yes | no | populate forwarding state before admitting data |
| forwarding | yes | yes | carry data on the active topology |
A port can receive and process control traffic while discarding ordinary data. “Link up but ping fails” is therefore expected on an alternate port; the correct evidence is its spanning-tree role and state.
One failure, one controlled transition #
In the illustrated steady state, S1 is root. S2 and S3 each have a direct root path; one end of the S2–S3 link is non-forwarding for this tree. When the S1–S3 path fails:
- S3 loses its current root-port information;
- the information received through S2 becomes its best available root path;
- the S2–S3 roles and states are updated through the protocol's synchronization procedure;
- ordinary data can use S3 → S2 → S1 without reintroducing the cycle;
- affected FDB state must converge with the new topology so traffic is not pinned to the failed direction.
Restoration is not instantaneous. Link-failure detection, BPDU propagation, agreement, state transition, and FDB correction all contribute. RSTP improves the reconfiguration procedure compared with original timer-driven STP, especially on point-to-point links and explicitly identified edge ports, but it cannot remove physical detection delay or incorrect configuration.
Edge ports shorten startup by making a promise #
An edge port is expected to attach an endpoint, not another bridge. It can enter forwarding without waiting for the same synchronization used on an inter-bridge link. The speedup rests on a topology promise: this attachment cannot create a bridge cycle.
Receiving a BPDU on an intended edge should therefore be treated as evidence that the promise is false. Exact protective actions—disable, restrict, log, or require operator review—are implementation and policy choices, but silently continuing as a trusted edge discards the safety assumption.
Never label a port edge merely to make an outage disappear. First prove what is attached and whether an unmanaged switch, hypervisor bridge, accidental cable, or dual-homed device can forward frames.
Root placement and path cost are design inputs #
Default identifiers can elect a valid but undesirable root. The active tree then follows cost toward that root, which may block an important link or force traffic through a low-capacity or administratively weak device.
Design requires explicit answers:
- which bridge should be root for each relevant instance;
- which bridge should be the backup root;
- which path costs express the intended active and standby paths;
- which ports are genuine edges;
- which failure removes each active path;
- how much traffic moves onto the surviving path after failure.
Spanning tree prevents loops; it does not reserve standby capacity. If two active links each carry 70% of a downstream bottleneck before a failure, a loop-free reconvergence can still overload the survivor.
RSTP and multiple spanning-tree instances #
Original STP, Rapid Spanning Tree Protocol (RSTP), and Multiple Spanning Tree Protocol (MSTP) describe related generations and deployment models. Current bridge standards consolidate these semantics in IEEE 802.1Q.
RSTP accelerates agreement about a loop-free topology and defines roles that make alternate paths explicit. MSTP allows multiple VLANs to be mapped to a bounded set of spanning-tree instances. Different instances can choose different active trees, so selected VLAN groups need not all block the same physical link.
MST is not automatically “one tree per VLAN.” Bridges in one MST region must agree on the region identity and VLAN-to-instance mapping. A mismatch creates a boundary and can produce forwarding paths different from the operator's drawing. Capture and compare the actual configuration digest/identity and observed BPDUs rather than assuming matching instance numbers mean matching regions.
Link aggregation solves a different graph problem #
IEEE 802.1AX link aggregation lets compatible parallel point-to-point links operate as one logical link. The aggregation function coordinates which members may collect and distribute frames; the bridge and spanning tree then see the logical link rather than independent parallel edges.
This gives two distinct resilience mechanisms:
| Mechanism | Hides or controls | Active use | Typical failure response |
|---|---|---|---|
| Link aggregation | several member links between compatible partners | members can share traffic | remove failed member, keep logical link if policy permits |
| Spanning tree | redundant logical paths in a bridged topology | one loop-free topology per instance | change port roles/states and relearn paths |
Aggregation does not mean one flow receives the sum of member rates. Distribution normally preserves ordering by keeping related frames on one member, so capacity is shared across a set of conversations. A single large flow can remain bounded by one member. Configuration must also agree on partner identity, member compatibility, and minimum viable membership; otherwise a physically up member may be excluded or, worse, form a separate forwarding path.
Independent parallel cables must not be mistaken for an aggregate. Until both ends agree that they are one logical link, spanning tree must treat them as separate edges and prevent the resulting cycle.
A convergence evidence set #
For an outage or topology change, preserve a timeline rather than one post-event screenshot:
- physical carrier transitions and negotiated modes on both ends;
- root bridge identifier and root path cost before and after;
- every relevant port's role and state;
- last BPDU receipt and the superior/inferior information observed;
- topology-change counters or notifications;
- FDB moves, flushes, and relearning for affected sources;
- aggregate member state if the path includes a LAG;
- queue drops and utilization on the surviving path;
- packet observations at ingress and expected egress.
The decisive sequence might be: carrier loss at 12:00:00.100, root-port invalidation at 12:00:00.104, alternate agreement at 12:00:00.116, forwarding at 12:00:00.120, first successful data frame at 12:00:00.123. Without aligned clocks and raw state, “STP took about a second” mixes detection, protocol, host, and measurement delay.
Common reasoning traps #
- “A redundant cable is backup automatically.” It is safe only if link aggregation or a loop-avoidance control plane owns it.
- “Blocking means broken.” A non-forwarding alternate can be the correct steady state.
- “The root bridge is the traffic center.” It is the tree's reference; individual host paths depend on source and destination positions in the active topology.
- “RSTP makes convergence instantaneous.” It accelerates agreement but still depends on failure detection, compatible neighbors, correct edge classification, and data-plane relearning.
- “MST gives every VLAN a unique tree.” VLANs are explicitly mapped to a finite set of instances.
- “A LAG doubles every transfer.” Member distribution increases aggregate capacity across conversations; ordering constraints can keep one conversation on one member.
- “Broadcast suppression fixes a loop.” It may limit one symptom while duplicate unicast and MAC flapping continue. The graph must become loop-free.
Sources
- docsIEEE 802.1Q-2022: Bridges and Bridged Networks
- docsIEEE 802.1AX-2020: Link Aggregation
- docsIEEE 802.1w: Rapid Reconfiguration of Spanning Tree
- docsLinux kernel documentation: Ethernet Bridging
- bookComputer Networks: Lecture Coursepdfnotes