FRR Backup Auto-Tunnels with SRLG
Load mpls.te.frr.init.cfg
A TE tunnel using the path CSR8-CSR9-CSR10-CSR5 is setup on CSR8. Configure automatic FRR link protection on CSR9 so that if the CSR9-CSR10 link goes down, traffic is rerouted around this failure and stitched back together on CSR10. Ensure that the backup tunnel does not use the links to XR12, CSR2, or CSR6.
Additionally, there is a TE tunnel from XR11 to CSR4 that passes through XR12-CSR9. Configure automatic FRR link protection on XR12 with a backup path that does not use the link to CSR10.
Answer
Explanation
SRLG (Shared Risk Link Group) is a mechanism for marking interfaces that should be grouped together because they share the same fate. An example of this is links that all share the same conduit, or links that use different wavelengths of the same fiber. If one fiber is cut, it is very likely other fibers in this conduit would be cut.
If your backup path ends up using a fiber that is in the same conduit as the primary path, then you have a good chance of both your primary and backup path going down at the same time, and therefore not providing fast reroute protection. To solve this, you can assign links that share the same fate to the same SRLG group. Then you tell the router to calculate auto-tunnels using SRLG in either preferred or force mode. In preferred mode, the router tries to calculate backup paths that don’t use links in the same SRLG, but if it can’t find any paths, it still calculates a backup path anyway. In force mode, the backup path will not come up unless it is a path which strictly does not contain a link in the same SRLG group as the primary link. (It is srlg-disjoint).
To assign an SRLG to a link, you use the following commands:
This information is flooded into the IGP as another attribute on the link, just like TE metric, affinity, and available bandwidth. We can see the SRLG information of links in the TED as follows:
We can also see all SRLG values and their links in the topology using this command:
The force and preferred keywords for SRLG protection for auto-backup tunnels requires a closer look. On IOS-XE, you must specify either force or preferred.
On IOS-XR, the default is force, and optionally you can override this using preferred.
Verification
On CSR9, we should see that the CSR9-CSR10 link is protected for the CSR8-CSR5 LSP, and that it is using CSR3 for the backup path. All of CSR9’s directly connected neighbors which are themselves also directly connected to CSR10, are in the same SRLG. Also, since we specified nhop-only, the router is not allowed to calculate node-protecting backup paths. This leaves CSR9-CSR3-CSR10 as the best possible backup path.
On XR12, we have a similar situation. We must use a nhop-only tunnel, and the XR12-CSR9 and XR12-CSR10 links are in the same SRLG, leaving XR12-CSR6-CSR9 as the best link-protecting backup path. However, this actually can’t be used, because the CSR9-CSR6 link is also in SRLG 10. If you happened to make the SRLG group IDs different on CSR9 and CSR10, then that would be a valid solution and you would see XR12-CSR6-CSR9. However, I instead see XR12-CSR6-CSR1-CSR9.
So as you can see, the router takes into account not just the local SRLG values, but the SRLG values for other routers in the topology. Essentially, SRLG is just another possible constraint that you can use, and it is flooded with all TE information as admin weight and affinity.
Note that IPFRR (LFA and TI-LFA) do not take into account the SRLG values of other routers in the topology. The router can only use local SRLG values for srlg-disjoint LFA/TI-LFA backup paths.
Last updated
