In this blog post, I am going to discuss OSPF LSA group pacing, an OSPF feature related to network convergence and scalability. Particularly, I am going to explain LSA group pacing, and how Cisco IOS optimizes refreshing, checksumming, and aging of OSPF LSAs in order to get rid of CPU bursts and overwhelming the network bandwidth.

Note that OSPF supports other features that enhance network convergence such as OSPF LSA retransmission pacing, OSPF LSA flood pacing, OSPF LSA throttling, OSPF SPF throttling, and OSPF incremental SPF.

In this post, I will be using this network topology. The OSPF router ID values of routers R1, R2, R3, and R4 are 1.1.1.1, 2.2.2.2, 3.3.3.3, and 4.4.4.4, respectively.

Here are the initial router configurations.

Router R1 Router R2 Router R3 Router R4

What is OSPF LSA Group Pacing?

OSPF LSA group pacing is a technique used in OSPF to control the rate at which the router refreshes self-originated link state advertisements (LSAs) and ages and checksums non-self-originated LSAs. The LSA group pacing mechanism applies to all OSPF LSA types.

LSA group pacing ensures that self-originated LSAs are refreshed and flooded at a regular and controlled rate, helping to avoid network bandwidth abuse and sudden CPU spikes caused by excessive flooding and processing of large volumes of LSAs in a short period of time.

In general, this feature prevents the network bandwidth and routers’ CPUs from being overloaded by excessive LSAs being processed and flooded within short periods of time, which may cause IP packet delays and other network issues.

How Does OSPF LSA Group Pacing Work?

Before explaining how LSA group pacing works, let’s describe some key concepts related to that feature.

OSPF Link-State (LS) Checksumming

LSA corruption and errors may happen while an LSA is being processed by an OSPF instance, or while an LSA is transmitted between OSPF neighbors.

OSPF includes the checksum field in LSAs in order to determine the most recent version of an LSA if two copies of it are received and they have the same sequence number, and to detect errors and data corruption in LSAs.

Additionally, OSPF examines the LS checksum field when an LSA is received or during the aging of the link state database (LSDB).

The checksum field is calculated based on the content of the LSA not including the LS age field using the Fletcher checksum, which is the algorithm used also for ISO connectionless datagrams.

OSPF excludes that field from the LS checksum since the LS age field gets updated frequently and that would cause OSPF to re-calculate the checksum repeatedly if the LS age is included in the checksum computation process.

Finally, note that the LS checksum field cannot equal zero, which is considered a checksum computation failure.

Aging Non-Self-Originated LSAs in The Link State Database (LSDB)

Each OSPF LSA includes an LS age attribute that tells how old the LSA is. OSPF increments the age of the LSAs stored in the LSDB and LSAs being encapsulated into a Link State Update packet before getting flooded to a neighbor.

Link State Database (LSDB) aging is the mechanism that OSPF implements to increment the age of the non-self-originated LSAs in the LSDB and discard obsolete LSAs from the LS database.

Outdated LSAs are LSAs whose LS age equals MaxAge (1 hour or 3600 seconds). In addition, any routes associated with a removed LSA may be deleted from the RIB and routing tables, depending on whether or not other valid LSAs can provide those routes.

Overall, the LSDB aging process helps ensure that data stored in the LSDB is accurate and up-to-date and that outdated LSA data does not cause routing decision issues.

Refreshing Self-Originated LSAs Based On RFC 2328

OSPF removes LSAs with an age that reaches MAxAge (3600 seconds) from the LSDB. Therefore, for an LSA to remain in the LSDB of other routers, the originating router must generate a new copy of the LSA every LSRefreshTime period and send it to its OSPF adjacent neighbors.

In other words, OSPF re-creates and re-floods each self-originated LSA whenever the LS Age field of the LSA reaches the value of LSRefreshTime.

Finally, the value of LSRefreshTime is 30 minutes and refers to the maximum amount of time between two consecutive updates of an LSA.

OSPF LSA Group Pacing Operation

Cisco routers originally regulated the rate at which LSAs were sent by refreshing self-originated LSAs in the LSDB every 30 minutes, regardless of the age of each of them.

In large enterprise networks, routers’ LSDBs may have thousands of LSAs; in this case, the way Cisco IOS initially acted would produce unusual increases in CPU cycle consumption every 30 minutes, as well as generating a large number of OSPF packets in a short period of time in order to flood those LSAs.

Besides, every OSPF router in the autonomous system would receive, handle, and re-flood a significant number of LSAs; thus leading to the same bandwidth and CPU issues.

