↓ Skip to main content
KAZULOG.INFO
  1. Network Articles/
  2. OSPF Articles/

OSPF Convergence Timers (SPF / LSA Throttling)

Table of Contents

OSPF Convergence Timers (SPF / LSA Throttling)

When a link goes down or a cost changes, an OSPF router rebuilds its LSA and every router that receives it recalculates its routes with SPF. For a single change, rebuilding and recalculating immediately converges fastest. But when a link flaps, repeating that work on every change overloads the CPU and the network settles more slowly, not faster.

That is why OSPF implementations deliberately delay rebuilding LSAs and running SPF, and stretch that delay as changes keep coming. This article works through how that delay is defined by the RFCs and by Cisco, then confirms it on IOS XR with millisecond timestamps.

Periodic LSA refresh (1800 seconds) and LSA aging are covered in OSPF LSAs and the LSA header.

What RFC 2328 defines

RFC 2328 sets fixed lower bounds on generating and receiving LSAs. Section 12.4 says this about generation.

… two instances of the same LSA may not be originated within MinLSInterval of each other. It may be necessary to delay the origination of the next LSA instance by up to MinLSInterval.

The same section states that a new LSA is originated only when its contents change. If a change is made and then reverted while the router is waiting, so that the contents match the LSA already sent, no new LSA is built.

The bound on the receiving side is in Section 13, step (5)(a).

If there is already a database copy, and if the database copy was received via flooding and installed less than MinLSArrival seconds ago, discard the new LSA (without acknowledging it).

Because no acknowledgement comes back, the sender retransmits the LSA. This check applies only to LSAs received via flooding, not to LSAs the router originates itself (Appendix G.2).

By contrast, RFC 2328 defines no timer for when SPF runs. Delaying SPF is left to implementations and to RFC 8405.

The RFC values and the IOS XR defaults line up as follows. The IOS XR values are visible in show ospf.

Item RFC 2328 IOS XR default Configuration command
Minimum interval between rebuilding the same LSA MinLSInterval 5 s 200 ms timers throttle lsa all
Minimum interval for accepting the same LSA MinLSArrival 1 s 100 ms timers lsa min-arrival
How LSA generation is delayed Not defined initial 50 / min 200 / max 5000 ms timers throttle lsa all
How SPF is delayed Not defined initial 50 / min 200 / max 5000 ms timers throttle spf

The Minimum LSA interval line in show ospf reports the same value as the second number (hold) of the LSA throttle. In this lab, setting hold to 2000 ms changes that line to Minimum LSA interval 2000 msecs.

Cisco’s exponential backoff

On IOS XR, timers throttle spf (SPF) and timers throttle lsa all (LSA generation) take three values.

Value Meaning
start Delay from an event in a quiet network until SPF runs or the LSA is built
hold Base delay once events keep arriving. It doubles on each successive run
max-wait Upper bound on the delay

Cisco’s OSPF Shortest Path First Throttling guide describes when it doubles and what happens at the maximum.

Notice that the wait interval between SPF calculations doubles when at least one topology change event is received during the previous wait interval.

Once the maximum wait time is reached, the wait interval remains the same until the topology stabilizes and no event is received in that interval.

With timers throttle spf 1000 2000 16000, for example, the delay grows 1, 2, 4, 8 and 16 seconds while events keep coming, then stops at 16 seconds. Three points matter here.

  • The delay is measured from the previous SPF run (or LSA build), not from the event. The actual run therefore happens at whichever is later: the previous run plus the delay, or the event plus start
  • Events that arrive during the delay are folded into the next single run. Ten changes collapsing into three SPF runs is perfectly normal
  • Once at the maximum, the delay returns to start if no event arrives for that same amount of time. That is the “stabilizes” condition

Because both the sender and the receiver hold back, the interval you observe is set by whichever is longer: LSA generation on the sender or SPF on the receiver. With the defaults on both, the sender is what you see first.

The defaults of 50 / 200 / 5000 ms and the 100 ms acceptance interval are the values Cisco’s notice about the default change aligned IOS with, stating that they match the IOS XR defaults.

