How does RSTP restore forwarding in well under a second after an uplink fails, and when does it fall back to 802.1D-like timers?

seniorshould knowfreq 25%

answer

replace waiting with knowing
a backup path computed in advance
silence detected in three Hellos
shared links and old neighbours

basics

~20 s

RSTP promotes a precomputed alternate port at once, accepts bad news from its designated bridge immediately, and confirms forwarding by handshake on point-to-point links. Shared links, 802.1D neighbours and non-edge host ports fall back to timers.

solid answer

~50 s

RSTP (IEEE 802.1w, now part of 802.1D-2004) removes each wait that made 802.1D take 30 to 50 s. A switch already knows its backup path: an alternate port that hears a path to the root, which becomes the new root port and forwards at once when the root-port link drops. RSTP accepts inferior information from its designated bridge immediately instead of waiting out Max Age. Downstream, designated ports on point-to-point links reach forwarding through an explicit handshake with the neighbour rather than through timed phases. The speed is conditional. A shared (half-duplex) link, a neighbour that speaks only 802.1D, or a host port not marked as edge all fall back to two Forward Delays. A fault that leaves the link up is detected only after three missed Hellos, 6 s at the IEEE default Hello of 2 s.

RSTP (IEEE 802.1w, now part of 802.1D-2004) removes each wait that made 802.1D take 30 to 50 s. A switch already knows its backup path: an **alternate port** that hears a path to the root, which becomes the new root port and forwards at once when the root-port link drops. RSTP accepts inferior information from its designated bridge immediately instead of waiting out Max Age. Downstream, designated ports on **point-to-point** links reach `forwarding` through an explicit handshake with the neighbour rather than through timed phases. The speed is conditional. A shared (half-duplex) link, a neighbour that speaks only 802.1D, or a host port not marked as edge all fall back to two Forward Delays. A fault that leaves the link up is detected only after three missed Hellos, 6 s at the IEEE default Hello of 2 s.

go deeper

for a junior

Remember that RSTP recovers from most link failures in well under a second, against 30 to 50 seconds for classic spanning tree, because it keeps a ready alternate path to the root.

for a middle

Explain the three changes: the alternate port taking over at once, immediate acceptance of inferior information, and a handshake replacing listening and learning on point-to-point links.

for a senior

Know where the speed is lost: shared links, 802.1D neighbours, host ports without edge status, and faults that keep the link up and need three missed Hellos to detect.

for a principal

Judge whether sub-second layer-2 recovery is enough for the services involved, or whether the design should rely on routed links or bundles that avoid spanning-tree reconvergence altogether.

Where 802.1D's 30 to 50 seconds came from

Classic 802.1D spanning tree (the IEEE standard, not an RFC) spends recovery time in three places:

Detection. A failure on the switch's own link is seen as link loss. A failure elsewhere is noticed only when stored BPDU information reaches Max Age (20 s at the IEEE default).
Ignoring bad news. A worse ("inferior") BPDU from the neighbour does not replace stored information until that information expires.
Timed admission. Every port that moves towards forwarding spends one Forward Delay listening and one learning (15 s each at the IEEE default).

RSTP, the rapid spanning tree protocol (IEEE 802.1w, folded into 802.1D-2004; RFC 4318 is its IETF management view), attacks each of the three. Its default timer values, the IEEE's, are the same as 802.1D's, and the figures below use them. The speed comes from changed rules, not from shorter timers.

The three changes

Delay in 802.1D	What RSTP does instead	Effect
Wait for Max Age on a silent neighbour	Every bridge sends its own BPDU every Hello; information is aged after three missed Hellos	Silence is detected in about 6 s, not up to 20 s
Ignore inferior BPDUs until stored information expires	Accept inferior information from the designated bridge immediately	The indirect-failure wait disappears
Listening + learning on every new forwarding port	A ready alternate port forwards at once as the new root port; designated ports on point-to-point links forward after a handshake with the neighbour	No 30 s timed walk on the normal path

The handshake is RSTP's proposal and agreement exchange. It is a mechanism in its own right; what matters here is that it replaces timed waiting with explicit confirmation from the bridge on the other end of the link.

