Microloop Avoidance
Last updated
Last updated
Load microloop.avoidance.init.cfg
A ring topology is configured, pictured above. The R4-R10 link has a high metric, and the R6-R10 link is currently shutdown on R6.
The routers have the following SPF intervals:
R3
500msec
R9
2000msec
R5
4000msec
Run an extended ping from R4 to 10.10.10.1/32, and then bring up the R6-R10 link. Notice how long it takes for routing to converge:
Use microloop avoidance to solve this problem.
Microloops occur when nodes update their forwarding tables at different intervals. This was artifically introduced in this lab by setting the SPF intervals to very high values.
When the R6-R10 link comes up, R4 will immediately run SPF and switch over to the path via R3. However, R3 will delay running SPF. During this time, R3 still believes the best route to 10.10.10.1/32 is via R4. So a microloop will occur, during which time other non-looping traffic might also be affected due to high utlization on the link. Once R3 converges, it switches over to using R9 as a nexthop. But R9 delayed its own SPF run even longer, so again a microloop occurs. This repeats on the R9-R5 link as well.
SR has a very simple solution, which is to use the TI-LFA tools to be able to force paths when microloops are possible due to a topology change. Microloops can occur during any topology change event, such as link up, link down, or metric change.
In some situations, the router might instead just continue forwarding on the old path and delay switching over to the new path, instead of pushing a SID list. This is what R4 actually does in this case. When you run the ping again and bring the R6-R10 link up, no pings are lost, as R4 waits sufficient time before switching over to the new path. You can control how long the router will wait before updating the RIB using the following command. The default is 5 seconds.
We can forcefully test that microloop avoidance uses TI-LFA by moving the test to R3. We’ll remove microloop avoidance on R4, and add it to R3. We’ll also remove the SPF delay on R3. When we bring the link up, we see a microloop between R3 and R4. R3 is not pushing something like an Adj-SID to force R4 to steer the traffic out the link to R10. R3 also has TI-LFA activated on its interfaces, but it does not make a difference. Perhaps this is a limitation with XRv.