How RFC 8405 delays SPF

Doubling behaves differently from one implementation to another. RFC 8405 was written to make it uniform. Instead of doubling, it switches the delay based on the time elapsed since the first change.

Parameter Recommended default Meaning
INITIAL_SPF_DELAY 50 ms Delay for the first change in a quiet network
SHORT_SPF_DELAY 200 ms Delay shortly after the first change
LONG_SPF_DELAY 5000 ms Delay while changes keep coming
TIME_TO_LEARN 500 ms Expected time for all information about one failure to arrive
HOLDDOWN 10000 ms Time before the network is considered quiet again

IOS XR has no option to select the RFC 8405 algorithm for OSPF. timers throttle spf accepts only three numbers, and there is no matching keyword under spf either (checked with ? in configuration mode). IS-IS has spf-interval ietf; OSPF does not. The lab below therefore measures Cisco’s exponential backoff.

Lab verification

Lab setup

Three IOS XR routers (XRd 26.1.1) in a line, all in area 0. The router-to-router links use network type point-to-point with a cost of 10.

Lab topology
Router Router ID Role
R1 1.1.1.1 Observation point. Watches the SPF delay and MinLSArrival. Only R1 gets timers throttle spf and timers lsa min-arrival
R2 2.2.2.2 Event source. Changes the cost of its link toward R3 so its Router-LSA is rebuilt. Only R2 gets timers throttle lsa all
R3 3.3.3.3 Beyond R2. The cost of 3.3.3.3/32 as seen from R1 changes on every event

One event means logging in to R2 over SSH, changing cost and committing. Staying in configuration mode and repeating only cost and commit produces a change roughly every 1.8 seconds. All timestamps come from router-side traces and syslog in milliseconds, and the capture is taken between R1 and R2.

Lab STEPs

STEP Operation What it shows
0 Defaults, nothing changed The default values in show ospf and reachability from R1 to R3
1 Twelve events about 1.8 seconds apart with the defaults Even at 50 / 200 / 5000 ms the delay doubles and stops at 5000 ms
2 timers throttle spf 1000 2000 16000 on R1; ten events 1.8 s apart, three 24 s apart, two 40 s apart The SPF delay grows 1 → 2 → 4 → 8 → 16 s, holds there, and returns to start once quiet
3 Revert R1, set timers throttle lsa all 1000 2000 16000 on R2, same event pattern LSA generation is delayed the same way and returns to start once quiet
4 Keep R2 as is; alternate the cost between 20 and 10 ten times about 1.8 s apart No new LSA is built when the contents revert during the delay
5 Revert R2, set timers lsa min-arrival 3000 on R1; ten events 1.8 s apart New LSAs arriving within 3 seconds are discarded without an acknowledgement
6 Keep R1 as is; generate only two events, then stay quiet The discarded LSA is retransmitted by the sender and then accepted
7 Set the SPF delay on R1 and LSA generation delay on R2 at the same time; 30 events 1.8 s apart The two delays add up, and LSA generation stays at its maximum
8 Revert everything (final state) show ospf and router ospf match STEP 0

STEP 0: Confirming the defaults

Here is show ospf on R1. SPF and LSA throttling are both 50 / 200 / 5000 ms and Minimum LSA arrival is 100 ms — orders of magnitude shorter than the 5 seconds and 1 second in RFC 2328.

STEP 0 timer lines from show ospf on R1
 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 interval 200 msecs. Minimum LSA arrival 100 msecs
 LSA refresh interval 1800 seconds
 Flood pacing interval 33 msecs. Retransmission pacing interval 66 msecs

STEP 1: Twelve events about 1.8 seconds apart with the defaults

Twelve events with the defaults untouched. These are the SPF runs on R1.