The uplink failure, replayed under RSTP

An access switch has two uplinks. One is its root port; the other is an alternate port, blocked but already holding the second-best path to the root.

The root-port link goes down. Link loss is reported at once by the physical layer.
The alternate port becomes the root port and moves straight to forwarding. There is no listening phase and no learning phase.
Because a non-edge port has just started forwarding, the switch signals a topology change, and switches flush the MAC entries that may now point the wrong way.
Traffic resumes in about the time it takes to detect link loss and recompute: typically well under a second.

For an indirect failure, a switch upstream that loses its own path sends inferior BPDUs. Its neighbour accepts them at once, answers with its own better information, and the handshake brings the repaired path to forwarding without waiting out Max Age.

When RSTP falls back to timers

RSTP's speed depends on conditions. Interviewers probe exactly these:

Shared links. The handshake is used only on point-to-point links. RFC 4318's point-to-point object, in its automatic setting, treats a port as point-to-point when it runs full duplex, or when it is an aggregator whose members are all aggregatable. On a half-duplex shared segment a designated port uses the timed path, two Forward Delays.
An 802.1D neighbour. A port that hears 802.1D BPDUs drops to 802.1D-compatible operation on that link, timers included. RFC 4318 exposes a protocol-migration control that forces the port to try RSTP BPDUs again once the neighbour has been upgraded.
Host ports not marked as edge. A host never answers the handshake, so a non-edge designated port facing it waits two Forward Delays, about 30 s at the default.
Failures that keep the link up. If a fault stops BPDUs without dropping the link, for example inside a media converter or on one direction of a fibre pair, there is no link-loss event. Detection then takes three missed Hellos, about 6 s at the IEEE default.

Why the guarantee is "well under a second", not a number

The recovery time is dominated by how fast the physical layer reports link loss and how fast the switch recomputes and rewrites its forwarding state. Both are implementation properties. The protocol guarantees that no timer stands in the way on point-to-point links between RSTP bridges. That is why the honest claim is "well under a second on point-to-point links", not a fixed millisecond figure.

What still costs time afterwards

Even with a sub-second port transition, the MAC-table flush that follows a topology change makes switches flood unicast for unlearned destinations until hosts are heard again. That is usually a brief burst rather than an outage, but on a large, busy VLAN the flood is noticeable.

