The biggest challenge in large-scale networks is to recover quickly from failures and instability.
As you know, OSPF is a link-state protocol which uses LSAs to advertise topology changes to other OSPF-enabled routers. When this happens, OSPF runs the SPF algorithm.
The problem arises when LSAs are received too quickly due network instability; in this case, the SPF calculation has to run whenever a new LSA arrives (LSA-driven), this may result in high CPU utilization. Here is where SPF throttling enters to play.
OSPF SPF throttling
OSPF throttling is a scheduling technique used to delay SPF calculations by imposing an SPF-waiting interval. With this interval in place, if a large number of LSAs are received, SPF rather than immediately trigger the SFP calculation, it waits for LSAs to be added to the Link-State Database (LSDB). Then when the SPF-waiting interval expires, SPF calculation runs. This result in more changes included in a single calculation. Using this timer naturally increases the efficiency of OSPF; however, this solution has a side effect: It also increases the convergence time.
The ideal solution would have a long wait interval when the network is unstable and short when it’s operating in the normal way. Some SPF adaptive timers.
Well, we are lucky; Cisco introduced an exponential back-off algorithm since IOS Release 12.2 which use three additional timers to the waiting timer interval to achieve this (All three timers are displayed as delay in the CLI, thus I will assign different names to each one for easy understanding):
- SPF-start: Indicates the initial SPF schedule delay. By default, the SPF-start timer is 5000 milliseconds.
- SPF-hold: Indicates the minimum hold time between two consecutive SPF calculations. By default, the SPF-hold timer is 10000 milliseconds.
- SPF-max: Indicates the maximum wait time between two consecutive SPF calculations. By default, the SPF-maximum timer is 10000 milliseconds.
These timers are expressed in milliseconds, and all of them have a range from 1 to 600,000 milliseconds.
To configure OSPF SPF Throttling use the timers throttle spf {SPF-start} {SPF-hold} {SPF-max} OSPF process command.
Here is how it works:
When the first LSA is received, the SPF calculation is delayed for the value set by the SPF-start timer. The SPF-waiting timer is set to the value of the SPF-hold timer.
LSA(1) - (SPF-start=5000) (SPF-hold=1000) –> (SPF-waiting= SPF-hold)
If the router receives more LSAs during the SPF-waiting timer, the SPF-waiting interval is set to the twice of its value. The SPF-waiting interval will increment every time an event occurs during the current hold-time window.
LSA(2) - (2*SPF-wait=20000) LSA(3) - (2*SPF-wait=40000) LSA(4) - (2*SPF-wait=80000)
The SPF calculation will be delayed until the current SPF-hold timer expires; if not, the SPF-wait interval will continue growing exponentially until it reaches the SPF-max value. If this happens, then the SPF calculation will take place.
If there are no more events for two times the SPF-max timer, timers will be reset back to the configured timer values.
OSPF LSA throttling
This feature also provides a dynamic scheduling to slow down the frequency of LSA generation during network instability. Before this feature was introduced, the LSA generation was rate-limited for 5 seconds; this is the default LSA-wait timer interval. That meant that the LSA could not be propagated in milliseconds. Therefore, OSPF could not achieve sub-second convergence. The principle is similar to the SPF throttling. It provides Adaptive Timers for LSA generation when the network is unstable.
OSPF LSA throttling also uses three additional timers to the waiting timer interval to achieve this (All three timers are displayed as delay in the CLI, thus, I will assign different names to each one for easy understanding):
- LSA-start: Indicates the initial LSA generation schedule delay. By default, the LSA-start timer is 0 milliseconds.
- LSA-hold: Indicates the minimum hold time between two consecutive LSA calculations. By default, the SPF-hold timer is 5000 milliseconds.
- LSA-max: Indicates the maximum wait time between two consecutive LSA calculations. By default, the LSA-max timer is 5000 milliseconds.
To configure OSPF LSA Throttling use the timers throttle lsa all {LSA-start} {LSA-hold} {LSA-max} OSPF process command.
Here is how it works:
By default, the first LSA is sent immediately after an event occurs; then the LSA-wait timer is set to LSA-hold interval.
LSA(1) – (LSA-start=0) (LSA-hold=5000) –> (LSA-waiting= LSA-hold)
If additional LSAs needs to be generated, it will at the LSA-hold interval, then the LSA-wait interval is set to the twice of its value.
LSA(2) – (2*LSA-wait=20000)
LSA(3) – (2*LSA-wait=40000)
LSA(4) – (2*LSA-wait=80000)
If there are several events during the LSA-waiting interval, the LSAs will be grouped and sent when the LSA-hold timer interval expires. The LSA-wait interval will continue growing exponentially until it reaches the LSA-max value. If this happens, then the grouped LSAs will be generated.
If there are no more events for two times the LSA-max timer, all timers will be reset back to the configured values.
When using OSPF LSA Throttling it’s also required set the minimum interval for accepting the same LSA. Let me explain this: If the same LSA arrives sooner than the interval that is set, the LSA is dropped. Now, Cisco recommends the arrival interval be less than or equal to the LSA-hold timer interval of the timers throttle lsa all command.
To do so use the timers lsa arrival {milliseconds} command.
Let’s use the following topology for the examples:
Here you can download the diagram and configuration files: OSPF-Throttling
Example 1:
Let’s configure SPF throttling with an initial delay of 5 milliseconds and hold timer of 10 seconds and an expiration of 90 seconds on both routers.
In R1& R2:
!
router ospf 1
timers throttle spf 5 10000 90000
exit
!
Ok, now both routers have the SPF throttling configured as shown next:
Let’s test the configuration. To do so, let’s flap the loopback 0 interface in R2.
Before start flapping the interface let’s enable the spf statistics debugging to observe the changes. I never get tired of saying that debug should be used with caution.
In R1& R2:
!
debug ip ospf spf statistic
!
Let’s flap the interface several consecutive times with the shutdown/no shutdown interface command.
As can be seen in the above output, the configuration worked as expected. When R1 first detects the topology change, it initiated SPF calculation after 5msec, when the router detected the second topology change it waited 10000msec and it set the next waiting interval was set to the twice of its value (20000) and continue growing. Once the wait interval reaches the maximum wait interval 90000msec, the wait interval remains the same until the network stabilizes.
Let’s clear the debug and the previous configuration for the next example.
In R1& R2:
!
no debug ip ospf spf statistic
!
config t
!
router ospf 1
no timers throttle spf 5 10000 90000
exit
!
Example 2:
Let’s configure LSA throttling with an initial delay of 100msec and hold timer of 10 seconds and an expiration of 50 seconds on both routers. Set the LSA arrival interval to 2 seconds.
In R1 & R2:
!
router ospf 1
timers throttle lsa all 100 10000 50000
timers lsa arrival 2000
exit
!
Ok, now both routers have the LSA throttling configured as shown next:
Let’s test the configuration. To do so, let’s flap again the loopback 0 interface in R2.
Before start flapping the interface let’s enable the database-timer rate-limit debugging in R2 to observe the changes.
In R2:
!
debug ip ospf database-timer rate-limit
!
Let’s flap the interface several consecutive times with the shutdown/no shutdown interface command.
As can be seen in the above output, the configuration worked as expected. The interface was shut down, which causes OSPF to generate a new Type-1 LSA, then the next wait timer was set to 10000ms. Then, a new change is detected; therefore, the next wait timer was set to 20000ms.
It is time to close this post. In the next one, we will discuss the OSPF Pacing Timers.
Thank you for visiting.