STEP 1 SPF runs on R1 (excerpt of show ospf trace spf)
238  Sep 16 11:33:21.575  ospf_run_spf: Begin SPF
269  Sep 16 11:33:23.576  ospf_run_spf: Begin SPF
300  Sep 16 11:33:25.377  ospf_run_spf: Begin SPF
331  Sep 16 11:33:27.178  ospf_run_spf: Begin SPF
362  Sep 16 11:33:28.951  ospf_run_spf: Begin SPF
393  Sep 16 11:33:32.153  ospf_run_spf: Begin SPF
424  Sep 16 11:33:37.154  ospf_run_spf: Begin SPF
455  Sep 16 11:33:42.155  ospf_run_spf: Begin SPF

Listing the intervals shows the delay stretching.

SPF on R1 (UTC) Since the previous SPF
11:33:21.575 —
11:33:23.576 2000 ms
11:33:25.377 1801 ms
11:33:27.178 1801 ms
11:33:28.951 1773 ms
11:33:32.153 3202 ms
11:33:37.154 5001 ms
11:33:42.155 5001 ms

While the delay grows 200 → 400 → 800 → 1600 ms it stays shorter than the event spacing of about 1.8 seconds, so the events set the pace. Once the delay reaches 3200 ms it overtakes the events, the delay itself becomes the interval, and it tops out at 5000 ms. Twelve changes collapsed into eight SPF runs.

Looking at the same window on R2, the times at which LSAs were built line up with the SPF runs on R1.

STEP 1 Router-LSAs built on R2 (excerpt of show ospf trace all)
72   Sep 16 11:33:21.497  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x80000005 vrfid 0x60000000
73   Sep 16 11:33:23.476  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x80000006 vrfid 0x60000000
74   Sep 16 11:33:25.321  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x80000007 vrfid 0x60000000
75   Sep 16 11:33:27.122  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x80000008 vrfid 0x60000000
76   Sep 16 11:33:28.894  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x80000009 vrfid 0x60000000
77   Sep 16 11:33:32.095  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x8000000a vrfid 0x60000000
78   Sep 16 11:33:37.096  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x8000000b vrfid 0x60000000
79   Sep 16 11:33:42.095  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x8000000c vrfid 0x60000000

Each SPF on R1 runs 50 to 78 ms after the LSA arrives, so the interval visible here is the sender’s LSA generation delay, not the receiver’s. To watch the receiver’s SPF delay, R1 has to be made slower, which is the next STEP.

STEP 2: Setting the SPF delay to 1000 / 2000 / 16000 ms

Only R1 changes.

STEP 2 configuration committed on R1
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Wed Sep 16 11:39:59.786 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router ospf 1
 timers throttle spf 1000 2000 16000
!
end
STEP 2 SPF lines from show ospf on R1
 Initial SPF schedule delay 1000 msecs
 Minimum hold time between two consecutive SPFs 2000 msecs
 Maximum wait time between two consecutive SPFs 16000 msecs

With that in place, the event spacing widens: ten events about 1.8 seconds apart, then three 24 seconds apart, then two 40 seconds apart.

STEP 2 SPF runs on R1 (excerpt of show ospf trace spf)
486  Sep 16 11:40:47.626  ospf_run_spf: Begin SPF
517  Sep 16 11:40:49.626  ospf_run_spf: Begin SPF
548  Sep 16 11:40:53.627  ospf_run_spf: Begin SPF
579  Sep 16 11:41:01.628  ospf_run_spf: Begin SPF
610  Sep 16 11:41:17.629  ospf_run_spf: Begin SPF
641  Sep 16 11:41:33.630  ospf_run_spf: Begin SPF
672  Sep 16 11:41:58.225  ospf_run_spf: Begin SPF
703  Sep 16 11:42:22.926  ospf_run_spf: Begin SPF
734  Sep 16 11:43:10.426  ospf_run_spf: Begin SPF
765  Sep 16 11:43:51.227  ospf_run_spf: Begin SPF

Matching those against the times R1 installed each LSA in its database:

