FRR Backup Auto-Tunnels

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 XRv11 - XRv12 - CSR9 - CSR1 - CSR4 is setup on XRv11.

Configure FRR link protection on all mid role LSRs (XRv12, CSR9, CSR1). Use autotunnel with a tunnel ID range of 10000-10100.

Answer

#CSR1, CSR9
mpls traffic-eng auto-tunnel backup nhop-only
mpls traffic-eng auto-tunnel backup tunnel-num min 10000 max 10100

#XRv11
int tunnel-te 0
 fast-reroute

#XRv12
ipv4 unnumbered mpls traffic-eng lo0
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.592
  auto-tunnel backup
   nhop-only
 !
 auto-tunnel backup
  tunnel-id min 10000 max 10100

Explanation

Auto-tunnel is a very handy feature, which automatically creates fully meshed primary tunnels, one hop tunnels, or backup tunnels. As we’ve seen in all the previous FRR labs, configuring backup tunnels can be quite configuration intensive and not very scalable. You must manually define explicit paths, tunnel interfaces, and associate them with the correct interface. When a new node gets added to the network, you’re looking at potentially a few hours of extra work on your hands. If you use auto-tunnel for backup tunnels instead, the router will do all of this automatically.

By default, the router creates both a NHOP tunnel and NNHOP tunnel for every protected LSP. If LSPs overlap in terms of the tunnel’s destination, a duplicate tunnel is not created. The NNHOP is always preferred, because it inherently provides both link and node protection. You can instruct the router to only create a NHOP tunnel and not do node protection with the following command:

#IOS-XE
mpls traffic-eng auto-tunnel backup nhop-only

#IOS-XR
mpls traffic-eng
 interface GigabitEthernet0/0/0/0
  auto-tunnel backup
   nhop-only

On IOS-XE, the global command mpls traffic-eng auto-tunnel backup is enough to automatically create backup tunnel interfaces and fully utilize the feature. You can also specify the range of tunnel IDs, require the backup tunnels to use an affinity, and configure how long to wait before removing unused backup tunnels. You can also manually specify the source address. By default it is assumed to be Lo0.

#IOS-XE
mpls traffic-eng auto-tunnel backup tunnel-num min value max value
mpls traffic-eng auto-tunnel backup config affinity value mask value
mpls traffic-eng auto-tunnel backup timers removal unused seconds
mpls traffic-eng auto-tunnel backup config unnumbered-interface Lo0

On IOS-XR, we must apply auto-tunnel configuration to the interfaces themselves. The attribute set is used to apply an affinity constraint. The exclude srlg command can be used to force the backup path to use an srlg-disjoint path. (This means the backup tunnel will not use an interface that belongs to the same SRLG as the protected interface).

#IOS-XR
mpls traffic-eng
 interface GigabitEthernet0/0/0/0
  auto-tunnel backup
   [nhop-only]
   [attribute-set name]
   [exclude srlg [preferred|weighted]]
   

On IOS-XR, when using auto-tunnels, you must also manually specify the source address. However, the command is almost a “hidden” command, because it is configured globally, not under mpls traffic-eng as you would expect! IOS-XR does not make the assumption that you want to use Lo0 as IOS-XE does.

#XRv12
ipv4 unnumbered mpls traffic-eng lo0

Additionally, on IOS-XR, the global parameters for auto-tunnel backup are configured under mpls traffic-eng auto-tunnel backup. You must specify a tunnel ID range on IOS-XR. IOS-XE can use 65436-65535 by default if none is specified.

#IOS-XR
mpls traffic-eng
 auto-tunnel backup
  [affinity ignore]
  [timers removal unused sec]
  tunnel-id min <value> max <value>

If you forget to set the unnumber interface or the tunnel-id range, you can see the reason the auto-tunnel is down in the “Reason for tunnel being down” section (last line of output).

Verification

We can use our standard verification tools for general FRR to verify that the auto-tunnel backup paths worked.

On R1, the outgoing label is implicit-null, as it is the penultimate hop.

We can see the path the same way as with any other TE tunnel.

Notice that an explicit path was automatically created and applied to the tunnel10000 interface:

Also note that this tunnel cannot be seen in the running-config, as it is a dynamic tunnel interface. However you can view the generated config using show derived-config int tun10000.

On XRv12, we can preform this same verification.

We also see that a dynamic explicit-path was created, however it doesn’t appear that we can view it.