FRR Link Protection (XE, RSVP Hellos)

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 FRR link protection so that if the CSR9-CSR10 link goes down, traffic is rerouted around this failure and stitched back together on CSR10. Use RSVP Hellos to detect the failure. Set the interval to 500 msec and 5 missed ACKs.

Answer

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

#CSR9
ip rsvp signalling hello
!
int Gi2.590
 mpls traffic-eng backup-path tun0
 ip rsvp signalling hello
 ip rsvp signalling hello refresh interval 500
 ip rsvp signalling hello refresh misses 5
!
ip explicit-path name AVOID_LINK_TO_CSR10
 exclude-address 132.9.10.10
!
int tunnel0
 tunnel mode mpls traffic-eng
 ip unn lo0
 tunnel dest 10.10.10.10
 tunnel mpls traffic-eng path-option 1 explicit name AVOID_LINK_TO_CSR10

#CSR10
ip rsvp signalling hello
!
int Gi2.590
 ip rsvp signalling hello
 ip rsvp signalling hello refresh interval 500
 ip rsvp signalling hello refresh misses 5

Explanation

MPLS-TE relies on fast failure detection. With Ethernet we are limited to the line going physically down, or using some sort of keepalive mechanism. Relying on line status is not reliable, because there could be multiple layer 1 devices in the path between two routers. So instead we must use RSVP Hellos, either with or without BFD.

In the previous lab we activated BFD, which is going to be a more common deployment, due to BFD being able to be offloaded into hardware. In this lab we explore using the RSVP Hello itself.

By default, RSVP does not use Hellos. When a path is setup, the neighbors are maintained using the PATH/RESV messages, not a separate RSVP Hello. To use RSVP Hellos, we must activate it at the global level and the link level:

#CSR9
ip rsvp signalling hello
!
int Gi2.590
 ip rsvp signalling hello

#CSR10
ip rsvp signalling hello
!
int Gi2.590
 ip rsvp signalling hello

RSVP Uses an activate/passive setup, in which one router is Active (sending requests), and the other end is Passive, simply acknowledging requests. Or both ends can be Activate. By default, when FRR is not configured on the interfaces of either neighbor, the Hello period is 2000 msec, and triggers failure when 4 ACKs are missed.

We can see this using the following show command:

When using RSVP Hellos without using FRR, there is “ReRoute” protection instead of “Fast ReRoute protection”. This allows the router to send a PathErr to the headend upon detecting the neighbor down. However, usually you can just rely on your IGP for this, so it would not be a typical use case for RSVP Hellos.

Once we add the backup tunnel to this interface, the default interval changes to 200 msec. Additionally, the client changes to “Fast ReRoute.”

#CSR9
int Gi2.590
 mpls traffic-eng backup-path tun0
!
ip explicit-path name AVOID_LINK_TO_CSR10
 exclude-address 132.9.10.10
!
int tunnel0
 tunnel mode mpls traffic-eng
 ip unn lo0
 tunnel dest 10.10.10.10
 tunnel mpls traffic-eng path-option 1 explicit name AVOID_LINK_TO_CSR10

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

Keep in mind that this is processd in the control plane, unlike BFD. To back off this interval a bit, we can change the interval and missed acks number via the following commands:

#CSR9
int gi2.590
 ip rsvp signalling hello refresh interval 500
 ip rsvp signalling hello refresh misses 5

We can also control the DSCP value if desired:

ip rsvp signalling hello dscp value (0-63)

Now when we shut down Gi2.590 on CSR10, we activate FRR on CSR9 within 2.5 seconds. This would be faster with BFD, but using RSVP hellos is the only other option if we cannot use BFD.

#CSR10
int gi2.590
 shut

Notice above that before we had an “Up” activce instance with CSR10. Then we had no active instances any more, and FRR had been activated.