OSPF LSA Refresh and Pacing

OSPF LSA Refresh and Pacing

An OSPF LSA ages inside the database of every router that holds it. The LS age in the header goes up by one each second, and an LSA that reaches MaxAge (3600 seconds) is taken out of the routing calculation. Left alone, every LSA would disappear within an hour.

That does not happen because the router that originated an LSA builds an identical one again at a fixed interval. That is the refresh. When a router originates many LSAs, those rebuilds and the packets that carry them come in bunches. This article confirms the refresh rules in RFC 2328 and then measures on IOS XR how many packets the refreshes are split into and how far apart they are sent.

The fields of the LSA header and how LS age is handled are covered in LSAs and the LSA Header.

What RFC 2328 defines

The trigger for a refresh is the first of the ten conditions under which a new LSA is originated:

(1) The LS age field of one of the router’s self-originated LSAs reaches the value LSRefreshTime. In this case, a new instance of the LSA is originated, even though the contents of the LSA (apart from the LSA header) will be the same. This guarantees periodic originations of all LSAs. (RFC 2328 Section 12.4 (1))

Only the LSA header changes in a refresh. The contents stay the same; the sequence number goes up by one and the LS age starts again from zero. The values involved are fixed architectural constants.

(RFC 2328 Appendix B)

Conversely, an LSA is withdrawn by flooding it with its LS age set to MaxAge, leaving the sequence number alone. Section 14.1 calls this premature aging and uses it, among other things, when an advertised external route is no longer needed.

What RFC 2328 does not define is how many packets the rebuilt LSAs are split into or how far apart they are sent. The two kinds of pacing below are implementation features.

Grouping the refreshes (LSA group pacing)

Each LSA is due for a refresh 30 minutes after it was built. If the LSAs were built at different times, their refreshes fall at different times too. Sending them one by one would mean a steady trickle of small Link State Update packets.

IOS XR groups them with group pacing. At a fixed interval it rebuilds all the LSAs whose refresh fell due in that interval and sends them together. The interval is set with timers lsa group-pacing between 10 and 1800 seconds, and the default is 240 seconds.

A short interval gives small groups sent often; a long one gives large groups sent rarely. The total number of LSAs sent does not change; only the number of rounds does. Because each LSA waits for its group, the actual refresh interval ends up slightly longer than 1800 seconds. On the router tested here, refreshes that were already scheduled when the value was changed were still handled on the old spacing.

Transmit spacing (flood pacing and retransmission pacing)

LSAs rebuilt together are split into several Link State Update packets when they do not fit into one. How many milliseconds apart those packets are sent is the flood pacing. The IOS XR default is 33 ms, and timers pacing flood changes it within 5 to 100 ms.

show ospf also shows a retransmission pacing of 66 ms. That is the spacing of packets that resend unacknowledged LSAs. It is not the same thing as retransmit-interval, which sets how many seconds a router waits before resending an LSA (covered in OSPF Hello and Dead Intervals). IOS XR has no command to set the retransmission pacing.

timers lsa refresh cannot go below 1800 seconds. LSRefreshTime in RFC 2328 is the maximum time between originations, so only the longer direction is offered.

Verification on real hardware

Test environment

Three Cisco IOS XR (XRd 26.1.1) routers in a line, every link in area 0 and point-to-point. R1 has 60 static routes to Null0 and redistribute static, so it originates 60 type 5 LSAs — one would not show any grouping.

The 60 statics were added one every 15 seconds. Adding them all at once would align their refresh times as well, and they would all be rebuilt in one go regardless of the group pacing. Packets are captured on R1 - R2, one capture per step.

Test steps

Defaults and configurable ranges (step 0)

The timer part of show ospf on R1:

 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

Refresh interval 1800 seconds, flood pacing 33 ms, retransmission pacing 66 ms. The group pacing value does not appear here.

The configuration-mode help gives the ranges:

RP/0/RP0/CPU0:R1(config-ospf)#timers lsa refresh ?

  <1800-2700>  How often self-originated LSAs should be refreshed, in seconds
RP/0/RP0/CPU0:R1(config-ospf)#timers lsa refresh 

