FRR Multiple Backup Tunnels (Node Protection)

Load mpls.te.frr.multi.node.init.cfg

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

#IOS-XR (XR1, XR2 only)
configure
load bootflash:mpls.te.frr.multi.node.init.cfg
commit replace
y

There are two TE tunnels setup:

• CSR8-CSR9-CSR3-CSR2-CSR5

• CSR8-CSR9-CSR3-CSR10-CSR5

Configure CSR9 for node protection, protecting both LSPs when the link to CSR3 fails. The tunnels on CSR8 already request FRR protection.

Answer

#CSR9
ip explicit-path name AVOID_CSR3
 exclude-address 3.3.3.3
!
int tun0
 tunnel destination 2.2.2.2
 ip unn lo0
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng path-option 1 explicit name AVOID_CSR3
!
int tun1
 tunnel destination 10.10.10.10
 ip unn lo0
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng path-option 1 explicit name AVOID_CSR3
!
int gi2.539
 mpls traffic-eng backup tun0
 mpls traffic-eng backup tun1

We can also apply RSVP Hellos to better detect failure:

#CSR3, CSR9
ip rsvp signalling hello
!
int gi2.539
 ip rsvp signalling hello

Explanation

The PLR can have multiple backup tunnels applied to a single interface. When the tunnels have the same NHOP, primary LSPs are round-robined across each backup tunnel. Each LSP is only associated with one backup tunnel though. When the backup tunnels have different destinations, the router is smart enough to understand which backup tunnels are available/applicable to which primary LSPs. When both a NNHOP and NHOP backup tunnel exist, the router prefers the NNHOP tunnel, as that protects both the link and the node.

On CSR9, we can see that both LSPs have their appropriate backup tunnel assigned. Tun0 has a destination of CSR2, and Tun1 has a destination of CSR10. CSR8’s Tun0 goes through CSR2, and CSR8’s Tun1 goes through CSR10, so this is correct.

When the CSR3-CSR9 link goes down, CSR9 will activate both at the same time:

#CSR3
int gi2.539
 shut