Optimizing OSPFv3 Performance in ISP Backbones Using LSA Throttling

 

Preface:

In today’s ISP world, especially in large scale deployments like GTPL, routing stability is a constant challenge. One of the most common yet disruptive issue faced by network engineers is OSPFv3 route flapping – where routes keep going active and inactive due to transient link failures, interface instability or misconfigurations. These rapid and repeated changes result in too many Link-State Advertisements (LSAs) and frequent Shortest Path First (SPF) calculations, overwhelming router CPUs, memory consumption and ultimately degrading network throughput and user experience. This problem is more severe in backbone and aggregation layers where even minor disruption can ripple across the network. To address this, OSPFv3 has a very effective but often underutilized feature: throttling. OSPFv3 throttling allows administrators to control how many LSAs are generated, received and processed and how often SPF calculations occur. By introducing configurable delays and pacing these operations, throttling ensures that routers don’t overreact to momentary instabilities and provides a more measured and stable response to network changes. This blog post will go into the details of OSPFv3 throttling, benefits for ISP networks and provide configuration examples and a case study from GTPL’s own infrastructure to show the real-world impact on routing performance and reliability.

Scenario: In the GTPL network, core routers were experiencing OSPFv3 route flapping due to fiber instability and frequent interface resets. Engineers noted CPU spikes during the flapping period and noticed delays in convergence.

Configuration steps

1. First configure router name as per location wise at both ends.

2. Need to configure physical IP and loopback on both ends interface.

3.IGP protocol OSPF configuration require as per area-id wise.

4. Need to set LSA throttling 3 timers in Pune_R1 router.

Command Line Interface Log:

=============================================

R1(config) # hostname Mumbai_R1

Mumbai_R1(config) # interface GigabitEthernet 0/0

Mumbai_R1(config-if) # ip address 10.0.0.1 255.255.255.0

Mumbai_R1(config-if) #exit

Mumbai_R1(config)# router ospf area 0

Mumbai_R1(config-router) # network 10.0.0.0 0.0.0.255 area 0

Mumbai_R1(config-router) # network 8.8.8.8 0.0.0.0 area 0

Mumbai_R1(config-router) # timers lsa arrival 10000

Mumbai_R1(config-router) # exit

Mumbai_R1(config) # exit

 Mumbai_R1#

=============================================

R1(config) # hostname Pune_R1

Pune_R1(config) # interface GigabitEthernet 0/1

Pune_R1(config-if) # ip address 10.0.0.2 255.255.255.0

Pune_R1(config-if) #exit

Pune_R1(config)# router ospf area 0

Pune_R1(config-router) # network 10.0.0.0 0.0.0.255 area 0

Pune_R1(config-router) # network 9.9.9.9 0.0.0.0 area 0

Pune_R1(config-router) # timers throttle lsa 5000 10000 60000

Pune_R1(config-router) # exit

Pune_R1(config)#exit

Pune_R1#

=======================================

Here 3 different timers are used:

1.     LSA_START TIMER: 5000 ms

2.     LSA_HOLD TIMER: 10000 ms

3.     LSA_MAX TIMER:  60000 ms

=================================

OSPF LSA throttling is a feature that delays LSA generation during network instability. Before LSA throttling, LSA generation was rate limited to 5 seconds due to the default LSA-wait timer interval. This meant an LSA could not be propagated in milliseconds and thus OSPF sub-second convergence was impossible.

This is very similar to OSPF SPF throttling. The mechanism is the same. It uses three values:

lsa-start: the initial wait interval for LSA generation. It is 0 milliseconds so the first LSA will be generated immediately.

lsa-hold: the minimum hold time interval between two LSA generations. The default is 5000 milliseconds, and it doubles every time the same LSA has to be re-generated.

lsa-max: the maximum wait time interval between two LSA generations. The default is 5000 milliseconds. It is also used to limit the maximum value of Isa-hold.

The first LSA generated uses lsa-start timer so it is generated immediately. If the same LSA has to be re-generated it will use Isa-hold value. If the LSA has to be generated the third time it will use Isa-hold value doubled. Each time the LSA is re-generated Isa-hold value will double until it reaches Isa-max value.

====================================

An LSA is considered the same if the following three values are the same:

LSA ID number

LSA type

advertising router ID

How OSPF LSA Throttling Timers Prevent Route Flapping

It starts when something happens in the network that should trigger the router to create and send out a new LSA (Link-State Advertisement). But instead of sending it right away, the router waits for 5 seconds — this is called the lsa-start time.

While waiting, another network change happens that also requires an LSA. After the 5 seconds are up, the router finally creates and sends the LSA.

Now the router goes into a lsa-hold timer for 10 seconds. If something else happens during this time that requires a new LSA, the router waits until the 10 seconds are up before sending it.

Then the lsa-hold timer doubles to 20 seconds. If nothing else happens, nothing is sent.

Later another change happens. The router goes back to waiting for the lsa-start time (5 seconds) again. During this, if another change happens, it still waits 5 seconds, then sends the LSA.

Now the lsa-hold timer doubles again to 40 seconds. If the network is stable during this time, no LSAs are sent.

Finally, if no more LSAs are needed, the router waits for the lsa-max time (60 seconds). After that the lsa-hold timer is reset back to 10 seconds and the process starts over if needed.

Conclusion

In large ISP environments like GTPL, routing stability is key to performance and user happiness. OSPFv3 route flapping caused by transient link issues or interface resets can put a lot of load on the router and the entire network. LSA throttling is a smart and efficient way to control LSA generation and SPF calculations. With lsa-start, lsa-hold and lsa-max timers, network engineers can make routers respond to real issues and ignore brief or unstable changes. As shown in GTPL’s real world example, LSA throttling reduced CPU spikes and convergence times and overall network reliability. Understanding and configuration of these timers is a must for any ISP to build a robust and scalable OSPFv3 backbone.