OSPF LSA Throttling – Network Professional Member Site

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

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

lsa-start: the initial wait interval for LSA generation. It is 0 milliseconds which means that the first LSA will be generated immediately.
lsa-hold: the minimum hold time interval between two LSA generations. The default value 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 value is 5000 milliseconds. It is also used to limit the maximum value of the lsa-hold value.

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

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

LSA ID number
LSA type
advertising router ID

Let’s look at an example where I use the following values:

lsa-start: 5000 milliseconds
lsa-hold: 10000 milliseconds
lsa-max: 60000 milliseconds

It starts with an event where an LSA should be generated, as indicated by the red arrow. Instead of generating and flooding it right away, we delay the LSA generation with the lsa-start value which is 5000 milliseconds (5 seconds):

During this time, another event happens and the LSA should be generated again. Once 5000 milliseconds have expired, we finally generate and flood the LSA, as indicated by the purple arrow:

lsa throttling start interval second lsa

The router now sets the wait interval to the lsa-hold value which is 10000 milliseconds (10 seconds). During this time, another LSA should be generated which is postponed until the timer expires. When 10 seconds have elapsed, the LSA is finally generated and flooded:

The router now doubles the value of the lsa-hold so now it’s 2x 10000 = 20000 milliseconds (20 seconds). During this time, the network is stable and no LSAs have to be generated:

When another event occurs and an LSA should be generated, the router will now use the lsa-start value again:

During this time, another interface flaps which means another LSA has to be generated. Once the lsa-start wait interval has expired, the LSA is generated and flooded:

The lsa-hold value doubles again, so now the LSA generation and flooding is delayed for 40 seconds. During this time, the network is stable:

When the same LSA doesn’t have to be generated again, we have to wait for the lsa-max value (60000 milliseconds) to expire:

Once the lsa-max wait interval has expired, the lsa-hold value is reset to its default value of 10000 milliseconds. If the same LSA has to be generated again, it will be dealt with like the beginning of this example.

Configuration

Let’s see this in action. Here is the topology I will use:

We only need two routers. R2 has a loopback interface that I will use to simulate a flapping interface.

Configurations
R1
R2

Want to take a look for yourself? Here you will find the startup configuration of each device.

To change the LSA throttling timers, we have to use the timers throttle lsa command. First, you need to configure the start-lsa value:

R2(config)#router ospf 1
R2(config-router)#timers throttle lsa ?

  <0-600000>  Delay to generate first occurrence of LSA in milliseconds

Let’s set it to 5000 milliseconds. Now we can configure the lsa-hold value:

R2(config-router)#timers throttle lsa 5000 ?
  <1-600000>  Minimum delay between originating the same LSA in milliseconds

I will set it to 10000 milliseconds. Last but not least, the lsa-max value:

R2(config-router)#timers throttle lsa 5000 10000 ?
  <1-600000>  Maximum delay between originating the same LSA in milliseconds

Which I will set to 60000 milliseconds:

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

While we are at it, there is one more command you can use to prevent the receiving router from accepting the same LSA over and over again. You can do this with the timers lsa arrival command:

R1(config)#router ospf 1
R1(config-router)#timers lsa arrival 10000

When R1 now receives the same LSA within 10000 milliseconds, it will accept the first LSA and discards the rest. This value should be equal or lower than the lsa-hold value of your neighbor, otherwise, your neighbor will send an updated LSA sooner than this router is willing to accept.

Verification

Let’s verify our work:

R2#show ip ospf | include throttle
 Initial LSA throttle delay 5000 msecs
 Minimum hold time for LSA throttle 10000 msecs
 Maximum wait time for LSA throttle 60000 msecs

Above you see the LSA throttling timers that I configured on R2.

These values only show up when you change them. You won’t see the default values.

Here’s the arrival timer on R1:

R1#show ip ospf | include arrival
 Minimum LSA arrival 10000 msecs

To see LSA throttling in action, we can enable a debug on R2:

R2#debug ip ospf database-timer rate-limit
OSPF LSA rate limit timer debugging is on

Once you do a couple of “shuts” and “no shuts” on the loopback interface of R2, you will see this on the console:

R2#
OSPF-1 LIMIT: Check rate limiting for LSA 1/2.2.2.2/2.2.2.2
OSPF-1 LIMIT: reset throttling to 5000ms next wait-interval 10000ms
OSPF-1 LIMIT: Starting rate limit timer for 2.2.2.2 2.2.2.2 1 with 5000ms delay

OSPF-1 LIMIT: Check rate limiting for LSA 1/2.2.2.2/2.2.2.2
OSPF-1 LIMIT: Rate limit timer is expired for 2.2.2.2 2.2.2.2 1
OSPF-1 LIMIT: Setting next wait-interval to 20000ms

OSPF-1 LIMIT: Check rate limiting for LSA 1/2.2.2.2/2.2.2.2
OSPF-1 LIMIT: Rate limit timer is expired for 2.2.2.2 2.2.2.2 1
OSPF-1 LIMIT: Setting next wait-interval to 40000ms

Above you can see that the timer starts with 5000 msec (lsa-start) and then increase the wait interval to 10000 msec (lsa-hold), 20000 msec (2x lsa-hold) and 40000 (4x lsa-hold). This will continue until we hit the lsa-max value which is 60000 msec.

There is also a show command that shows the queue which LSAs which are currently rate-limited:

R2#show ip ospf timers rate-limit 

            OSPF Router with ID (2.2.2.2) (Process ID 1)

List of LSAs that are in rate limit Queue

    LSAID: 2.2.2.2 Type: 1 Adv Rtr: 2.2.2.2 Due in: 00:00:02.402

This command isn’t very useful in a production network where you use short timers but in a lab like this, you can catch an LSA that is delayed. This command does show the three values that are used to consider an LSA the “same” LSA: the LSA ID, LSA type, and advertising router.

Configurations
R1
R2

Want to take a look for yourself? Here you will find the final configuration of each device.

Conclusion

OSPA LSA throttling allows you to delay the generation and flooding of LSAs in times of network/interface instability. To prevent your router from flooding the same LSA over and over again, you can configure this feature.

The first LSA generation is delayed with the lsa-start value, which is 0 milliseconds by default so it’s generated and flooded immediately when an event occurs. When the same LSA has to be generated and flooded again, it is delayed with the lsa-hold value. Subsequent same LSAs will be delayed by doubling this lsa-hold value until the lsa-max value is reached. The lsa-max value is also used to define how long the same LSA should not be generated again to consider the network stable.

Configuration

Verification

Conclusion

Unit 1: Introduction to OSPF

Unit 2: OSPF Neighbor Adjacency

Unit 3: OSPF Network Types

Unit 4: OSPF Stub Areas

Unit 5: Advanced OSPF Topics