IGP TE Flooding Thresholds
Load mpls.te.base.config.with.ospf.cfg
Configure R8 and XR11 to flood TED information upon the following up and down thresholds:
5 10 80 90
Configure R9 and XR12 to flood periodic TED changes which weren’t trigged by a threshold every 10 minutes.
Create bi-directional TE tunnels between R8 and XR11 that go through R9 and XR12 which reserve 100M. Which routers flood changes immediately into the IGP?
Answer
Explanation
The TED must be kept up-to-date with all links in the topology and their associated available bandwidth, link affinity, and TE metrics. If many LSPs are reserved and torn down constantly, the available bandwidth values can change often, requiring lots of IGP flooding.
To minimize this flooding, but still keep the TED somewhat up-to-date, default thresholds are used to determine when to flood information upon changes in available bandwidth. By default, the following thresholds are used on IOS-XE and IOS-XR for both up and down changes in bandwidth:
When bandwidth consumed crosses one of the up thresholds, the IGP is flooded with the current bandwidth allocations. Likewise, when bandwidth consumed goes down and crosses one of the down thresholds, this information is flooded via the IGP.
We can set these values on a per-interface basis using the following commands on IOS-XE and IOS-XR:
If a change in bandwidth happens that doesn’t cross a threshold, then this information is flooded when the periodic flooding timer is triggered. By default, this is every minute on IOS-XE, and every 3 minutes on IOS-XR. We can control this globally using the following commands:
Also note that IGP flooding occurs when RSVP encounters an error due to path setup because of a lack of bandwidth. This must mean that the headend does not have an updated TED and thinks there is more bandwidth available than there actually is. So this triggers flooding on the router which encountered the error.
There is also a bandwidth-hold timer knob. This controls how long bandwidth is reserved on the interface during path setup. If the timer expires but the path setup has not been completed, the bandwidth allocation is freed up. By default this is 15 seconds.
IOS-XR also allows us to tune the preemption-delay. This appears to control how long to wait before preempting an LSP. The default appears to be 0 seconds.
Verification
First we’ll verify the thresholds on R8 and XR11. We’ll only check one interface for brevity.
Next we’ll setup the paths between R8 and XR11 which each reserve 100M. Check the TED on any router in the topology, for example R5. We can see that R8 and XR11 have immediately flooded their new bandwidth values, but R8 and XR12 have not.
R9 and XR12 have not advertised their updated bandwidth values yet because bandwidth allocation went up but did not pass the first 15% threshold mark. Once the periodic-flooding timer expires, we should see the updated information.
Last updated
