In 802.1D spanning tree, what do the Hello, Max Age and Forward Delay timers control, and whose values do bridges actually use?
answer
- pace, shelf life, waiting room
- news carries its own age
- the root sets the clock
- Forward Delay has a second job
basics
~20 sHello Time (IEEE default 2 s) paces the root's Configuration BPDUs, Max Age (20 s) is how long stored BPDU information lives, and Forward Delay (15 s) is each listening and learning period. Every bridge uses the root's values, carried in its BPDUs.
solid answer
~50 s**Hello Time** is the interval at which the root sends Configuration BPDUs, 2 s by the IEEE standard's default. **Max Age**, 20 s by default, is how old stored BPDU information may become before a bridge discards it; because each BPDU carries a **Message Age** that started at zero at the root, information expires when its age reaches Max Age, which is how a bridge notices an indirect failure nobody announced. **Forward Delay**, 15 s by default, is the time a port spends in each of listening and learning, and during a topology change it is also the shortened MAC ageing time. The defaults are the IEEE's; the Bridge MIB (RFC 4188) gives their ranges (1-10 s, 6-40 s, 4-30 s). Bridges do **not** use their own settings: they use the values the root puts in its BPDUs, and a bridge's configured values matter only when it becomes root.
go deeper
Recall the three timers and their IEEE defaults, Hello 2 s, Max Age 20 s, Forward Delay 15 s, and roughly what each paces.
Explain Message Age against Max Age, Forward Delay's two jobs, and why bridges use the timers the root advertises rather than their own.
Diagnose a timer that was set but did not take effect, and check that the root and backup root carry the same values before a failover proves they do not.
Treat timer settings as a property of the whole layer-2 domain owned by the root's configuration, and weigh tuning them against moving to RSTP or a routed design.
## Three timers, three jobs Classic spanning tree (**IEEE 802.1D**; the IETF restates its managed objects in the Bridge MIB, RFC 4188) runs on three protocol timers. The defaults below are the IEEE standard's; RFC 4188 gives only the ranges an operator may set, in hundredths of a second. | Timer | IEEE default | RFC 4188 range | What it governs | |---|---|---|---| | **Hello Time** | 2 s | 1-10 s | how often the root sends Configuration BPDUs | | **Max Age** | 20 s | 6-40 s | how old stored BPDU information may become before it is discarded | | **Forward Delay** | 15 s | 4-30 s | time in each of listening and learning; the MAC ageing time during a topology change | The MAC table's ordinary **ageing time** is a separate setting: RFC 4188 notes that 802.1D-1998 recommends 300 s. ## Hello Time: the pace RFC 4188 defines Hello Time as the time between Configuration BPDUs a bridge sends "when it is the root of the spanning tree, or trying to become so". Under 802.1D-1998 the root originates a Configuration BPDU every Hello Time, and the other bridges relay it outward. A shorter Hello means fresher information and more BPDUs; the standard also caps bursts, since RFC 4188's Hold Time object allows no more than two Configuration BPDUs per Hold Time interval. ## Max Age and Message Age: the shelf life Every Configuration BPDU carries a **Message Age**, which the root sets to zero and each relaying bridge increases. A bridge stores the best information it has heard on each port and lets it age from the received Message Age. When that age reaches **Max Age**, RFC 4188's "maximum age of Spanning Tree Protocol information learned from the network on any port before it is discarded", the information is thrown away and the bridge recomputes its port roles from what is left. This is how 802.1D notices an **indirect failure**. If a link two hops away dies, no message announces it; the BPDUs simply stop arriving, and the stored copy expires at Max Age. Because the age started at the root: - a bridge far from the root receives information that is already older, so it has less time left before expiry; - information that has crossed too many relays may arrive almost expired, which is why Max Age also bounds the size of the tree. How long the whole recovery then takes, Max Age plus the listening and learning periods, is a matter of failover timing. ## Forward Delay: the waiting room, and a second job RFC 4188 states the two uses directly. Forward Delay "determines how long the port stays in each of the Listening and Learning states, which precede the Forwarding state", and it "is also used when a topology change has been detected and is underway, to age all dynamic entries in the Forwarding Database". So: 1. a port selected to forward waits one Forward Delay listening and one learning, 30 s at the default; 2. while the root signals a topology change, bridges age MAC entries after 15 s instead of 300 s. ## Whose values count: the root's The decisive detail is that **every bridge uses the root's timers**, carried in the Max Age, Hello Time and Forward Delay fields of each Configuration BPDU. RFC 4188 makes the split visible with two sets of objects: - `dot1dStpMaxAge`, `dot1dStpHelloTime`, `dot1dStpForwardDelay` — the values this bridge is **currently using**; - `dot1dStpBridgeMaxAge`, `dot1dStpBridgeHelloTime`, `dot1dStpBridgeForwardDelay` — the values "that all bridges use" **when this bridge is acting as the root**. Consequences an interviewer will probe: - changing timers on a non-root bridge does nothing until it becomes root; - if the root fails and a backup root takes over, the backup's configured timers take effect, so both should be configured alike; - the timers are related, and changing one alone can break the others' assumptions. ## RSTP's version RSTP (IEEE 802.1w, folded into 802.1D-2004) keeps the same fields but has every bridge send its own BPDU each Hello Time and discard a neighbour's information after missing three Hellos (the IEEE's rule). Message Age and Max Age remain as a hop limit. RFC 4318 adds `dot1dStpTxHoldCount`, default 3, range 1-10, which limits how fast a port may transmit BPDUs.
- Why does a bridge far from the root effectively get less than Max Age to keep stored information?Message Age starts at zero at the root and grows at each relay, and information is discarded when its age reaches Max Age. A bridge many hops away therefore receives information that has already used part of its lifetime. If Max Age is too small for the number of hops, distant bridges discard information almost as soon as it arrives.
- You configured Forward Delay 10 s on a switch, but it still uses 15 s. Why?802.1D bridges use the timers carried in the root's Configuration BPDUs, not their own settings. The Bridge MIB separates the value a bridge is currently using from the value it would advertise if it were root. Configure timers on the root, and on the bridge meant to take over as root, or the change has no effect.
Max Age works like a best-before date stamped when news leaves its source. Each person who passes the news on adds the time it spent with them, and everyone throws it away at roughly the same moment, however many people it passed through. A listener far down the chain gets news that is already older, not news with a fresh date.
saying these in an interview costs you the question
- Each switch runs the Hello, Max Age and Forward Delay it has configured locally.
- Max Age counts from when a BPDU arrived, so distance from the root does not matter.
- The 2 s, 20 s and 15 s defaults are set by an RFC.
- A port forwards 15 s after link-up, after one Forward Delay.
- Hello Time also decides how fast MAC table entries age out.