FRR Node Protection (XR)
Load mpls.te.frr.init.cfg
A TE tunnel using the path XRv11 - XRv12 - CSR9 - CSR1 - CSR4 is setup on XRv11. Configure FRR node protection so that if CSR9 goes down, traffic is rerouted around this failure at XR12 and stitched back together at CSR1. Test that the fast reroute works by shutting Gi2 on CSR9 and Gi0/0/0/0.592 on XRv12.
Answer
Node protection is very similar to link protection, except the backup tunnel excludes the entire node rather than just a link address. This is sometimes called a NNHOP (next next-hop) tunnel because XRv12 is repairing the path at the next-hop of its own next-hop, which is CSR1.
XRv12 must learn CSR1’s label for the primary path. This happens via RSVP. When XRv12 request fast-reroute for node protection specifically, a label recording option is requested in the PATH message. The RRO in the RESV message contains the label at every single hop. This allows any NNHOP tunnel to be built along the LSP.
Note that requesting node protection specifically does not appear to be necessary. The label recording request happens whether or not node protection is requested. The node option, to me, appears to be an interoperability feature to work with non-Cisco devices in the MPLS-TE domain. The node option turns on the “node protection requested” flag in the PATH message. But on an IOS-XE or IOS-XR PLR, it does not appear to need this flag in order to provide node protection. The link or node protection designation is simply based on the backup tunnel’s destination.
Just like with link protection, we can see that XRv12 is ready to protect the primary tunnel.
The backup tunnel is taking the path XRv12-CSR6-CSR1:
We must bring down both Gi2 on CSR9 and Gi0/0/0/0.592 on XRv12. This is because XRv does not support BFD, nor RSVP Hellos. Once the interfaces are down, we can see the FRR status is “active.” This will stay in place permanently, because the primary path has only an explicit-path that must go through CSR9, which is now down.
We can see at XRv11 it is in “reroute pending” although the tunnel remains up and connected.
If XRv11 finds a new path, the FRR protection would go away on XRv12. On XRv11 we can see that the last error is from XRv12 which signaled a PathErr but that local repair was in place. This allowed XRv11 to try to do make-before-break.
Last updated