LSA installed on R1 SPF on R1 Since the previous SPF Reading
11:40:46.625 11:40:47.626 — start 1000 (1001 ms after the install)
48.427 11:40:49.626 2000 ms hold 2000
50.125 / 51.726 / 53.526 11:40:53.627 4001 ms Three arrivals during the delay folded into one run
56.725 11:41:01.628 8001 ms —
11:41:01.725 11:41:17.629 16001 ms Maximum reached
06.725 / 32.586 11:41:33.630 16001 ms The second one arrived 14.96 s after the previous SPF, so it stays at the maximum
11:41:57.224 11:41:58.225 24595 ms Arrived 23.59 s after the previous SPF, so it is back to start and runs 1001 ms later
11:42:21.926 11:42:22.926 24701 ms start
11:43:09.426 11:43:10.426 47500 ms start
11:43:50.226 11:43:51.227 40801 ms start

One table shows all three behaviours: doubling 1 → 2 → 4 → 8 → 16 seconds and stopping, holding at the maximum as long as the next arrival lands within the delay, and returning to start when nothing arrives for that long. The boundary is the 16 second maximum: an arrival 14.96 seconds after the SPF did not reset it, one 23.59 seconds after did.

STEP 3: Setting the LSA generation delay to 1000 / 2000 / 16000 ms

R1 goes back to the defaults and R2 is slowed down instead.

STEP 3 configuration committed on R2
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Wed Sep 16 11:51:24.226 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router ospf 1
 timers throttle lsa all 1000 2000 16000
!
end
STEP 3 LSA throttle lines from show ospf on R2
 Initial LSA throttle delay 1000 msecs
 Minimum hold time for LSA throttle 2000 msecs
 Maximum wait time for LSA throttle 16000 msecs
 Minimum LSA interval 2000 msecs. Minimum LSA arrival 100 msecs

Minimum LSA interval now reports 2000 ms, the same as hold. With the same event pattern, the interval between LSA builds stretches.

STEP 3 Router-LSAs built on R2 (excerpt of show ospf trace all)
93   Sep 16 11:52:12.249  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x8000001a vrfid 0x60000000
94   Sep 16 11:52:14.249  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x8000001b vrfid 0x60000000
95   Sep 16 11:52:18.250  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x8000001c vrfid 0x60000000
96   Sep 16 11:52:26.250  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x8000001d vrfid 0x60000000
97   Sep 16 11:52:42.250  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x8000001e vrfid 0x60000000
98   Sep 16 11:53:01.952  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x8000001f vrfid 0x60000000
99   Sep 16 11:53:26.738  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x80000020 vrfid 0x60000000
100  Sep 16 11:54:14.345  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x80000021 vrfid 0x60000000
101  Sep 16 11:54:55.222  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x80000022 vrfid 0x60000000
Event on R2 LSA built After the event Since the previous build
11:52:11.246 11:52:12.249 1003 ms —
12.939 11:52:14.249 1310 ms 2000 ms
14.625 11:52:18.250 3625 ms 4001 ms
18.460 11:52:26.250 7790 ms 8000 ms
Six events from 20.439 to 29.949 11:52:42.250 14114 ms 16000 ms
11:53:00.949 11:53:01.952 1003 ms 19702 ms

It stretches exactly like SPF and reaches the maximum. The second row is 1310 ms after its event but 2000 ms after the previous build, which is the delay being measured from the previous build. In the last row, no event had arrived for 18.7 seconds, so the delay was back to start and the LSA was built 1003 ms after the event. Fifteen changes collapsed into nine LSAs.

STEP 4: No LSA is built when the contents revert during the delay

R2 keeps its configuration and the cost alternates between 20 and 10. Because the change is reverted while the router waits, the contents at build time match the LSA already sent.

STEP 4 Router-LSAs built on R2 (excerpt of show ospf trace all)
102  Sep 16 12:01:25.953  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x80000023 vrfid 0x60000000
103  Sep 16 12:01:28.141  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x80000024 vrfid 0x60000000
104  Sep 16 12:01:36.142  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x80000025 vrfid 0x60000000
105  Sep 16 12:01:52.142  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x80000026 vrfid 0x60000000

Ten events produced only four LSAs. The builds that produced nothing are recorded in the trace as well.

STEP 4 record of a build that was skipped on R2
137  Sep 16 12:01:32.141  ospf_build_rtr_lsa: no change in router LSA, area 0.0.0.0 rtrid 2.2.2.2 instance 0x60000000 db_nsf_active 0