Similarly, Cisco routers originally perform LSA checksumming and aging every 10 minutes, which has a roughly equivalent impact as periodic LSA refreshing.

Before implementing OSPF LSA group pacing, Cisco IOS performs LSA refreshing every 30 minutes and performs LSA checksumming and aging every 10 minutes. This way the router’s CPU gets exhausted every 30 minutes (Figure 1).

Moreover, that has a huge negative impact on network bandwidth since all LSAs get flooded together.

Figure 1 – Cisco IOS’s original LSA refreshing method

Cisco solved the 30-minute refreshing issue by assigning a separate timer to each LSA. In other words, instead of linking all self-originated LSAs to one refreshing timer, each LSA has its own refreshing timer.

Using this approach, Cisco IOS decreases the age of each LSA separately periodically. The time duration between refreshing the ages of two LSAs is short, and the LSA is flooded if its age is about 30 minutes old. This way, the router’s CPU does not get abused within brief time periods (Figure 2).

However, this solution even if it decreases the number of sudden CPU bursts, it does generate frequent LSA floods; thus, OSPF produces lots of OSPF packets in order to carry the LSAs to be flooded, which would waste network bandwidth.

In summary, each LSA has its own timer and is refreshed separately from other self-originated LSAs at irregular intervals.

As a result, self-originated LSAs are refreshed, propagated, and processed frequently, and CPU utilization and network load are well distributed over time.

Figure 2 – Cisco IOS’s LSA individual refreshing method

Starting from Cisco IOS version 12.0, Cisco implemented LSA group pacing, a new way to deal with LSA refreshing, aging, and checksumming. The new solution consists in handling a set of LSA every short period of time called the pacing interval.

Instead of refreshing each LSA individually, the router takes a group of LSAs that are close to half of the MaxAge, refreshes them at the same time, and then re-floods them together.

In this way, routers in the routing domain get rid of sporadic CPU spikes and wasted network bandwidth due to excessive OSPF packets used to re-flood each LSA separately (Figure 3).

The OSPF LSA group pacing mechanism applies also to LSA aging and checksumming. Therefore, a portion of non-self-originated LSAs in the LSDB get aged and checksummed every LSA pacing interval instead of every 10 minutes.

Figure 3 – Cisco IOS’s LSA group pacing method

OSPF LSA Group Pacing Timer

The LSA group pacing timer is an automatic mechanism used to refresh, age, or checksum a portion of the LSDB at preset times after the corresponding LSAs have been grouped.
By default, the LSA pacing timer is four minutes or 240 seconds.

For large OSPF autonomous systems, lowering the LSA pacing interval may be appropriate. However, the default value would be fine for small and medium networks.

OSPF LSA Group Pacing Configuration and Verification on Cisco IOS

On Cisco IOS 12 and above, the default OSPF LSA group pacing timer is 240 seconds. To change this value, use the timers pacing lsa-group drtn command in router configuration mode, where drtn is a number between 10 seconds and 1800 seconds.

This example sets the OSPF LSA group pacing timer to 100 seconds on router R2.

R2(config)# router ospf 1
R2(config-router)# timers pacing lsa-group 100

To check the LSA group pacing timer, use the show ip ospf command in enable mode, as illustrated in this example.

R2# show ip ospf
Routing Process "ospf 1" with ID 2.2.2.2
Start time: 00:06:16.186, Time elapsed: 02:20:29.731
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
Supports NSSA (compatible with RFC 3101)
Supports Database Exchange Summary List Optimization (RFC 5243)
Event-log enabled, Maximum number of events: 1000, Mode: cyclic
It is an area border router
Router is not originating router-LSAs with maximum metric
Initial SPF schedule delay 5000 msecs
Minimum hold time between two consecutive SPFs 10000 msecs
Maximum wait time between two consecutive SPFs 10000 msecs
Incremental-SPF disabled
Minimum LSA interval 5 secs
Minimum LSA arrival 1000 msecs
LSA group pacing timer 100 secs
Interface flood pacing timer 33 msecs
Retransmission pacing timer 66 msecs


omitted output

Related Lessons to OSPF LSA Group Pacing

Conclusion

I hope this blog post helps you learn something.
Now I’d like to turn it over to you:
What did you like about this tutorial?
Or maybe you have an excellent idea that you think I need to add.
Either way, let me know by leaving a comment below right now.

Mohamed Ouamer
Mohamed Ouamer
Mohamed Ouamer is a computer science teacher and a self-published author. He taught networking technologies and programming for more than fifteen years. While he loves to share knowledge and write, Mohamed's best passions include spending time with his family, visiting his parents, and learning new things.
Linkedin