FRR Multiple Backup Tunnels (Backwidth/Link Protection)

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

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

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

There are four TE tunnels setup on the path CSR8-CSR9-CSR3-CSR2, each signalling 100M of bandwidth

• Configure CSR9 for link protection, using two backup paths.

  • One backup tunnel should use CSR9-CSR1-CSR3, and another should use CSR9-CSR10-CSR3.

  • The path through CSR10 only has 100M available, so only one LSP should be backed up on this tunnel.

Answer

#CSR9
ip explicit-path name CSR9-CSR1-CSR3
 next-address 1.1.1.1
 next-address 3.3.3.3
!
ip explicit-path name CSR9-CSR10-CSR3
 next-address 10.10.10.10
 next-address 3.3.3.3
!
int tun0
 tunnel dest 3.3.3.3
 ip unn lo0
 tunnel mode mpls traffic-eng 
 tunnel mpls traffic-eng path-option 1 explicit name CSR9-CSR1-CSR3
!
int tun1
 tunnel dest 3.3.3.3
 ip unn lo0
 tunnel mode mpls traffic-eng 
 tunnel mpls traffic-eng path-option 1 explicit name CSR9-CSR10-CSR3
 tunnel mpls traffic-eng backup-bw 100000
!
int gi2.539
 mpls traffic-eng backup tun0
 mpls traffic-eng backup tun1

Explanation

When using multiple backup tunnels per interface, we also have the option of limiting how much bandwidth we want to use on each backup tunnel. This bandwidth is not signalled. Instead it is used to do admission control when permiting primary LSPs over backup tunnels.

This is controlled using the backup-bw command:

#CSR9
int tun1
 tunnel mpls traffic-eng backup-bw 100000

Because all primary LSPs are each signalling 100M of bandwidth, only one primary LSP can be protected by Tun1. We can verify this on CSR9:

Notice that CSR8’s tun0 (the first one listed) has Tun1, while the other three have Tun0. There is a reason for this. When the router picks which backup tunnel to use for a given primary LSP, first the backup tunnels with limited backup-bw are evaluated. Tun1 had enough room, so it was used. The second through fourth LSPs then only had the option of Tun0, which has unlimited backup-bw. So the router will fill up backup tunnels that have limited bandwidth before filling up unlimited bw backup tunnels.

Note that we can also explicitly define unlimited backup-bw for a tunnel as follows. However, this limits us to either the global-pool or sub-pool.

#IOS-XE
int tun0 
 tunnel mpls traffic-eng backup-bw global-pool unlimited

If you configure this for the sub-pool, it means that no bandwidth is available for the global-pool.

#CSR9
int tun0 
 tunnel mpls traffic-eng backup-bw sub-pool 100000

On CSR9, all three LSPs that were using tun0 for backup have dissappeared. This is because Tun0 now has zero global-pool backup-bw.

Note that you can also specify backup-bw for DS-TE LSPs as well, using the sub-pool for traditional DS-TE, or class-type for IETF DS-TE.

#IOS-XE
int tun0
 tunnel mpls traffic-eng backup-bw class-type 1 100000

Also, be careful when using this feature in general, as an LSP that requests no bandwidth cannot be protected by an LSP that has backup-bw. This seems a little bit like a bug, but appears to be how the feature is supposed to work. For example, if we remove the signalled bandwidth on CSR8’s tunnels, and add backup-bw to CSR9’s tun0, no LSPs will be protected.

#CSR8
int range tun0-3
 shut
 no tunnel mpls traffic-eng bandwidth
 no shut

#CSR9
int tun0
 tunnel mpls traffic-eng backup-bw 1000000