After 0x80000024 was built at 12:01:28.141, the build at 12:01:32.141 ended in no change in router LSA and no LSA was flooded. That is exactly what RFC 2328 Section 12.4 requires: a new LSA only when the contents change. The capture has no LS Update at that time either.

STEP 5: Setting MinLSArrival to 3000 ms

R2 returns to the defaults and the receive-side bound on R1 is widened to 3000 ms. The default is 100 ms, but the sender’s own bound (200 ms by default) prevents LSAs from ever arriving that fast, so the receive side has to be widened to watch anything actually being discarded.

STEP 5 configuration committed on R1
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Wed Sep 16 12:08:57.065 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router ospf 1
 timers lsa min-arrival 3000
!
end
STEP 5 LSA acceptance line from show ospf on R1
 Minimum LSA interval 200 msecs. Minimum LSA arrival 3000 msecs

R2 built eight LSAs about 1.8 seconds apart.

STEP 5 Router-LSAs built on R2 (excerpt of show ospf trace all)
106  Sep 16 12:09:43.201  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x80000027 vrfid 0x60000000
107  Sep 16 12:09:44.976  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x80000028 vrfid 0x60000000
108  Sep 16 12:09:46.711  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x80000029 vrfid 0x60000000
109  Sep 16 12:09:48.501  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x8000002a vrfid 0x60000000
110  Sep 16 12:09:50.388  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x8000002b vrfid 0x60000000
111  Sep 16 12:09:53.589  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x8000002c vrfid 0x60000000
112  Sep 16 12:09:58.589  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x8000002d vrfid 0x60000000
113  Sep 16 12:10:03.589  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x8000002e vrfid 0x60000000

R1 installed only six of them.

STEP 5 database installs on R1 (excerpt of show ospf trace all)
258  Sep 16 12:09:46.725  db_install: FC: LSA_CHG: Changed Rtr LSA: ar 0.0.0.0 lsid 2.2.2.2 advrtr 2.2.2.2 seq 0x80000029
259  Sep 16 12:09:46.725  db_install: FC: SCHED_SPF: ar 0.0.0.0 type 1 lsid 2.2.2.2 advrtr 2.2.2.2
264  Sep 16 12:09:50.393  db_install: FC: LSA_CHG: Changed Rtr LSA: ar 0.0.0.0 lsid 2.2.2.2 advrtr 2.2.2.2 seq 0x8000002b
265  Sep 16 12:09:50.393  db_install: FC: SCHED_SPF: ar 0.0.0.0 type 1 lsid 2.2.2.2 advrtr 2.2.2.2
270  Sep 16 12:09:53.592  db_install: FC: LSA_CHG: Changed Rtr LSA: ar 0.0.0.0 lsid 2.2.2.2 advrtr 2.2.2.2 seq 0x8000002c
271  Sep 16 12:09:53.592  db_install: FC: SCHED_SPF: ar 0.0.0.0 type 1 lsid 2.2.2.2 advrtr 2.2.2.2
276  Sep 16 12:09:58.594  db_install: FC: LSA_CHG: Changed Rtr LSA: ar 0.0.0.0 lsid 2.2.2.2 advrtr 2.2.2.2 seq 0x8000002d
277  Sep 16 12:09:58.594  db_install: FC: SCHED_SPF: ar 0.0.0.0 type 1 lsid 2.2.2.2 advrtr 2.2.2.2
282  Sep 16 12:10:03.593  db_install: FC: LSA_CHG: Changed Rtr LSA: ar 0.0.0.0 lsid 2.2.2.2 advrtr 2.2.2.2 seq 0x8000002e
283  Sep 16 12:10:03.593  db_install: FC: SCHED_SPF: ar 0.0.0.0 type 1 lsid 2.2.2.2 advrtr 2.2.2.2
LSA built by R2 Arrived at R1 What R1 did Since the previous install
0x80000027 21:09:43.223 Installed, SPF, acknowledged —
0x28 45.023 Discarded 1.80 s
0x29 46.722 Installed, SPF, acknowledged 3.499 s
0x2a 48.522 Discarded 1.80 s
0x2b 50.390 Installed, SPF, acknowledged 3.668 s
0x2c 53.590 Installed, SPF, acknowledged 3.199 s
0x2d 58.591 Installed, SPF, acknowledged 5.002 s
0x2e 21:10:03.591 Installed, SPF, acknowledged 4.999 s

