skip to content

Why is lowering just one 802.1D spanning-tree timer, such as Max Age or Forward Delay, to speed up convergence risky?

level: seniorimportance: nice to knowfreq 12%

answer

  1. the timers are coupled
  2. two inequalities from the IEEE
  3. diameter and message age
  4. the root's values, and its backup's

basics

~20 s

The 802.1D timers are coupled: the IEEE requires 2 x (Hello + 1 s) <= Max Age <= 2 x (Forward Delay - 1 s). Changing one alone can expire information too early or let ports forward before the tree settles, causing loops.

solid answer

~50 s

The IEEE standard relates the three timers: `2 x (Forward Delay - 1 s) >= Max Age >= 2 x (Hello Time + 1 s)`, and its defaults (2, 20, 15 s) assume a bridge diameter of seven. Lowering **Forward Delay** alone, say to 8 s with Max Age still 20, breaks the upper bound: 2 x 7 = 14 < 20, so ports can forward before stale information has expired everywhere, opening a temporary loop. Lowering **Max Age** below what the diameter needs means distant bridges receive BPDUs already near expiry, discard them, and claim to be root. Raising **Hello** alone, to 10 s, breaks the lower bound (22 > 20). Two practical traps: only the root's values count, so a change on another bridge does nothing; and if the backup root has different values, failover silently changes them. RSTP is the usual answer to slow convergence.

code

pseudocode · 12 lines
pseudocode
// IEEE 802.1D timer consistency check, values in seconds
function timers_consistent(hello, max_age, fwd_delay):
    if hello < 1 or hello > 10: return false          // RFC 4188 range
    if max_age < 6 or max_age > 40: return false      // RFC 4188 range
    if fwd_delay < 4 or fwd_delay > 30: return false  // RFC 4188 range
    if max_age < 2 * (hello + 1): return false        // IEEE lower bound
    if max_age > 2 * (fwd_delay - 1): return false    // IEEE upper bound
    return true

timers_consistent(2, 20, 15)   // true:  6 <= 20 <= 28
timers_consistent(2, 20, 8)    // false: 20 > 2 * (8 - 1) = 14
timers_consistent(10, 20, 15)  // false: 20 < 2 * (10 + 1) = 22

go deeper

for a junior

Recall that the three spanning-tree timers have defaults chosen together and are set on the root bridge.

for a middle

Explain what each timer protects against, so you can say what breaks when one is shortened.

for a senior

Check both IEEE inequalities and the diameter before any change, apply it to the root and backup root alike, and prefer RSTP over aggressive tuning.

for a principal

Frame timer tuning as a symptom of an oversized layer-2 domain and argue for shrinking that domain or routing instead of squeezing seconds out of 802.1D.

## Why people tune the timers Classic **IEEE 802.1D** spanning tree is slow: a port waits one **Forward Delay** listening and one learning (30 s at the IEEE default of 15 s), and a bridge that loses its root information through an indirect failure first waits for it to reach **Max Age** (20 s). The tempting fix is to lower the timers. The Bridge MIB, RFC 4188, lets an operator set them within ranges: Hello Time 1-10 s, Max Age 6-40 s, Forward Delay 4-30 s. It also notes that 802.1D "specifies that the range for this parameter is related to" the others, and that is the catch. ## The coupling rule The IEEE standard requires two inequalities (its text is not in an RFC): - `Max Age >= 2 x (Hello Time + 1 s)` - `Max Age <= 2 x (Forward Delay - 1 s)` At the defaults: 2 x (2 + 1) = 6 <= 20 <= 28 = 2 x (15 - 1), so they hold with room to spare. The defaults are also sized for a **bridge diameter of seven**, the IEEE's assumption about how many bridges information may cross. | Change made alone | Rule it breaks | What can go wrong | |---|---|---| | Forward Delay 15 -> 8 s | 20 > 2 x (8 - 1) = 14 | ports forward before old information has expired everywhere: a transient loop | | Max Age 20 -> 6 s | none, but it can be too small for the diameter | distant bridges discard BPDUs on arrival and claim root | | Hello 2 -> 10 s | 20 < 2 x (10 + 1) = 22 | stored information can expire between two Hellos | | Hello 2 -> 1 s | none | more BPDUs to process; harmless in itself, gains little alone | ## Max Age and the diameter Every Configuration BPDU carries a **Message Age** that starts at zero at the root and grows at each relay. A bridge discards stored information when its age reaches Max Age. So Max Age must cover the age information has already accumulated on its way to the farthest bridge, plus enough margin to survive a lost Hello or two. Set it too low and the bridges at the edge of the network receive information that expires almost immediately. They then believe no root exists beyond that port, may elect themselves root and make their ports designated. Two bridges that both think they are designated on a segment will both forward, which is exactly the loop spanning tree exists to prevent. ## Forward Delay and the transition Listening and learning exist so that, before a port starts forwarding, every bridge has heard the new topology and stopped forwarding on ports that should now block. Forward Delay must therefore be long enough for information to cross the network and for old information to time out. Shortening it without shortening Max Age to match violates the upper bound and lets a port forward while somewhere else an old path is still open. ## Two operational traps 1. **Only the root's values count.** Bridges use the timers carried in the root's Configuration BPDUs. RFC 4188 separates the values a bridge is using from the values it would advertise "when this bridge is acting as the root". Tuning a non-root bridge changes nothing until it becomes root. 2. **The backup root must match.** If the primary root fails, the next root's configured timers take over. A tuned primary with a default backup silently reverts the whole tree to 2/20/15 during exactly the failure it was tuned for. ## A safe way to reason about it 1. Reduce the diameter first: fewer bridges in the layer-2 domain. 2. Derive Max Age from the diameter and Hello Time, then Forward Delay from Max Age. 3. Check both inequalities. 4. Apply the same values on the root and on the backup root. Even tuned to the bottom of the allowed ranges, 802.1D's recovery is measured in seconds, not milliseconds. The usual answer is **RSTP** (IEEE 802.1w, folded into 802.1D-2004), whose handshake makes most transitions independent of these timers, or a routed design that removes the large layer-2 domain altogether.

  • With Hello Time 2 s, what is the smallest Forward Delay that still allows the default Max Age of 20 s?
    The IEEE rule needs Max Age <= 2 x (Forward Delay - 1 s), so 20 <= 2 x (Forward Delay - 1), which gives Forward Delay >= 11 s. Anything lower forces Max Age down too, and Max Age in turn must stay at least 2 x (2 + 1) = 6 s and large enough for the network's diameter.
  • You tuned the root's timers and convergence improved, until the root failed. Then it was slow again. Why?
    Bridges use the timers carried in the current root's BPDUs. When the primary failed, the backup root took over and advertised its own configured values, probably still the IEEE defaults. Configure identical timers on every bridge that may become root.

saying these in an interview costs you the question

  • Setting the timers on any switch changes them for the whole network.
  • Forward Delay can be lowered freely; it only affects how fast host ports come up.
  • Max Age can be set independently of Hello Time and Forward Delay.
  • Tuned 802.1D timers converge as fast as RSTP.
  • The 2 s Hello default comes from an RFC.