FRR Backup Auto-Tunnels with SRLG

Load mpls.te.frr.init.cfg

#IOS-XE
config replace flash:mpls.te.frr.init.cfg

#IOS-XR
configure
load bootflash:mpls.te.frr.init.cfg
commit replace
y

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

#CSR8
int tun0
 tunnel mpls traffic-eng fast-reroute

#XR11
int tunnel-te0
 fast-reroute

#CSR9
int GigabitEthernet2.529
 srlg gid 10
int GigabitEthernet2.592
 srlg gid 10
int GigabitEthernet2.569
 srlg gid 10
int GigabitEthernet2.590
 srlg gid 10
!
mpls traffic-eng auto-tunnel backup nhop-only
mpls traffic-eng auto-tunnel backup srlg exclude force

#XR12
ipv4 unnumbered mpls traffic-eng lo0
!
srlg
 interface GigabitEthernet0/0/0/0.502
  1 value 10
 interface GigabitEthernet0/0/0/0.592
  1 value 10
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.592
  auto-tunnel backup exclude srlg
  auto-tunnel backup nhop-only
 !
 auto-tunnel backup tunnel-id min 100 max 199

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:

#IOS-XE
int GigabitEthernet1
 srlg gid <value>    ! Where gid is "global ID"

#IOS-XR
srlg
 interface GigabitEthernet0/0/0/0
  1 value <value>    ! Where 1 is the index number

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.

CSR9(config)#mpls traffic-eng auto-tunnel backup srlg exclude ?
  force      Backup tunnels MUST not use SRLGs of protected interfaces
  preferred  Backup tunnels try to avoid using SRLGs of protected interfaces

On IOS-XR, the default is force, and optionally you can override this using preferred.

RP/0/0/CPU0:XRv12(config-mpls-te-if)#  auto-tunnel backup exclude srlg ?
  preferred  SRLG exclusion is preferred but not mandatory
  weighted   If SRLG is shared admin weight of the SRLG is added to link metric
  <cr>

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.