0x28 and 0x2a arrived within 3 seconds of the previous install: not added to the database, no SPF, and no acknowledgement. In the capture there are eight LS Updates but only six LS Acknowledges.

STEP 5 LS Update and LS Acknowledge between R1 and R2
   13  56.147212    10.0.12.2 → 224.0.0.5    OSPF 146 LS Update
   16  57.946875    10.0.12.2 → 224.0.0.5    OSPF 146 LS Update
   17  58.152029    10.0.12.1 → 224.0.0.5    OSPF 78 LS Acknowledge
   18  59.646385    10.0.12.2 → 224.0.0.5    OSPF 146 LS Update
   19  61.446002    10.0.12.2 → 224.0.0.5    OSPF 146 LS Update
   20  61.651004    10.0.12.1 → 224.0.0.5    OSPF 78 LS Acknowledge
   21  63.314147    10.0.12.2 → 224.0.0.5    OSPF 146 LS Update
   22  65.319472    10.0.12.1 → 224.0.0.5    OSPF 78 LS Acknowledge
   25  66.514402    10.0.12.2 → 224.0.0.5    OSPF 146 LS Update
   26  68.518464    10.0.12.1 → 224.0.0.5    OSPF 78 LS Acknowledge
   27  71.515036    10.0.12.2 → 224.0.0.5    OSPF 146 LS Update
   28  73.520027    10.0.12.1 → 224.0.0.5    OSPF 78 LS Acknowledge
   31  76.514801    10.0.12.2 → 224.0.0.5    OSPF 146 LS Update
   32  78.518679    10.0.12.1 → 224.0.0.5    OSPF 78 LS Acknowledge

Each acknowledgement comes about 2005 ms after the install (delayed acknowledgement).

STEP 6: A discarded LSA is retransmitted

No retransmission appeared in STEP 5. With a new instance built every 1.8 seconds, a discarded instance is superseded before the 5 second retransmission timer expires. So R1 keeps its configuration and only two events are generated, followed by silence.

STEP 6 LS Update and LS Acknowledge between R1 and R2
    2   4.086032    10.0.12.2 → 224.0.0.5    OSPF 146 LS Update
    4   5.984502    10.0.12.2 → 224.0.0.5    OSPF 146 LS Update
    5   6.090964    10.0.12.1 → 224.0.0.5    OSPF 78 LS Acknowledge
    7  10.856835    10.0.12.2 → 10.0.12.1    OSPF 146 LS Update
    8  12.861767    10.0.12.1 → 224.0.0.5    OSPF 78 LS Acknowledge

No.2 and No.4 are the two LSAs R2 built. No.4 arrived 1.9 seconds later and was discarded, so no acknowledgement follows it. No.7 is the retransmission, sent to R1 as a unicast (10.0.12.1) rather than to the multicast address 224.0.0.5. It is 4.872 seconds after the original, matching the 5 second RxmtInterval.

Download the pcap of the packet in the capture above (No.7, retransmitted LS Update)

Here is the same event from R1. After installing 0x80000031 at 12:21:37.227, it installed 0x80000032 only when the retransmission arrived at 12:21:43.998, 6.771 seconds after the first install.

STEP 6 database installs on R1 (excerpt of show ospf trace all)
308  Sep 16 12:21:37.227  db_install: FC: LSA_CHG: Changed Rtr LSA: ar 0.0.0.0 lsid 2.2.2.2 advrtr 2.2.2.2 seq 0x80000031
309  Sep 16 12:21:37.227  db_install: FC: SCHED_SPF: ar 0.0.0.0 type 1 lsid 2.2.2.2 advrtr 2.2.2.2
314  Sep 16 12:21:43.998  db_install: FC: LSA_CHG: Changed Rtr LSA: ar 0.0.0.0 lsid 2.2.2.2 advrtr 2.2.2.2 seq 0x80000032
315  Sep 16 12:21:43.998  db_install: FC: SCHED_SPF: ar 0.0.0.0 type 1 lsid 2.2.2.2 advrtr 2.2.2.2

