Spanning Tree Port States and the Cost of a Blocked Link

A set of transparent bridges connected in a mesh will loop broadcast traffic forever. Spanning tree solves the problem by computing a tree over the physical graph and disabling the ports that would close a cycle. The computation is distributed, it runs on a timer rather than on demand, and the ports it disables are still physically up and still receiving frames. Understanding which ports end up in which state, and why the transition takes the time it does, is what makes the protocol’s convergence behaviour predictable.

The root bridge and the cost metric

Every bridge has an identifier: a configurable priority, two bytes, followed by its six-byte MAC address. Comparison is numeric with the MAC as tie-break, and the protocol assumes identifiers are unique, so the election produces a single winner. The bridge with the lowest identifier becomes the root.

The root emits configuration BPDUs, which are frames with destination 01:80:c2:00:00:00 and a payload carrying the root identifier, the sender’s identifier, the cost from the sender to the root, and a set of timers. Non-root bridges receive these, add the cost of the port they arrived on, and propagate them outward with their own identifier as sender. Cost is a per-port value assigned from a table keyed by link speed. The original 16-bit table gives 100 for 10 Mbit/s, 19 for 100 Mbit/s, 4 for 1 Gbit/s, and 2 for 10 Gbit/s; the later revision replaces it with a 32-bit table whose values are 2,000,000 for 10 Mbit/s, 200,000 for 100 Mbit/s, 20,000 for 1 Gbit/s, and 2,000 for 10 Gbit/s, so that speeds above 10 Gbit/s can be distinguished at all. Either way the value is an administrative number, not a measured latency, and it does not adapt to load.

Each non-root bridge keeps the best BPDU it has heard, meaning the one with the lowest root identifier, then the lowest cost to the root, then the lowest sender identifier, then the lowest sending port identifier. The port on which the best BPDU arrived becomes the root port, the one port through which this bridge reaches the root. Every other port is either designated, meaning it is the best port on its segment for reaching the root, or blocked.

The result is that every segment has exactly one designated port transmitting toward it, and every bridge except the root has exactly one root port. The union of designated ports and root ports forms a tree. Ports that are neither are in a blocking state and forward no data.

Port states and what each one permits

The classic 802.1D state machine has five states:

State	Learns addresses	Forwards data	Sends/receives BPDUs
Disabled	No	No	No
Blocking	No	No	Receives
Listening	No	No	Yes
Learning	Yes	No	Yes
Forwarding	Yes	Yes	Yes

The separation of learning from forwarding is the mechanism that makes a topology change safe. A port that begins forwarding before it has learned addresses would flood frames for every destination, and if the topology has just changed, some of those frames would travel paths that the old table still points along. By spending a learning interval with forwarding disabled, the bridge populates its table from the traffic it observes on the new topology, and by the time the port forwards, the table describes the tree that is actually in use.

The timers that govern the transitions are carried in the BPDUs so that all bridges agree: a hello time of 2 seconds between BPDUs, a maximum age of 20 seconds before a stored BPDU is considered stale, and a forwarding delay of 15 seconds. A port moving from blocking to forwarding passes through listening for the forwarding delay and learning for another forwarding delay, so the transition takes 30 seconds in the absence of any acceleration. A link failure is detected when BPDUs stop arriving for the maximum age, so the worst-case recovery is roughly 50 seconds: 20 seconds to notice, then 30 to transition.

Those numbers are the price of the timer-based design, and shortening them without changing the protocol risks transient loops, because the timers are what guarantee that all bridges have seen the new topology before any of them forwards on it.

Topology change notification and table flushing

When a bridge detects that a port has changed state in a way that alters the tree, it does not simply update its own table. It sends a topology change notification toward the root, and the root then sets a flag in its configuration BPDUs for a period. Every bridge that sees the flag reduces its aging time from the default to the forwarding delay, so entries expire quickly rather than lingering for minutes. The flush is deliberate: entries learned on the old topology may point at ports that no longer lead anywhere.

The cost of the flush is a burst of flooding while tables refill. On a large network a topology change therefore produces a visible, brief increase in flooded traffic, and repeated changes, which happen when a link is flapping, keep the network in that state. This is one reason a flapping link is treated as an incident rather than a nuisance.

Failure modes that the protocol does not prevent

Spanning tree assumes that BPDUs are delivered. A bridge that stops receiving them, because of a unidirectional link, a broken cable, or a device that filters the reserved group address, will eventually age out its stored BPDU and start forwarding on a port it should block. If the other end is still forwarding, a loop forms.

The failure is inherent in a protocol that infers liveness from received frames: silence is indistinguishable from a link that is filtering the reserved group address. The rapid variant narrows the window by ageing received information after three hello times rather than the classic maximum age, but it cannot tell a dead link from a filtered one. Ports facing end stations are configured as edge ports so that their silence is not treated as a failure; a port wrongly classified as an edge port forwards immediately and can close a loop, which is why the setting is explicit rather than inferred.

A second failure mode is a bridge that is not running the protocol at all: a consumer switch, a hub, or a virtual bridge in a hypervisor with spanning tree disabled. Such a device forwards BPDUs it receives, or drops them, and either way the tree computation does not include its internal topology. Two ports of the same unmanaged switch connected into the same managed network create a loop the managed bridges cannot see.

Rapid spanning tree and the state reduction

The rapid variant, defined in later revisions of 802.1D and carried into 802.1Q, replaces the timer-driven transitions with an explicit handshake. A designated port proposes, its downstream neighbour agrees, and the port moves to forwarding without waiting for the forwarding delay, because the agreement proves that the neighbour has stopped forwarding on any other port that would close a loop. Ports that are not part of a handshake still wait.

The rapid variant also reduces the states from five to three: discarding, learning, and forwarding, with the blocking and listening states merged into discarding. The information content is the same; the reduction reflects that the distinction between blocking and listening existed only to sequence the timers.

Convergence on a link failure in the rapid variant is bounded by the detection of the failure plus the handshake, which is on the order of a few seconds rather than tens of seconds, provided the failure is detected by the protocol rather than by a carrier loss that takes longer to report. The remaining exposure is the edge of the network: a port configured as an edge port skips the handshake entirely and forwards immediately, which is correct for a host and catastrophic for a bridge.

Why the tree and not something better

The obvious alternative to a spanning tree is to use all links and forward along shortest paths, which is what layer-3 routing does and what the routing-bridge proposals formalised. The obstacle is the frame format: Ethernet has no hop count, so a frame that follows a non-tree path has no way to be discarded when it reaches a loop. Any scheme that uses multiple paths must either add a header field, which is what TRILL and the shortest-path bridging amendments do, or accept that the topology must be acyclic.

Given that constraint, the tree is the minimal structure that keeps the graph acyclic while preserving connectivity, and disabling links is the only way to obtain it without changing the frame. The bandwidth left unused on blocked links is the price, and it is the reason aggregation and routing at layer 3 are preferred for high-capacity backbones. The learning behaviour that the tree protects is described in MAC learning and bridge forwarding, and the way ports are partitioned into separate trees per VLAN is part of 802.1Q VLAN tagging.