FRR Link Protection (XE, RSVP Hellos)
Load mpls.te.frr.init.cfg
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
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:
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.”
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:
We can also control the DSCP value if desired:
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.
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.
Last updated