A single capture holds the whole sequence: discard without acknowledging, and the sender resending.

STEP 7: Delaying both SPF and LSA generation

Production networks set both. The SPF delay on R1 and the LSA generation delay on R2 were configured at the same time, followed by 30 events about 1.8 seconds apart.

STEP 7 configuration committed on R1
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Wed Sep 16 12:27:23.959 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router ospf 1
 timers throttle spf 1000 2000 16000
 no timers lsa min-arrival 3000
!
end
STEP 7 Router-LSAs built on R2
118  Sep 16 12:28:17.923  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x80000033 vrfid 0x60000000
119  Sep 16 12:28:19.923  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x80000034 vrfid 0x60000000
120  Sep 16 12:28:23.923  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x80000035 vrfid 0x60000000
121  Sep 16 12:28:31.923  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x80000036 vrfid 0x60000000
122  Sep 16 12:28:47.924  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x80000037 vrfid 0x60000000
123  Sep 16 12:29:03.924  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x80000038 vrfid 0x60000000
124  Sep 16 12:29:19.925  ospf_build_rtr_lsa: area 0.0.0.0 rtrid 2.2.2.2 seq 0x80000039 vrfid 0x60000000
STEP 7 SPF runs on R1
1511 Sep 16 12:28:18.927  ospf_run_spf: Begin SPF
1542 Sep 16 12:28:20.930  ospf_run_spf: Begin SPF
1573 Sep 16 12:28:24.930  ospf_run_spf: Begin SPF
1604 Sep 16 12:28:32.931  ospf_run_spf: Begin SPF
1637 Sep 16 12:28:48.932  ospf_run_spf: Begin SPF
1668 Sep 16 12:29:04.934  ospf_run_spf: Begin SPF
1699 Sep 16 12:29:20.934  ospf_run_spf: Begin SPF
LSA built on R2 Since the previous build SPF on R1 Install to SPF
12:28:17.923 — 12:28:18.927 1000 ms
19.923 2000 ms 20.930 1000 ms
23.923 4000 ms 24.930 1002 ms
31.923 8000 ms 32.931 1003 ms
47.924 16001 ms 48.932 1004 ms
12:29:03.924 16000 ms 12:29:04.934 1006 ms
19.925 16001 ms 20.934 1006 ms

From the first event (12:28:16.856) to the SPF run on R1 (12:28:18.927) is 2071 ms: start 1000 ms on R2, a few milliseconds of propagation, and start 1000 ms on R1. The delays add up. Once at the maximum, the pattern settles into R2 building an LSA every 16 seconds and R1 recalculating about a second later. Thirty changes collapsed into seven LSAs and seven SPF runs.

STEP 8: Reverting everything (final state)

The timers are removed from R1 and R2.

STEP 8 configuration committed on R1
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Wed Sep 16 12:36:14.495 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router ospf 1
 no timers throttle spf 1000 2000 16000
!
end
STEP 8 show ospf on R1 back at the defaults
 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 interval 200 msecs. Minimum LSA arrival 100 msecs

All three routers end with router ospf 1 identical to STEP 0, and reachability from R1 to R3 was 100 percent in every STEP.

Verification configs and show output

Each STEP was captured from all three routers as separate files per router. The verification config is the ..._run.txt (the final state is the one from the last STEP).

