FRR Path Protection
Load mpls.te.frr.init.cfg
A TE tunnel using the path CSR8-CSR9-CSR10-CSR5 is setup on CSR8. Configure FRR path protection so that if the primary path goes down, traffic is rerouted around this failure using a pre-signaled path of CSR8-CSR1-CSR3-CSR2-CSR5. Test by shutting down the CSR9-CSR10 link.
Additionally, configure TE-tunnel 0 on XR11 for path-protection, simply using a dynamic path for the standby LSP.
Answer
Path protection involves pre-calculating and signalling a secondary path option from the headend. Upon receiving notification that the primary path is no longer up (via RESV tear, local detection, etc), the headend will immediately switch traffic onto the backup TE tunnel. This is a completely separate TE tunnel that is already signaled from the headend to the tailend, using a separate path-option.
Path protection is not nearly as fast as link or node protection, because the protection is not always happening at the PLR (unless the headend itself is the PLR). If the link down event happens 5 nodes away, this has to be detected, then signaled to the headend which is not guaranteed to happen within 50 msec. The only thing path protection helps you with is not having to run CSPF again and signal the new path.
When using path protection we need to make sure to not use tunnel mpls traffic-eng fast-reroute. We aren’t really using FRR on the primary path itself, instead the headend is creating a separate TE tunnel and will locally switch to that tunnel.
Note that path-protection on IOS-XR is enabled as its own command. A path-option is not explicitly associated with the protection. Instead, IOS-XR appears to be smart enough to calculate a completely path divert backup path to use as its standby LSP. You can also use an explicit-path as your backup path-option if desired.
Note that the following syntax also appears to work:
Verification - CSR8
You may need to shut/no shut the tunnel. You should see that the backup tunnel has been pre-signaled and shares 0 common nodes:
Add the parameter protection to see more details. We an see the primary LSP path and protection LSP path.
We can also see on any node along the protection LSP that the TE tunnel is fully signaled:
If we shut down Gi2.590 on CSR9, we should see that the backup LSP is now in use on CSR8.
This will last indefinitely, as CSR8 cannot satisfy path-option 1. However, if it was able to find a new LSP that satisfies the original path-option, we would see that the path protection would only be temporary.
Also note that if the backup path option is not valid, you will see “Path Protection: Requested” - it has been requested but could not be fulfilled. This appears to be the case when you use a path-option number that is not the same as the normal path-option.
If we change the primary path-option to 2, it appears to work.
If the protected path is not valid, that will also cause path protection to only show “Requested.” Here I shut down the CSR3-CSR2 link. Now the strict explicit path-option cannot be satisfied:
If I change the explicit-path to use loose next-addresses, it can now be setup.
Above, the protection LSP goes CSR1-CSR3-CSR2, but actually takes the path through CSR10.
Verification - XR11
Path-protection on IOS-XR is fairly simple. The feature is enabled under the TE tunnel, and you must give it an additional path-option to use as its standby LSP.
We can see that the router now has two separate LSPs for the tunnel:
Path option 1 is what is actually used for setup, and path option 2 is used for the standby LSP. This LSP is fully signaled. For example, we can see that the LSP is up on R3:
If we bring down the XR12-R9 link, we should see this LSP becomes active:
Above, XR11 immediately switches over to the standby LSP and then generates a new standby path. We can see this second path below:
Could we use a single dynamic path-option with the path-protection command?
Unfortunately this does not work. It seems that the router needs a second option in order to calculate and setup the standby LSP. The router appears to be able to only use a single path-option for both setup and standby LSPs when the primary LSP path-option has failed.
Update 4-23-24: I found the following passage in MPLS in the SDN Era:
It could be in this lab that there is not a secondary path that is completely distinct from the primary path? However in this topology, there should be a valid secondary path.
Last updated
