OSPF LSA Throttling

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:

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.