File Contents
..._show.txt show version, show interface description, show route, show route ospf, the show ospf set (interface, neighbor, neighbor detail, database, database router, database network, database router self-originate, database database-summary, statistics spf, statistics spf detail, statistics prot), show route 3.3.3.3/32 and show configuration commit list
..._log.txt show logging narrowed to that STEP. A logmsg marker is placed at the start of each STEP and its timestamp passed to show logging start. R2 commit times (%MGBL-CONFIG-6-DB_COMMIT) are here too
..._run.txt show running-config at that STEP (the verification config for that STEP)
..._trace.txt show ospf trace spf, adj_cycle, events and errors, plus show ospf trace all filtered on rtr, db_install and arriv
..._ping.txt From R1: ping 3.3.3.3 and traceroute 3.3.3.3 (source 1.1.1.1, 50 packets). None for R2 and R3
..._trigger.txt The SSH session on R2 that generated the events. Only in STEPs that generated events (STEP 2 and 3 have b and c for the wider spacings)
..._commit.cfg What was committed in that STEP (show configuration commit changes last 1). Absent for STEPs and routers that changed nothing

STEP 0: Defaults, nothing changed

Router show output syslog running-config trace ping commit events
R1 show log run trace ping — —
R2 show log run trace — — —
R3 show log run trace — — —

STEP 1: Twelve events about 1.8 seconds apart with the defaults

Router show output syslog running-config trace ping commit events
R1 show log run trace ping — —
R2 show log run trace — — trigger
R3 show log run trace — — —

STEP 2: timers throttle spf 1000 2000 16000 on R1

Router show output syslog running-config trace ping commit events
R1 show log run trace ping commit —
R2 show log run trace — — trigger / triggerb / triggerc
R3 show log run trace — — —

STEP 3: Revert R1, timers throttle lsa all 1000 2000 16000 on R2

Router show output syslog running-config trace ping commit events
R1 show log run trace ping commit —
R2 show log run trace — commit trigger / triggerb / triggerc
R3 show log run trace — — —

STEP 4: Keep R2 as is; alternate the cost between 20 and 10

Router show output syslog running-config trace ping commit events
R1 show log run trace ping — —
R2 show log run trace — — trigger
R3 show log run trace — — —

STEP 5: Revert R2, timers lsa min-arrival 3000 on R1

Router show output syslog running-config trace ping commit events
R1 show log run trace ping commit —
R2 show log run trace — commit trigger
R3 show log run trace — — —

STEP 6: Keep R1 as is; only two events, then silence

Router show output syslog running-config trace ping commit events
R1 show log run trace ping — —
R2 show log run trace — — trigger
R3 show log run trace — — —

STEP 7: SPF on R1 and LSA generation on R2 delayed at the same time, 30 events

Router show output syslog running-config trace ping commit events
R1 show log run trace ping commit —
R2 show log run trace — commit trigger
R3 show log run trace — — —

STEP 8: Revert everything (final state)

Router show output syslog running-config trace ping commit events
R1 show log run trace ping commit —
R2 show log run trace — commit —
R3 show log run trace — — —

Packet captures were taken per STEP between R1 and R2.

STEP R1-R2
0 pcap
1 pcap
2 pcap
3 pcap
4 pcap
5 pcap
6 pcap
7 pcap
8 pcap

References

Standard / document Title Summary
RFC 2328 OSPF Version 2 Section 12.4 sets the minimum interval between rebuilding the same LSA (MinLSInterval, 5 s) and requires a new LSA only when the contents change. Section 13 step (5)(a) sets the receive-side minimum (MinLSArrival, 1 s) and requires discarding without acknowledging. Appendix G.2 limits that check to LSAs received via flooding. No SPF timer is defined.
RFC 8405 Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs Section 3 defines the five parameters, Section 5 the QUIET / SHORT_WAIT / LONG_WAIT state machine and Section 6 the recommended defaults. IOS XR has no option to select it for OSPF.
Cisco IP Routing: OSPF Configuration Guide, IOS XE Gibraltar 16.10.x OSPF Shortest Path First Throttling Explains that the SPF wait interval doubles when an event is received during the previous wait, and that at the maximum it stays there until the topology stabilizes (written for IOS XE).
Cisco: Change of Default OSPF and IS-IS SPF and Flooding Timers Document ID 211432 Explains that the IOS defaults for OSPF SPF throttling, LSA throttling and LSA arrival were changed to 50 / 200 / 5000 ms and 100 ms to match the IOS XR defaults.

Related articles