Microloop Avoidance

Load microloop.avoidance.init.cfg

#R3-R6, R9, R10 only
configure
load bootflash:microloop.avoidance.init.cfg
commit replace
y

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:

#R4
ping 10.10.10.1 so lo1 repeat 1000000 time 1

Use microloop avoidance to solve this problem.

Answer

#R4
router isis 1
 add ipv4
  microloop avoidance segment-routing

Explanation

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.

router isis 1
 address-family ipv4 unicast
  microloop avoidance rib-update-delay msec

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.