% Incomplete command.
RP/0/RP0/CPU0:R1(config-ospf)#timers lsa group-pacing ?

  <10-1800>  Interval between group of LSA being refreshed or maxaged
RP/0/RP0/CPU0:R1(config-ospf)#timers lsa group-pacing 

% Incomplete command.
RP/0/RP0/CPU0:R1(config-ospf)#timers pacing ?

  flood  OSPF flood pacing timer
RP/0/RP0/CPU0:R1(config-ospf)#timers pacing 

% Incomplete command.
RP/0/RP0/CPU0:R1(config-ospf)#timers pacing flood ?

  <5-100>  Interval in msec to pace flooding on all interfaces

timers lsa refresh accepts 1800 to 2700 seconds, timers lsa group-pacing 10 to 1800 seconds and timers pacing flood 5 to 100 ms. Under timers pacing there is only flood; nothing sets the retransmission pacing.

A rebuild every 1800 seconds (step 2)

The type 5 for 172.16.0.0/24, the first one added in step 1, sampled every two minutes in R2’s LSDB (the ..._watch.txt files):

Just past 1800 the LSA was rebuilt: the LS age went back near zero and the sequence number went up by one. It was built at 07:42:50 in step 1 and its first refresh LSU crossed the link at 08:13:17 — 1827 seconds later. The next refresh (in step 3) came at 08:43:19, 1802 seconds after that.

Group pacing changes the grouping (steps 2 and 3)

The same 60 refreshes with 10 s group pacing (step 2) and 240 s (step 3). The figure plots every LSU from R1 that carried type 5 LSAs, by time and number of LSAs:

With 10 seconds, the 60 LSAs went out in 52 LSUs, almost one each. The LSAs are 15 seconds apart, so each 10 second group usually holds just one.

With 240 seconds, groups of 12 to 17 went out about 4 minutes 20 seconds apart. The LSUs from step 3, by time and number of LSAs:

2026-09-22T08:43:19.286136000+0900	1
2026-09-22T08:44:20.695040000+0900	1
2026-09-22T08:44:31.988204000+0900	1
2026-09-22T08:44:42.199414000+0900	1
2026-09-22T08:45:02.699256000+0900	1
2026-09-22T08:45:23.163630000+0900	1
2026-09-22T08:45:33.409927000+0900	1
2026-09-22T08:45:43.635052000+0900	1
2026-09-22T08:45:53.869064000+0900	1
2026-09-22T08:46:14.336978000+0900	1
2026-09-22T08:46:24.569156000+0900	1
2026-09-22T08:46:46.039085000+0900	1
2026-09-22T08:47:07.637609000+0900	1
2026-09-22T08:47:18.811163000+0900	1
2026-09-22T08:47:39.309147000+0900	1
2026-09-22T08:47:50.645647000+0900	1
2026-09-22T08:50:58.999675000+0900	15
2026-09-22T08:55:18.048995000+0900	17
2026-09-22T08:59:34.080183000+0900	12

The last three rows are the 240 second groups: 15, 17 and 12. The first 16 rows are the refreshes of the first nine minutes after the change, still sent one at a time on the old 10 second spacing. LSAs whose refresh was already scheduled when the value changed were handled as scheduled. The total is still 60.

The change of group pacing is recorded in the trace as well:

RP/0/RP0/CPU0:R1#show ospf trace all | include pacing
Tue Sep 22 00:45:28.719 UTC
49   Sep 21 22:42:41.725  ospf_apply_lsapacing_timer: sense 1 op_lsa_group_interval 240 new_interval 10
52   Sep 21 23:38:24.744  ospf_apply_lsapacing_timer: sense 1 op_lsa_group_interval 10 new_interval 240
70   Sep 22 00:28:16.604  ospf_apply_lsa_pacing_flood_timer: sense 1 op_if_flood_pacing 33 new_interval 100
74   Sep 22 00:42:09.796  ospf_apply_lsa_pacing_flood_timer: sense 0 op_if_flood_pacing 100 new_interval 33
76   Sep 22 00:42:09.796  ospf_apply_lsapacing_timer: sense 0 op_lsa_group_interval 240 new_interval 240

