OSPF SPF and LSA Throttling Timers: Tuning Convergence Safely

OSPF converges fast. That is its whole reason for existing. But "fast" is a tuning decision, and the knobs are not where most people look. They are not the hello and dead timers - those control failure detection. The knobs that control what happens after detection are the SPF and LSA throttle timers, and getting them wrong in either direction hurts.

Too slow and you leave convergence time on the table. Too fast and a single flapping link can drive every router in the area into a CPU spiral, recalculating the topology dozens of times per second. This article covers the exponential backoff algorithm behind both throttles, the modern IOS XE defaults (which are not what the older documentation says), and how to verify what your router is actually doing. For the fundamentals, start at the complete OSPF guide.

Two separate throttles, one algorithm

OSPF has two independent throttle mechanisms and they are constantly confused with each other:

All three take the same three arguments, in the same order:

timers throttle spf <start> <hold> <max-wait>
timers throttle lsa <start> <hold> <max-wait>

The algorithm is exponential backoff, and it works like this:

1. A topology change arrives. The router waits start milliseconds, then runs SPF. This is the fast path, and for an isolated event it is the only delay you ever see.
2. If another change arrives while the router is inside the current wait interval, the next SPF is scheduled after hold milliseconds.
3. Each subsequent back-to-back change doubles the hold interval: hold, 2×hold, 4×hold, and so on.
4. The interval is capped at max-wait. It stays there for as long as the churn continues.
5. Once the network is quiet for max-wait milliseconds, the whole thing resets and the next event gets the fast start delay again.

This is exactly the behaviour you want. A single link failure - the common case - converges as fast as the hardware allows. A pathological flap gets progressively throttled until the router is spending a sane amount of CPU on it.

The defaults are not what you think

Half the OSPF tuning advice on the internet is written against IOS defaults from a decade ago: an initial SPF delay of 5 seconds and a hold of 10 seconds. On IOS XE 17.18, from the lab:

R1#show ip ospf
 Initial SPF schedule delay 50 msecs
 Minimum hold time between two consecutive SPFs 200 msecs
 Maximum wait time between two consecutive SPFs 5000 msecs
 Initial LSA throttle delay 50 msecs
 Minimum hold time for LSA throttle 200 msecs
 Maximum wait time for LSA throttle 5000 msecs
 Minimum LSA arrival 100 msecs
 LSA group pacing timer 240 secs

50 ms initial delay, 200 ms hold, 5000 ms max. Modern IOS XE ships with what used to be considered aggressive tuning. Before you reach for the timers, check what you already have. In a great many networks the honest answer is that OSPF convergence is already sub-second and the bottleneck is elsewhere - usually failure detection, which is a job for BFD, not for SPF timers.

Tuning, and verifying it took

router ospf 1
 timers throttle spf 10 100 5000
 timers throttle lsa 10 100 5000
 timers lsa arrival 80
 timers pacing flood 33

R1#show ip ospf
 Initial SPF schedule delay 10 msecs
 Minimum hold time between two consecutive SPFs 100 msecs
 Maximum wait time between two consecutive SPFs 5000 msecs
 Initial LSA throttle delay 10 msecs
 Minimum hold time for LSA throttle 100 msecs
 Maximum wait time for LSA throttle 5000 msecs
 Minimum LSA arrival 80 msecs
 Interface flood pacing timer 33 msecs

The constraint everyone gets wrong

Your LSA arrival timer must be lower than your neighbours' LSA throttle hold timer. If a neighbour re-originates an LSA every 100 ms and you refuse to accept a new instance more often than every 200 ms, you will silently discard half of their updates and your LSDB will lag behind reality.

The safe rule: set timers lsa arrival to roughly 80% of the smallest timers throttle lsa hold value anywhere in the area. In the config above, 80 ms arrival against a 100 ms hold. Get this backwards and you have built an intermittent, load-dependent, extremely difficult routing bug.

Watching the backoff happen

show ip ospf statistics is the command nobody runs and everybody should. It logs every SPF run, how long each phase took, and - critically - why it ran.

From the lab, after flapping a link between R1 and R2 twice in quick succession:

R1#show ip ospf statistics
  Area 0: SPF algorithm executed 13 times

  SPF calculation time