## Where 802.1D's 30 to 50 seconds came from Classic **802.1D** spanning tree (the IEEE standard, not an RFC) spends recovery time in three places: 1. **Detection.** A failure on the switch's own link is seen as link loss. A failure elsewhere is noticed only when stored BPDU information reaches **Max Age** (20 s at the IEEE default). 2. **Ignoring bad news.** A worse ("inferior") BPDU from the neighbour does not replace stored information until that information expires. 3. **Timed admission.** Every port that moves towards forwarding spends one **Forward Delay** listening and one learning (15 s each at the IEEE default). **RSTP**, the rapid spanning tree protocol (IEEE 802.1w, folded into 802.1D-2004; RFC 4318 is its IETF management view), attacks each of the three. Its default timer values, the IEEE's, are the same as 802.1D's, and the figures below use them. The speed comes from changed rules, not from shorter timers. ## The three changes | Delay in 802.1D | What RSTP does instead | Effect | |---|---|---| | Wait for Max Age on a silent neighbour | Every bridge sends its own BPDU every Hello; information is aged after three missed Hellos | Silence is detected in about 6 s, not up to 20 s | | Ignore inferior BPDUs until stored information expires | Accept inferior information from the designated bridge immediately | The indirect-failure wait disappears | | Listening + learning on every new forwarding port | A ready **alternate port** forwards at once as the new root port; designated ports on point-to-point links forward after a handshake with the neighbour | No 30 s timed walk on the normal path | The handshake is RSTP's proposal and agreement exchange. It is a mechanism in its own right; what matters here is that it replaces timed waiting with explicit confirmation from the bridge on the other end of the link. ## The uplink failure, replayed under RSTP An access switch has two uplinks. One is its root port; the other is an **alternate port**, blocked but already holding the second-best path to the root. 1. The root-port link goes down. Link loss is reported at once by the physical layer. 2. The alternate port becomes the root port and moves straight to `forwarding`. There is no listening phase and no learning phase. 3. Because a non-edge port has just started forwarding, the switch signals a **topology change**, and switches flush the MAC entries that may now point the wrong way. 4. Traffic resumes in about the time it takes to detect link loss and recompute: typically well under a second. For an indirect failure, a switch upstream that loses its own path sends inferior BPDUs. Its neighbour accepts them at once, answers with its own better information, and the handshake brings the repaired path to forwarding without waiting out Max Age. ## When RSTP falls back to timers RSTP's speed depends on conditions. Interviewers probe exactly these: - **Shared links.** The handshake is used only on **point-to-point** links. RFC 4318's point-to-point object, in its automatic setting, treats a port as point-to-point when it runs full duplex, or when it is an aggregator whose members are all aggregatable. On a half-duplex shared segment a designated port uses the timed path, two Forward Delays. - **An 802.1D neighbour.** A port that hears 802.1D BPDUs drops to 802.1D-compatible operation on that link, timers included. RFC 4318 exposes a protocol-migration control that forces the port to try RSTP BPDUs again once the neighbour has been upgraded. - **Host ports not marked as edge.** A host never answers the handshake, so a non-edge designated port facing it waits two Forward Delays, about 30 s at the default. - **Failures that keep the link up.** If a fault stops BPDUs without dropping the link, for example inside a media converter or on one direction of a fibre pair, there is no link-loss event. Detection then takes three missed Hellos, about 6 s at the IEEE default. ## Why the guarantee is "well under a second", not a number The recovery time is dominated by how fast the physical layer reports link loss and how fast the switch recomputes and rewrites its forwarding state. Both are implementation properties. The protocol guarantees that no **timer** stands in the way on point-to-point links between RSTP bridges. That is why the honest claim is "well under a second on point-to-point links", not a fixed millisecond figure. ## What still costs time afterwards Even with a sub-second port transition, the MAC-table flush that follows a topology change makes switches flood unicast for unlearned destinations until hosts are heard again. That is usually a brief burst rather than an outage, but on a large, busy VLAN the flood is noticeable.

Why can a fault inside a media converter make RSTP take seconds instead of milliseconds?
The switch port keeps its link up, so no link-loss event fires. The only sign is that BPDUs stop arriving. RSTP treats the stored information as aged after three missed Hellos, about 6 s at the IEEE default Hello of 2 s. That is still faster than 802.1D's 20 s Max Age, but it is not sub-second.
What happens on an RSTP port whose neighbour runs only 802.1D?
The RSTP port detects 802.1D BPDUs and runs 802.1D-compatible operation on that link, so it uses listening and learning with Forward Delay timers and loses the fast transition. After the neighbour is upgraded, an operator can trigger protocol migration (RFC 4318 exposes the control) so the port sends RSTP BPDUs again.
Is RSTP faster because its default timers are shorter than 802.1D's?
No. The IEEE defaults are the same: Hello 2 s, Max Age 20 s, Forward Delay 15 s. RSTP is faster because it stops depending on those timers on the normal path: a precomputed alternate port, immediate acceptance of inferior information, and a handshake on point-to-point links. The timers remain as the fallback.

saying these in an interview costs you the question

RSTP is faster because its default timers are shorter
RSTP converges in under a second on every kind of link
RSTP still waits out Max Age after an indirect failure
An RSTP port facing an 802.1D-only switch keeps the fast handshake
RSTP's backup port is the ready replacement for a failed root port

How does RSTP restore forwarding in well under a second after an uplink fails, and when does it fall back to 802.1D-like timers?

§ answer

basics

solid answer

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Where 802.1D's 30 to 50 seconds came from

The three changes

The uplink failure, replayed under RSTP

When RSTP falls back to timers

Why the guarantee is "well under a second", not a number

What still costs time afterwards

▾common follow-ups3 questions

▾red flags5 flags

Where 802.1D's 30 to 50 seconds came from

The three changes

The uplink failure, replayed under RSTP

When RSTP falls back to timers

Why the guarantee is "well under a second", not a number

What still costs time afterwards

answer

go deeper