Network convergence is not one number

Ask how fast a network converges and you will usually get a single number. It is almost always the wrong question, because convergence is not one event. It is a chain, and the chain is only as fast as its slowest link.

The four delays

Detection. How long until anything notices the failure. A physically severed fibre triggers loss-of-light in milliseconds. A link that stays up while silently dropping traffic — a failed optic, a wedged line card, a misprogrammed forwarding table — is invisible to link-state detection entirely. This is what BFD exists for, and it is the delay most often left at default.

Propagation. How long for the news to reach every device that needs it. In a link-state protocol this is LSP or LSA flooding, bounded by generation timers and per-hop processing. In BGP it is update generation, MRAI timers and the depth of the AS path. Propagation is where a large flat topology quietly costs you.

Computation. How long each device takes to recompute. SPF runtime scales with topology size, and SPF back-off timers — which exist to stop a flapping link melting the control plane — deliberately delay the second and third computations. Reasonable protection, real added latency.

Programming. How long to install the new result in forwarding hardware. This is the delay everyone forgets. The control plane has converged, the routing table is correct, and packets are still being dropped because the FIB write to hardware has not completed. With large tables this can dominate every other term in the chain.

Why the datasheet number is not your number

Vendor figures are measured on a small topology, with one failure, on an unloaded control plane, with a table that fits comfortably in silicon.

Production is none of those. Your convergence happens with a full table, during a maintenance window, with a second event arriving before the first has finished — and the interaction between overlapping events is precisely what the benchmark did not test.

Measure the chain, not the total

The useful measurement is per-stage. A traffic generator sending at a known, constant packet rate turns loss directly into time: 1,000 packets per second, 380 packets lost, means 380 ms of outage. Then instrument each stage independently — BFD session-down timestamps, LSP arrival, SPF run duration from the routing process, and FIB programming completion from the platform layer.

The result is a budget you can act on. Almost always, one stage is responsible for the majority of the total, and it is rarely the one that was tuned.

Tuning has a cost, and it is not linear

Aggressive timers trade stability for speed:

• Faster BFD detects real failures sooner and also detects congestion and control-plane load as failures. A BFD session that flaps under load turns a performance problem into a routing problem.
• Faster SPF back-off reconverges sooner and lets a flapping link consume the control plane.
• Shorter MRAI propagates BGP changes faster and increases update churn, which costs CPU on every peer.

The better lever is usually structural: precompute the backup. Loop-free alternates and TI-LFA install a repair path before the failure occurs, so the data plane switches in single-digit milliseconds while the control plane reconverges at its own pace. That converts a convergence problem into a forwarding problem, which is the right place for it.

The stage most designs ignore

Hierarchy. A flat topology means every device recomputes for every change. Summarisation at area or level boundaries contains the blast radius: a link failure inside one area does not trigger SPF everywhere else.

It is unglamorous, it constrains addressing, and it does more for convergence than any timer.

Practically

Write down a convergence budget with a number per stage. Measure against it with traffic, not with show commands. Test with a full table under load, and test overlapping failures.

A single number on a slide is not a design. A budget with four terms, each measured, is.

---