RDM w/ FRR Troubleshooting

Load rdm.frr.tshoot.cfg

#IOS-XE
config replace flash:rdm.frr.tshoot.cfg

#IOS-XR
configure
load bootflash:rdm.frr.tshoot.cfg
commit replace
y

All nodes have DS-TE configured in IETF mode using RDM as the bc-model.

A TE tunnel is setup on the path CSR8-CSR6-XR12-XR11. CSR6 has a local backup tunnel configured and applied to the R6-XR12 interface, but the path does not seem to be providing backup to CSR8’s tunnel. Fix the issue.

Answer

# OPTION 1
#R6
int tun100
 no tunnel mpls traffic-eng backup-bw class-type 1 10000

# OPTION 2
#R6
int tun100
 no tunnel mpls traffic-eng backup-bw class-type 1 10000
 tunnel mpls traffic-eng backup-bw class-type 0 95000

# OPTION 3
#R6
int tun100
 no tunnel mpls traffic-eng backup-bw class-type 1 10000
 tunnel mpls traffic-eng backup-bw class-type 0 unlimited

# OPTION 4
#R6
int tun100
 no tunnel mpls traffic-eng backup-bw class-type 1 10000
 tunnel mpls traffic-eng backup-bw 95000

Explanation

A backup tunnel can use the backup-bw parameter to ensure that it takes a path that has available bandwidth. Primary tunnels will only use the repair tunnel if the repair tunnel can satisfy the bandwidth demand.

In this lab, we can see that R6 has given tun100 10M of backup-bw for CT1.

interface Tunnel100
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 12.12.12.12
 tunnel mpls traffic-eng backup-bw class-type 1 10000
 tunnel mpls traffic-eng path-option 1 explicit name AVOID_R6-XR12_LINK

The tunnel is correctly applied to the interface as a backup tunnel, yet we see that it is not providing protection:

interface GigabitEthernet2.562
 encapsulation dot1Q 3562
 ip address 132.6.12.6 255.255.255.0
 ip ospf message-digest-key 1 md5 OSPF_AUTH
 ip ospf network point-to-point
 mpls traffic-eng tunnels
 mpls traffic-eng backup-path Tunnel100
 ip rsvp bandwidth rdm bc0 100000 bc1 10000

The reason for this is that the primary tunnel uses 95M of CT0 bandwidth. The backup tunnel cannot satisfy this because it only provides 10M of CT1 bandwidth. The backup tunnel must be able to accomodate the primary tunnel’s pool of bandwidth and the amount of bandwidth.

We have several ways to fix this:

• We can remove the backup-bw command altogether. This means that the tunnel does not have a specific bandup-bw pool so any LSP will be able to use it for a repair path.

• We can set the backup-bw pool to use CT0 specifically

• We can set the backup-bw pool to use any pool

Using CT0

We can configure R6 to have its backup tunnel use at least 95M of CT0 bandwidth as follows:

#R6
int tun100
 no tunnel mpls traffic-eng backup-bw class-type 1 10000
 tunnel mpls traffic-eng backup-bw class-type 0 95000|unlimited

When the class-type matches, the available bandwidth on the backup tunnel needs to be at least the amount that the primary LSP is using. As long as we provide at least 95M of available backup-bw, the LSP can be protected:

Using “any” pool

Alternatively, the backup tunnel can use “any” pool to allow both CT0 and CT1 LSPs to be protected by this backup tunnel. By omitting the class-type keyword, “any” pool is used.

#R6
int tun100
 no tunnel mpls traffic-eng backup-bw class-type 1 10000
 tunnel mpls traffic-eng backup-bw 95000

If we change the LSP at CSR8 to use CT1 bandwidth, this same backup tunnel can still protect it:

#CSR8
int tun0
 no tunnel mpls traffic-eng bandwidth 95000 class-type 0
 tunnel mpls traffic-eng bandwidth 8000 class-type 1

Backup tunnel selection process

Multiple backup tunnels can be applied to an interface. When this happens, the router uses the following selection criteria to prefer one backup tunnel over another:

• NNHOP tunnels are preferred over NHOP, because they provide both link and node protection

• Backup tunnels that have a limited amount of backup-bw are preferred over backup tunnels that have unlimited backup-bw

  • This can be considered a “max-fill” decision

• Backup-bw that comes from the same pool as the class-type of the protected tunnel is preferred

Remember that configuring backup-bw on a repair tunnel does not actually reserve bandwidth over that path. This is only a local decision at the PLR to make sure the backup path has enough bandwidth to satisfy the protected tunnel. It does not explicitly reserve bandwidth using RSVP over the backup path.