BFD/TI-LFA Detection and BGP NSR on RP Failover
A regional ISP runs SR-MPLS with TI-LFA in its core. Aggregation routers A1 and A2 are dual-homed to core P1 and P2; BFD is enabled on all core links with a 300 ms interval and multiplier 3. TI-LFA is enabled only on the P1-P2 and P2-A2 links; A1's uplinks are protected by plain IGP fast convergence. During a test, the P1-P2 link fails, and traffic from A1 to a prefix behind P2 drops for about 900 ms. A second test reloads P2's standby route processor; the BGP session to an external peer resets, and routes are withdrawn for 45 seconds. P2 runs IOS XR with NSR-capable hardware, but nsr is not configured under BGP. The operator wants sub-50 ms protection and no BGP flap on RP switchover.
1. Why is the loss 900 ms when TI-LFA is enabled, and what would you change to meet sub-50 ms?
Read the worked answer
TI-LFA is a local repair mechanism; it does not detect the failure. The repair path is installed in the forwarding plane, but traffic still follows the failed link until BFD declares the neighbor down. With a 300 ms interval and multiplier 3, detection is about 900 ms, which matches the measured loss. TI-LFA then converges quickly, but the detection timer dominates. To meet sub-50 ms, reduce BFD to the minimum supported by the platform and line cards, for example 10 ms x 3 or 20 ms x 3, and enable hardware offload for BFD if available. Also enable TI-LFA on every link in the protected topology, not only P1-P2 and P2-A2; A1's uplinks need a repair path too. Verify that the TI-LFA backup label stack is present for the affected prefix and that the SRGB is consistent. Test with a link failure while watching show isis fast-reroute and show mpls forwarding to confirm the repair path is used before BFD expires.
2. What is the difference between NSF and NSR in this BGP reset, and what configuration is missing?
Read the worked answer
NSF/graceful restart is neighbor-assisted. The restarting router's control plane loses state, peers detect the restart, mark routes stale, and keep forwarding for a bounded time while the router rebuilds. BGP may still reset the TCP session, and if the peer is not a helper or the restart exceeds the timer, routes are withdrawn. NSR keeps the BGP and TCP state synchronized between active and standby route processors, so an RP switchover does not reset the session or require neighbor assistance. In this scenario the hardware is NSR-capable but nsr is not configured under BGP, so the standby RP does not have the session state and the peer sees a reset. Configure nsr under router bgp and ensure the underlying transport and line cards support it, then test an RP failover and confirm the session stays up. Keep graceful restart as an interop fallback for peers that do not support NSR, but do not rely on it to prevent this local flap.