Delta T   Intra   D-Intra Summ    D-Summ  Ext     D-Ext   Total   Reason
00:04:29   0       0       0       0       0       0       0      X
00:04:26   0       1       0       0       0       0       1      R
00:03:07   0       0       0       0       0       0       0      X
00:02:38   0       0       0       0       0       0       0      X
00:00:14   0       0       0       1       0       0       1      R, SN, X
00:00:14   0       0       1       0       0       0       1      R
00:00:13   1       0       0       0       0       0       1      R, N
00:00:09   0       0       0       1       0       0       1      R
00:00:08   0       0       1       0       0       0       1      R, N, SN, X
00:00:07   0       0       0       0       0       0       0      R

Read the Delta T column bottom-up and you can watch the throttle working: a burst of SPF runs clustered at 14, 13, 9, 8 and 7 seconds ago, each triggered by an LSA change during the flap. The Reason column tells you what changed:

Notice that only R and N reasons trigger the full intra-area SPF (the expensive Dijkstra). Summary and external changes only require a partial recalculation, which is why the Intra column is mostly zero. That is the point of the OSPF LSA hierarchy, visible in a single command.

Two more timers worth knowing

LSA group pacing (timers pacing lsa-group, default 240 s) controls how OSPF batches its LSA refresh, checksum and aging work. In a very large database, the default groups too much work together and you get periodic CPU spikes every four minutes. Lowering it spreads the load. In an area with fewer than a few thousand LSAs, do not touch it.

Flood pacing (timers pacing flood, default 33 ms) controls the interval between LSA flood packets on an interface. Lower means faster flooding of a large update set, at the cost of a burst on the wire that a slow neighbour may not keep up with. The default is fine.

How to actually make OSPF converge fast

Tuning SPF timers is the last step, not the first. In priority order:

1. Detect failures fast. Sub-second detection comes from BFD, not from hello timers. bfd interval 300 min_rx 300 multiplier 3 plus ip ospf bfd gets you failure detection in under a second without the hello overhead of a 1-second dead timer.
2. Make the SPF cheap. A smaller LSDB runs a faster Dijkstra. That means proper area design, summarisation at ABRs, and prefix suppression on transit links.
3. Then tune the timers, and only if measurement shows they are the bottleneck.
4. Then consider LFA / remote LFA for pre-computed backup paths, which converges in the forwarding plane without waiting for SPF at all.

An SPF run over a 500-LSA area on modern hardware takes single-digit milliseconds. If your convergence is measured in seconds, the SPF timers are almost certainly not why.

Troubleshooting checklist

1. Convergence slower than expected? Check show ip ospf statistics for the actual SPF frequency and duration, and show ip ospf | include SPF schedule|hold time for the timers in effect. Do not assume the defaults.
2. Router CPU spiking during a flap? Raise the hold and max-wait values so the backoff engages sooner. Then go and fix the flapping link.
3. LSDB out of sync intermittently? Check that your timers lsa arrival is lower than every neighbour's LSA throttle hold. This is the classic cause and it is very hard to spot.
4. Periodic CPU spikes with no topology change? LSA group pacing on a very large database. Lower timers pacing lsa-group.
5. Tuning applied but no change? The throttle timers are per-process, not per-area or per-interface. Confirm you are under the right router ospf process.

Key takeaways

• SPF throttle protects your CPU. LSA throttle protects everyone else's. They are different mechanisms with an identical-looking syntax.
• Both use exponential backoff: start for the first event, then hold doubling each time up to max-wait, resetting after a quiet period.
• IOS XE 17.x already defaults to 50/200/5000 ms, not the 5000/10000/10000 you will read in older guides. Check before you tune.
• timers lsa arrival must be lower than the smallest LSA throttle hold in the area, or you will silently drop your neighbours' updates.
• show ip ospf statistics shows every SPF run, its cost, and its reason code. It is the only way to see the throttle working.
• For real convergence gains, fix detection (BFD) and database size (areas, summarisation, prefix suppression) before touching the timers.

Next in the expert OSPF series: prefix suppression, which shrinks the routing table by removing the transit links nobody needs to reach. The full cluster index lives on the OSPF pillar guide.