No LFA on a Ring and the TI-LFA Repair List
Six Nokia SR OS routers form a ring: R1-R2-R3-R4-R5-R6-R1. All links are Level 2 point-to-point with symmetric wide metric 10, and each router advertises a /32 loopback with a prefix SID from SRGB 16000-23999: R1=16001 through R6=16006. Segment routing and IS-IS are enabled, and loopfree-alternate is configured on all routers. The design requires sub-50 ms protection for the loopbacks. A test fails over the R2-R3 link: traffic from R1 to R3's loopback 10.3.3.3/32 and to the service prefix 172.16.3.0/24 behind R3 is dropped for about 200 ms. The show command on R1 lists no backup next-hop for either prefix, although backups exist for other prefixes such as R4's loopback. The SRGB is consistent and all prefix SIDs are advertised at Level 2. The customer asks whether TI-LFA would fix it and what else must be checked.
1. Why does R1 have no LFA for 10.3.3.3/32 even though it has two neighbors?
Read the worked answer
R1's primary next-hop for R3 is R2, cost 20. The only alternate neighbor is R6. R6's shortest path to R3 is 30 (via R5-R4-R3, or equal-cost via R1-R2-R3). The loop-free condition requires the alternate neighbor's distance to the destination to be less than its distance to the source plus the source's distance to the destination, i.e. 30 < 10 + 20. That is false (30 < 30 is not true), so R6 is not a loop-free alternate; if R1 sent traffic to R6, R6 could send it back across R1 to reach R3. R4's loopback works as an LFA because R6's path to R4 (20) does not traverse R1 and satisfies the inequality. The absence of a backup is therefore a topology and inequality result, not a misconfiguration of the prefix SID.
2. How would TI-LFA provide protection, and what repair list would you expect?
Read the worked answer
TI-LFA computes the post-convergence path after the protected link fails and encodes it as a segment list, so the alternate does not have to be loop-free under the pre-failure topology. After R1-R2 fails, R1's post-convergence path to R3 is R1-R6-R5-R4-R3. R1 can impose a repair list containing the adjacency SID of R1-R6 and, if needed, the adjacency SID of R6-R5 or a node SID for R5, followed by R3's prefix SID 16003. MPLS then forwards the packet along the repair path without relying on R6's pre-convergence routing table, which might still point back to R1. The result is sub-50 ms protection instead of waiting for SPF. The exact repair list depends on the P-space/Q-space computation and the MSD of the ingress line card; the point is that the list encodes the intended post-convergence path.
3. What would you verify on the routers and line cards before declaring the problem solved?
Read the worked answer
Verify that loopfree-alternate is enabled with TI-LFA, not LFA only, at Level 2, and that the protected prefixes have a backup next-hop in show router isis routes and a repair list in the MPLS or SR show commands. Confirm SRGB consistency and that 16003 is advertised at Level 2 and installed; a prefix SID that is local-only or filtered breaks the repair. Check the maximum SID depth of the ingress line card against the repair list length: a 3-label list on a card that supports 2 will not install. Confirm SR/MSD support on the egress path, and that no policy is filtering the prefix or its SID. Finally, repeat the failover test rather than trusting the control plane, and check that the backup path uses R6-R5-R4-R3 and not a path that returns through R1.