op_lsa_group_interval 240 new_interval 10 is the step 1 change: the value before it was 240, which is the default. The last line is the return to the default, with new_interval 240.

Flood pacing (steps 4 and 6)

no redistribute static withdraws the 60 type 5 LSAs at once, and the spacing of the resulting LSUs is measured. First with the default 33 ms (step 4):

	1	1	1
0.111437000	39	3600	5
0.033086000	21	3600	5

The columns are the seconds since the previous LSU, the number of LSAs, the LS age of the first LSA and its type. The first row is R1’s router-LSA (type 1), rebuilt because R1 is no longer an ASBR. Rows 2 and 3 are the 60 type 5 LSAs being withdrawn at LS age 3600 (39 and 21). They do not fit into one LSU and are split into two packets, 33 ms apart.

Step 6 adds timers pacing flood 100 and repeats the same withdrawal:

	1	1	1
0.100147000	39	3600	5
0.099919000	21	3600	5

The packets are now 100 ms apart. The 60 LSAs are still split 39 and 21; only the transmit spacing changed. This change, too, is in the trace above, as op_if_flood_pacing 33 new_interval 100 on line 5.

Retransmission pacing cannot be configured (step 7)

Trying to change the retransmission pacing that show ospf displays is not accepted as a command:

RP/0/RP0/CPU0:R1(config-ospf)# timers pacing retransmission 100
                                             ^
% Invalid input detected at '^' marker.

It is rejected with % Invalid input, as the step 0 help, with only flood under timers pacing, already suggested.

Design notes

• A shorter group pacing means more packets. On a router originating many LSAs, the default 240 seconds sends fewer of them
• Changing group pacing does not reschedule refreshes that are already due; they run on the old spacing until the next cycle. Seeing the effect takes at least one cycle (30 minutes)
• timers lsa refresh cannot go below 1800 seconds. It protects the relationship with the LSA lifetime (MaxAge); only the longer direction is available

Verification configs and show output

Every step collects the following files from all three routers, kept separate per router. The verification config is the ..._run.txt file (the final state is the one from the last step).

The times at which the statics were added in step 1 are in ospf-lsa-refresh_step1_r1_stagger.txt, and the configuration rejected in step 7 is in ospf-lsa-refresh_step7_r1_failed.cfg. The final running-config is back to the defaults, with no refresh, group pacing or flood pacing configured.

Step 0: Initial state (defaults, no type 5)

Step 1: group-pacing 10 on R1, 60 statics added one every 15 s

Step 2: No change (watching the refresh 30 minutes later)

Step 3: group-pacing 240 on R1

Step 4: no redistribute static on R1 (flood pacing at the default)

Step 5: redistribute static back on R1

Step 6: timers pacing flood 100 and no redistribute static on R1

Step 7: Trying timers pacing retransmission on R1 (rejected)

Step 8: Everything back to default (final state)

Packets were captured on R1 - R2, one capture per step.

References

Related articles

• What Is OSPF
• OSPF Router ID
• OSPF Packet Types and Header Format
• OSPF Authentication
• OSPF Neighbor States
• OSPF Options Field
• OSPF DR and BDR
• OSPF Network Types
• OSPF Cost (Metric)
• OSPF External Routes (Redistributing Static Routes)
• OSPF RFC1583 Compatibility (External Route Selection Rules)
• OSPF Multiple Areas and the ABR
• OSPF Virtual Links
• OSPF Stub and Totally Stubby Areas
• OSPF NSSA and Totally NSSA
• OSPF Default Route
• OSPF Route Summarization
• OSPF LSAs and the LSA Header
• OSPF Hello and Dead Intervals
• OSPF Convergence Timers (SPF / LSA Throttling)
• OSPF LSA Refresh and Pacing
• OSPF router-LSA (type 1)
• OSPF network-LSA (type 2)
• OSPF summary-LSA (type 3)
• OSPF ASBR summary-LSA (type 4)
• OSPF AS external-LSA (type 5)
• OSPF NSSA External-LSA (Type 7)