OSPF LSA Throttling is a feature that allows managing the pace at which each LSA is regenerated and flooded by its originating OSPF node in order to avoid overloading the router’s CPU when there are repeated network topology updates or instabilities whether on the current router or outside of it. OSPF distinguishes between locally originated LSAs based on the link-state ID and type fields.
For example, two LSAs, generated by a particular OSPF node, with identical link-state IDs and types but with different contents represent the same LSA. This means when an LSA gets modified by its originating router, the content of the LSA gets changed but its link-state ID and type fields don’t; additionally, the originating router field stays untouched.
OSPF LSA throttling works per locally generated LSA. The delay OSPF should wait before re-creating and flooding an updated version of a particular LSA due to a network topology change depends on the fact that there was a network topology change or not, that requires the LSA to be updated, within the period of time, called the wait interval, between the last two consecutive reoriginations of that LSA.
As specified in RFC 2328, OSPF re-originates and floods a particular LSA each time there is a change in the routing domain’s topology that affects the content of the LSA. However, OSPF may not produce two versions of the same LSA within a time period of MinLSInterval.
MinLSInterval is the least amount of time that should elapse between two successive originations of any individual LSA. By default, it is set to five seconds, as indicated in this example.
R1# show ip ospf
Routing Process "ospf 1" with ID 1.1.1.1
Start time: 00:00:40.663, Time elapsed: 00:44:00.607
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
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
omitted output
If the network is not stable, i.e. there may be several malfunctioning network links, a massive amount of versions of the same LSA may get created within a limited time period driving OSPF to execute SPF repeatedly and thus using a tremendous amount of CPU cycles and negatively impacting other router operations or network traffic.
OSPF LSA throttling helps to get rid of this issue by controlling the delay between consecutive originations of any LSA.
In this tutorial, I will be using the following network topology to demonstrate the OSPF LSA throttling feature.
Here are the initial router configurations.
Router R1
Router(config)# hostname R1 R1(config)# R1(config)# interface GigabitEthernet0/2 R1(config-if)# ip address 10.0.12.1 255.255.255.0 R1(config-if)# no shutdown R1(config-if)# R1(config-if)# router ospf 1 R1(config-router)# router-id 1.1.1.1 R1(config-router)# network 10.0.12.1 0.0.0.0 area 0
Router R2
Router(config)# hostname R2 R2(config)# R2(config)# interface GigabitEthernet0/1 R2(config-if)# ip address 10.0.12.2 255.255.255.0 R2(config-if)# no shutdown R2(config-if)# R2(config-if)# router ospf 1 R2(config-router)# router-id 2.2.2.2 R2(config-router)# network 10.0.12.2 0.0.0.0 area 0 R2(config-router)# timers throttle lsa all 10000 20000 300000
Note that OSPF supports other features that enhance network convergence such as OSPF LSA retransmission pacing, OSPF LSA flood pacing, OSPF LSA group pacing, OSPF SPF throttling, and OSPF incremental SPF.
What is OSPF LSA Throttling?
OSPF LSA Throttling is a feature that allows managing the pace at which each LSA is regenerated and flooded by its originating OSPF node in order to avoid overloading the router’s CPU when there are repeated network topology updates or instabilities.
This way all changes affecting a particular LSA get applied together instead of being applied individually, thus avoiding creating and propagating the LSA many times within a short period of time. Therefore, routers don’t have to run the SPF algorithm several times within a short timeframe. This limits creating an unnecessary load on the routers’ CPUs and accelerates OSPF convergence by running the SPF algorithm less than usual.
As with OSPF SPF throttling, OSPF LSA throttling controls the waiting interval between subsequent originations of any specific LSA.
OSPF LSA throttling uses three time-based parameters to postpone an LSA’s re-originations; in other words, to configure the wait interval, which is the amount of time OSPF waits between two consecutive originations of the same LSA. These parameters are:
- Start-interval: represents the initial wait interval that should elapse before generating an updated version of the LSA because it corresponds to the first LSA change or the LSA has been unchanged for a long time period greater than the hold or max interval.
- Hold-interval: the minimum amount of time that must elapse between two successive originations of any particular LSA.
- Max-interval: the maximum amount of time OSPF waits between two subsequent originations of any particular LSA.
How Does OSPF LSA Throttling Work?
Here are the rules that control OSPF LSA throttling:
Rule #1: When OSPF detects a network change that requires updating a local LSA, OSPF delays the origination and flooding of the LSA until the current wait time elapses.
Rule #2: When OSPF detects a network change that causes updating a local LSA for the first time or after the LSA has been unchanged for more than hold-interval or max-interval, OSPF sets the wait time to start-interval. Otherwise, the wait time is set to the hold interval.
Rule #3: When OSPF updates and floods a particular LSA after detecting a network change for a period greater than hold-interval but less than max-interval, the hold interval parameter stays set to its current value.
Rule #4: When OSPF updates and floods a particular LSA after detecting a network change for a period greater than max-interval, the hold interval parameter gets set to its default value.
Rule #5: When OSPF originates and floods an LSA, it doubles the value of the hold interval if OSPF detects a network change, requiring updating the LSA, within the wait interval that is started from the moment of its previous regeneration.
In the next paragraphs, I demonstrate how LSA origination scheduling works through throttling. We enable OSPF debugging on router R2, and change the OSPF cost of R2’s GigabitEthernet 0/1 interface many times at instants t, t+7, t+20, t+60, t+100, t+345, and t+720 seconds, where t is 10:57:45.750 (ten fifty-seven forty-five seconds seven hundred fifty milliseconds). This will requires R2 to re-originate its router LSA several times.
The start, hold, and max intervals are set to 10 sec, 20 sec, and 300 sec, respectively. Besides, OSPF rate limit timer debugging has been enabled using the debug ip ospf database-timer rate-limit command in enable mode.
R2# debug ip ospf database-timer rate-limit
OSPF LSA rate limit timer debugging is on
R2#
Besides, the first updated version of R2’s router LSA has been produced after the router’s local links were unchanged for more than 300 seconds, the max interval.
- At time t, we set the OSPF cost of R2’s GigabitEthernet 0/1 interface to 11, which requires R2 to re-originate its router LSA. R2 first checks if the wait timer is already started; however, it did not. Next, R2 resets the wait interval value to start-interval, which is equal to 10 seconds, because its router LSA has been changed for a while as mentioned before, and then it initiates the LSA origination wait timer.
*Dec 20 10:57:45.750: OSPF-1 LIMIT: Check rate limiting for LSA 1/2.2.2.2/2.2.2.2 *Dec 20 10:57:45.751: OSPF-1 LIMIT: reset throttling to 10000ms next wait-interval 20000ms *Dec 20 10:57:45.751: OSPF-1 LIMIT: Starting rate limit timer for 2.2.2.2 2.2.2.2 1 with 10000ms delay
- At time t + 7 sec seconds, we change the OSPF cost of R2’s GigabitEthernet 0/1 interface to 12, which requires R2 to re-originate its router LSA. R2 first checks the wait timer, and it found it already started but not expired yet, and thus the router continues waiting for the timer to lapse.
*Dec 20 10:57:53.033: OSPF-1 LIMIT: Check rate limiting for LSA 1/2.2.2.2/2.2.2.2
- At time t + 10 sec, R2 re-originates its router LSA to reflect local link changes and sets the hold interval to 20 seconds, which is its default value.
*Dec 20 10:57:55.752: OSPF-1 LIMIT: Rate limit timer is expired for 2.2.2.2 2.2.2.2 1 *Dec 20 10:57:55.753: OSPF-1 LIMIT: Setting next wait-interval to 20000ms
- At time t + 20 seconds, we set the OSPF cost of R2’s GigabitEthernet 0/1 interface to 13, which requires R2 to re-originate its router LSA. R2 first checks if the wait timer is already started; however, it did not. Next, R2 starts the timer so that amount of time between the next and last originations of its router LSA is equal to hold-interval, which is 20 seconds.
*Dec 20 10:58:06.230: OSPF-1 LIMIT: Check rate limiting for LSA 1/2.2.2.2/2.2.2.2 *Dec 20 10:58:06.231: OSPF-1 LIMIT: Starting rate limit timer for 2.2.2.2 2.2.2.2 1 with 9524ms delay
- At time t + 30 sec, R2 re-originates its router LSA to reflect local link changes and sets the hold interval to 40 seconds, which is twice its previous value.
*Dec 20 10:58:15.757: OSPF-1 LIMIT: Rate limit timer is expired for 2.2.2.2 2.2.2.2 1 *Dec 20 10:58:15.759: OSPF-1 LIMIT: Setting next wait-interval to 40000ms
- At time t + 60 sec, we set the OSPF cost of R2’s GigabitEthernet 0/1 interface to 14, which requires R2 to re-originate its router LSA. R2 first checks if the wait timer is already started; however, it did not. Next, R2 starts the timer so that amount of time between the next and last originations of its router LSA is equal to hold-interval, which is 40 seconds.
*Dec 20 10:58:46.180: OSPF-1 LIMIT: Check rate limiting for LSA 1/2.2.2.2/2.2.2.2 *Dec 20 10:58:46.181: OSPF-1 LIMIT: Starting rate limit timer for 2.2.2.2 2.2.2.2 1 with 9578ms delay
- At time t + 70 sec, R2 re-originates its router LSA to reflect local link changes and sets the hold interval to 80 seconds, which is twice its previous value.
*Dec 20 10:58:55.761: OSPF-1 LIMIT: Rate limit timer is expired for 2.2.2.2 2.2.2.2 1 *Dec 20 10:58:55.762: OSPF-1 LIMIT: Setting next wait-interval to 80000ms
- At time t + 100 sec, we set the OSPF cost of R2’s GigabitEthernet 0/1 interface to 15, which requires R2 to re-originate its router LSA. R2 first checks if the wait timer is already started; however, it did not. Next, R2 starts the timer so that amount of time between the next and last originations of its router LSA is equal to hold-interval, which is 80 seconds.
*Dec 20 10:59:26.129: OSPF-1 LIMIT: Check rate limiting for LSA 1/2.2.2.2/2.2.2.2 *Dec 20 10:59:26.129: OSPF-1 LIMIT: Starting rate limit timer for 2.2.2.2 2.2.2.2 1 with 49634ms delay
- At time t + 150 sec, R2 re-originates its router LSA to reflect local link changes and sets the hold interval to 160 seconds, which is twice its previous value.
*Dec 20 15:00:15.765: OSPF-1 LIMIT: Rate limit timer is expired for 2.2.2.2 2.2.2.2 1 *Dec 20 15:00:15.766: OSPF-1 LIMIT: Setting next wait-interval to 160000ms
- At time t + 345 sec, we set the OSPF cost of R2’s GigabitEthernet 0/1 interface to 16, which requires R2 to re-originate its router LSA. R2 first checks if the wait timer is already started; however, it did not. R2 resets the wait interval value to start-interval, which is equal to 10 seconds, and then it initiates the LSA origination wait timer. Here is why.
The amount of time elapsed between instants t+150sec (the time of the previous re-origination of R2’s router LSA) and t + 345 sec (the time of the current OSPF change of interface GigabitEthernet 0/2) is 195sec, which is greater than the current hold interval (160 seconds) and less than the maximum interval.
During this time period, R2 did not make an OSPF change that implies updating its router LSA, and thus R2 resets the wait time to the start interval and then schedules re-origination of its type 1 LSA to run with a delay of 10 sec (the current start interval) after the time of detecting the OSPF change to its G0/2 interface, which is t + 345 sec. Therefore, R2 will create an updated version of its router LSA at instant t + 345s + current wait time, around t + 355 sec.
*Dec 20 15:03:31.123: OSPF-1 LIMIT: Check rate limiting for LSA 1/2.2.2.2/2.2.2.2 *Dec 20 15:03:31.123: OSPF-1 LIMIT: Delay throttle trigger by 10000ms next wait-interval 160000ms *Dec 20 15:03:31.124: OSPF-1 LIMIT: Starting rate limit timer for 2.2.2.2 2.2.2.2 1 with 10000ms delay
- At time t + 355 sec, R2 re-originates its router LSA to reflect local link changes and sets the hold interval to 160 seconds, which is its previous value, because R2’s router LSA didn’t need to be updated for a time period greater than the hold interval and less than the max interval.
*Dec 20 15:03:41.125: OSPF-1 LIMIT: Rate limit timer is expired for 2.2.2.2 2.2.2.2 1 *Dec 20 15:03:41.126: OSPF-1 LIMIT: Setting next wait-interval to 160000ms
- At time t + 720 sec, we set the OSPF cost of R2’s GigabitEthernet 0/1 interface to 17, which requires R2 to re-originate its router LSA. R2 first checks if the wait timer is already started; however, it did not. R2 resets the wait timer to start-interval because R2’s router LSA didn’t need to be updated since its last origination for a time period ( t + 720 sec – ( t + 355 sec )) greater than the max interval. Finally, R2 starts the wait timer.
*Dec 20 15:09:46.023: OSPF-1 LIMIT: Check rate limiting for LSA 1/2.2.2.2/2.2.2.2 *Dec 20 15:09:46.023: OSPF-1 LIMIT: reset throttling to 10000ms next wait-interval 20000ms *Dec 20 15:09:46.024: OSPF-1 LIMIT: Starting rate limit timer for 2.2.2.2 2.2.2.2 1 with 10000ms delay
- At time t + 730 sec, R2 re-originates its router LSA to reflect local link changes and sets the hold interval to 20 seconds, which is its default value, because of the same reason as for the wait timer.
*Dec 20 15:09:56.025: OSPF-1 LIMIT: Rate limit timer is expired for 2.2.2.2 2.2.2.2 1 *Dec 20 15:09:56.026: OSPF-1 LIMIT: Setting next wait-interval to 20000ms
How Does OSPF LSA Throttling Behave by Default on Cisco IOS?
The default values for LSA start, LSA hold, and LSA max-wait parameters on Cisco IOS are 0, 5, and 5 seconds, respectively. OSPF originates the first instance of an LSA immediately. This does not apply to received LSAs from other OSPF nodes.
Therefore, the wait time between two consecutive originations of the same LSA is at least 5 seconds. If an LSA has not been updated for a prolonged period of time, the LSA gets re-originated immediately when OSPF updates it.
Besides, the wait time and LSA hold fields are not increased gradually.
Configuring OSPF LSA Throttling on Cisco IOS
The timers throttle lsa all command, issued in the router configuration mode, enables the OSPF LSA throttling feature in Cisco IOS in order to rate-limit the origination of OSPF LSAs. The command requires three timer parameters, which are:
- Start interval: the amount of time in milliseconds OSPF used to initialize the wait time. It varies from 0 to 600000 ms.
- Hold interval: the minimum amount of time, expressed in milliseconds, that must pass between two subsequent originations of the same LSA. This timer’s value is adjustable from 1 to 600000 ms.
- Max interval: the maximum amount of time, in milliseconds, OSPF waits between two subsequent originations of the same LSA. Like the last timer, the range is from 1 to 600000 ms.
The following example configures OSPF LSA throttling on router R2 with 10, 20, and 100 seconds as the start, hold, and maximum intervals, respectively.
R1(config-if)# router ospf 1 R1(config-router)# timers throttle lsa all 10000 20000 300000
The show ip ospf command indicates the current configuration of the OSPF LSA throttling feature, as shown in the example below.
R2# show ip ospf Routing Process "ospf 1" with ID 2.2.2.2 Start time: 00:02:56.307, Time elapsed: 00:46:20.171 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 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 Initial LSA throttle delay 10000 msecs Minimum hold time for LSA throttle 20000 msecs Maximum wait time for LSA throttle 300000 msecs omitted output
Rate Limiting Throttling of Arriving OSPF LSAs
Cisco IOS allows throttling arriving LSAs by ignoring copies of the same LSA received in a short period of time, generally in milliseconds. If the timeframe between consecutive copies of the same LSA is less than a particular value, OSPF accepts the first one and rejects the others.
Note that an LSA can be distinguished by its originating router, link-state ID, and type.
The timers lsa arrival min_interval command allows setting the minimum time interval that should be elapsed before accepting a version of the same LSA, where min_interval is a number between 0 and 600000 milliseconds.
This example configures the minimum time interval for accepting the same LSA at 3000 milliseconds:
R2(config)# router ospf 1 R2(config-router)# timers lsa arrival 3000
To verify the configuration, use the show ip ospf command, as shown below.
R2# show ip ospf
Routing Process "ospf 1" with ID 2.2.2.2
Start time: 00:00:40.057, Time elapsed: 03:26:26.294
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
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
Initial LSA throttle delay 10000 msecs
Minimum hold time for LSA throttle 20000 msecs
Maximum wait time for LSA throttle 300000 msecs
Minimum LSA arrival 3000 msecs
omitted output
Related Lessons to OSPF LSA Throttling
- OSPF
- OSPF Router ID
- OSPF Null Authentication
- OSPF Plain Text Authentication
- OSPF Default Route
- Basic OSPF Configuration Lab for CCNA
- OSPF Configuration
- OSPF Passive Interface
- OSPF Virtual Link
- OSPF Stub Area
- OSPF LSA Types
- OSPF Graceful Restart
- OSPF Totally Stubby Area
- OSPF Reference Bandwidth
- OSPF Cost
- OSPF DR/BDR Election
- OSPF Hello and Dead Interval
- OSPF Metric
- OSPF MD5 Authentication
- OSPF HMAC-SHA Cryptographic Authentication
- OSPF Multi-Area
- OSPF TTL Security Check
- OSPF Graceful Shutdown
- Route Redistribution between OSPF and RIP
- OSPF Network Types
- OSPF Totally NSSA Area
- OSPF NSSA Area
- OSPF Summarization
- OSPF Route Filtering
- OSPF Type 5 LSA Filtering
- OSPF ABR Type 3 LSA Filtering
- OSPF Prefix Suppression
- OSPF Path Selection
- OSPF LSA Throttling
- OSPF SPF Throttling
- OSPF Incremental SPF
- OSPF Non-Broadcast Network Type
- OSPF Point-to-Point Network Type
- OSPF Broadcast Network Type
- OSPF Point-to-Multipoint Network Type
- OSPF vs RIP
- OSPF LSA Group Pacing
- OSPF LSA Flood Pacing
- OSPF LSA Retransmission Pacing
- Troubleshooting OSPF Neighbor Adjacency
- Troubleshooting OSPF Route Installation
- Troubleshooting OSPF Route Advertisement
- OSPF Stub Router
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.