Under 802.1D spanning tree, why does a direct uplink failure take about 30 seconds to recover while an indirect failure takes about 50?
answer
- who notices the failure, and how
- link loss versus silence
- stored information must expire first
- Max Age plus two Forward Delays
basics
~20 sA direct failure shows up at once as link loss, leaving only listening and learning: about 30 s at IEEE defaults. An indirect failure is learned through BPDUs, so stored information must first reach Max Age (20 s): about 50 s.
solid answer
~40 sUnder 802.1D the difference is how the switch learns of the failure. In a **direct failure** a switch's own root-port link goes down. It notices at once, a blocked port that already hears a path to the root becomes the new root port, and that port walks through `listening` and `learning`, one Forward Delay each: about 30 s at the IEEE default of 15 s. In an **indirect failure** the broken link is elsewhere. The switch hears about it only through BPDUs, and 802.1D makes it keep the information it already stored on its blocked port until that information reaches **Max Age** (20 s by default). Only then does the port re-evaluate and walk through the same two phases. That gives up to about 20 + 15 + 15 = 50 s.
go deeper
Remember the two figures: about 30 seconds when a switch's own uplink fails, and about 50 when the failure is somewhere else and must first be learned through BPDUs.
Walk the two timelines: link loss then listening and learning (15 + 15), versus Max Age expiry then the same two phases (20 + 15 + 15).
Explain why 802.1D ignores inferior BPDUs until Max Age, what users experience during each phase, and why tuning timers is a weaker fix than moving to RSTP.
Weigh whether any design still tolerating 30 to 50 seconds of layer-2 outage is acceptable, and what replacing it costs: RSTP, routed access, or multi-chassis bundles.
## The topology Take three switches running **802.1D spanning tree** (the IEEE standard; its text is not an RFC), with the IEEE default timers: Hello 2 s, **Max Age** 20 s, **Forward Delay** 15 s. The IETF's Bridge MIB, RFC 4188, lists their settable ranges (Max Age 6 to 40 s, Hello 1 to 10 s, Forward Delay 4 to 30 s) but not the defaults, which are the IEEE's. - **R** is the root bridge, with a link to each of the other two. - **S2** and **S3** each use their link to R as their **root port**, their best path to the root. - S2 and S3 are also linked to each other. That link closes a triangle, so one end must block. Here S2 has the lower bridge ID, so S2's end is the **designated port** and forwards, while **S3's end is blocked**. S3's blocked port is not idle. It keeps receiving S2's BPDUs, which say "I am one hop from root R", and S3 stores that information. ## Direct failure: about 30 seconds The link R–S3 fails. 1. S3 sees the link go down on its own root port. Detection is immediate; no timer is involved. 2. S3 re-evaluates. Its blocked port toward S2 already holds a valid path to R, so it becomes the new root port. 3. 802.1D does not let a port jump from blocked to forwarding. It enters `listening` for one Forward Delay (15 s), then `learning` for another (15 s). 4. At about **0 + 15 + 15 = 30 s**, S3 forwards toward the root through S2. ## Indirect failure: about 50 seconds Now the link R–S2 fails instead. 1. S2 sees link loss on its root port. Its only other port is the designated port toward S3, which offers no path to the root, so S2 concludes that it is the root itself and starts sending BPDUs naming itself as root. 2. To S3 these BPDUs are **inferior**: they describe a worse root than the R that S3 has stored for that port. Under 802.1D, S3 keeps its stored information until it ages out and does not act on the inferior BPDUs before then. 3. S3 has seen no link loss. It waits up to **Max Age (20 s)** for the stored information to expire. 4. When it expires, S3 re-evaluates. It still reaches R through its own root port, so its port toward S2 becomes **designated** and starts sending BPDUs naming R. S2 recognises them as **superior** and makes its port toward S3 its new root port. 5. S3's newly designated port must still walk through `listening` (15 s) and `learning` (15 s) before it forwards. 6. At about **20 + 15 + 15 = 50 s**, S2 reaches the root through S3. ## Side by side | | Direct failure | Indirect failure | |---|---|---| | How it is noticed | Link loss on the switch's own root port | Only through BPDUs (inferior ones, or none at all) | | Wait before re-evaluation | None | Up to Max Age, 20 s | | Listening + learning | 15 s + 15 s | 15 s + 15 s | | Recovery at IEEE defaults | about 30 s | about 50 s | The 50 s is a worst case. Stored information carries an age, so it can expire a little earlier than a full Max Age after the failure. ## What the users see meanwhile - Frames toward the root across the failed path are lost for the whole interval, because nothing forwards on the backup path until it reaches `forwarding`. - When the backup port starts forwarding, spanning tree signals a topology change, and switches expire their MAC entries quickly. For a short time afterwards, unicast to hosts that have not yet been relearned is flooded. - Application sessions with timeouts shorter than 30 to 50 s may break. This is why classic spanning tree is described as "30 to 50 seconds of outage per failure". ## What changed later The 30 s and 50 s come from 802.1D's design: waiting on timers instead of confirming with a neighbour. **RSTP** (IEEE 802.1w, folded into 802.1D-2004) removes both parts. A precomputed alternate port takes over a failed root port without listening or learning. Inferior information from the designated bridge is accepted immediately instead of waiting for Max Age. With those two changes, most failures on point-to-point links recover in well under a second.
- In the indirect case, why doesn't S3 act at once on the inferior BPDUs it receives from S2?Under 802.1D a bridge keeps the best information it has stored for a port until that information reaches Max Age. A worse BPDU from the same neighbour does not replace it, so S3 sits out the Max Age wait before re-evaluating. RSTP changed this rule and accepts inferior information from the designated bridge immediately, which removes the 20 s.
- Could you cut the 50 seconds just by lowering Max Age and Forward Delay?Only partly, and at a risk. The root advertises the timers to every bridge, RFC 4188 limits Max Age to 6 to 40 s and Forward Delay to 4 to 30 s, and the IEEE standard ties the timers to each other and to the network's diameter. Timers that are too short can let ports forward before the tree has settled, which creates temporary loops. Moving to RSTP is the real fix.
saying these in an interview costs you the question
- Every 802.1D failure costs the full 50 seconds
- The 30 seconds of a direct failure is Max Age expiring
- A blocked 802.1D port starts forwarding the moment the root port fails
- An indirect failure is noticed by link loss on the switch's own port
- The 50 seconds is two Max Ages plus one Forward Delay