> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # OSPF SPF and LSA Throttling Timers: Tuning Convergence Safely - URL: https://www.pinglabz.com/ospf-spf-lsa-throttling-timers/ - Published: 2026-07-12T07:18:22.000Z - Updated: 2026-08-24T09:44:16.000Z - Description: SPF and LSA throttle timers control what OSPF does after a failure is detected. Learn the exponential backoff algorithm, the modern IOS XE defaults, and how to tune convergence without letting a flapping link spike every CPU in the area. - Author: Jaime - Tags: OSPF, Labs, CCIE, #Import 2026-08-01 19:54 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](https://www.pinglabz.com/ospf/). ## Two separate throttles, one algorithm OSPF has two independent throttle mechanisms and they are constantly confused with each other: SPF throttle `timers throttle spf` Governs how soon the router runs the Dijkstra calculation after receiving a topology change, and how quickly it will run it again. Protects **your CPU**. LSA throttle `timers throttle lsa` Governs how soon *this router* re-originates one of its *own* LSAs after a change. Protects **everyone else's CPU** from your flapping interface. LSA arrival `timers lsa arrival` The minimum interval at which the router will *accept* a new instance of the same LSA from a neighbor. Your defence against a neighbor who has tuned their LSA throttle too aggressively. All three take the same three arguments, in the same order: ``` timers throttle spf timers throttle lsa ``` 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 behavior 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 neighbors' LSA throttle hold timer.** If a neighbor 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: **R**A Router LSA (Type 1) changed. Somebody's link went up or down. **N**A Network LSA (Type 2) changed. A DR election or a change on a multiaccess segment. **SN / SA**A Summary LSA (Type 3 / Type 4) changed. An inter-area route moved. **X**An External LSA (Type 5) changed. A redistributed route moved. 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 neighbor 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](https://www.pinglabz.com/ospf-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 neighbor'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 neighbors' 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](https://www.pinglabz.com/ospf-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](https://www.pinglabz.com/ospf/).