The Fast Reroute Extensions to RSVP-TE for LSP Tunnels describes two different types of traffic protection for RSVP-signaled LSPs:
One-to-one backup—In this method, detour LSPs for each protected LSP is created at each potential point of local repair.
Facility backup—In this method, a bypass tunnel is created to protect a set of LSPs that have similar backup constraints at a potential failure point by taking advantage of the MPLS label stacking.
In FRR, each label switch router (LSR) tries to establish the detour/bypass LSP except egress LSR for local repair of LSP tunnels. These mechanisms enable immediate re-direction of traffic onto detour/bypass LSP tunnels in the event of a failure. This article explains how to verify whether the detours are enabled or not.
Note: In Junos OS, to configure one-to-one FRR, you use fast-reroute and for facility backup, you use node-link-protection .
fast-reroute
node-link-protection
In the following diagram, an LSP with FRR one-to-one is configured on router R1 toward router R4. The path for the LSP is via R1 > R2 > R3 > R4. Each LSR—R1, R2 and R3—will establish a detour LSP to protect this LSP.
[edit protocols mpls] @R1_re# show label-switched-path To-R4 { to 192.168.4.4; fast-reroute; primary Primary; } path Primary { 192.168.4.4 loose; }
The FRR detour/backup LSPs are part of the main LSP. The tunnel-id for the main LSP and detour LSPs are the same as 13069.
@R1_re> show rsvp session ingress name To-R4 detail Ingress RSVP: 1 sessions 192.168.4.4 From: 192.168.1.1, LSPstate: Up, ActiveRoute: 0 LSPname: To-R4, LSPpath: Primary LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 300080 Resv style: 1 FF, Label in: -, Label out: 300080 Time left: -, Since: Sat Jul 10 04:02:06 2021 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 6 receiver 13069 protocol 0 FastReroute desired PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 10.8.11.2 (ge-0/0/2.0) 3 pkts RESV rcvfrom: 10.8.11.2 (ge-0/0/2.0) 5 pkts, Entropy label: Yes Explct route: 10.8.11.2 10.8.23.2 10.8.32.2 Record route: <self> 10.8.11.2 10.8.23.2 10.8.32.2 Detour is Up Detour Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Detour adspec: sent MTU 1500 Path MTU: received 1500 Detour PATH sentto: 10.8.10.2 (ge-0/0/1.0) 2 pkts Detour RESV rcvfrom: 10.8.10.2 (ge-0/0/1.0) 2 pkts, Entropy label: Yes Detour Explct route: 10.8.10.2 10.8.52.2 10.8.31.1 10.8.32.2 Detour Record route: <self> 10.8.10.2 10.8.52.2 10.8.31.1 10.8.32.2 Detour Label out: 300064 Total 1 displayed, Up 1, Down 0
From the captured RSVP path message on the links between R1<—>R5, R1 wants to avoid the node 192.168.2.2 (R2) to establish the node protection detour LSP.
From the captured RSVP path message on the links between R2<—>R6, R2 wants to avoid the node 193.168.3.3 (R3) to establish the node protection detour LSP.
To verify the detour LSP status on ingress LSR (R1), use:
@R1_re> show mpls lsp name To-R4 extensive Ingress LSP: 1 sessions 192.168.4.4 From: 192.168.1.1, State: Up, ActiveRoute: 0, LSPname: To-R4 ActivePath: Primary (primary) FastReroute desired LSPtype: Static Configured, Penultimate hop popping LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 LSP Self-ping Status : Enabled *Primary Primary State: Up Priorities: 7 0 SmartOptimizeTimer: 180 Flap Count: 1 MBB Count: 0 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3) 10.8.11.2 S 10.8.23.2 S 10.8.32.2 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 10.8.11.2(flag=9 Label=299904) 10.8.23.2(flag=1 Label=299936) 10.8.32.2(Label=3) 30 Jun 25 01:01:29.804 Record Route: 10.8.11.2(flag=9 Label=299904) 10.8.23.2(flag=1 Label=299936) 10.8.32.2(Label=3) 29 Jun 25 01:00:58.950 Self-ping ended successfully 28 Jun 25 01:00:58.009 Fast-reroute Detour Up 27 Jun 25 01:00:58.009 Self-ping started 26 Jun 25 01:00:58.009 Self-ping enqueued 25 Jun 25 01:00:57.593 Record Route: 10.8.11.2(flag=9 Label=299904) 10.8.23.2(Label=299936) 10.8.32.2(Label=3) 24 Jun 25 01:00:12.854 Self-ping ended successfully 23 Jun 25 01:00:12.170 Selected as active path 22 Jun 25 01:00:12.169 Record Route: 10.8.11.2(Label=299904) 10.8.23.2(Label=299936) 10.8.32.2(Label=3) 21 Jun 25 01:00:12.169 Up 20 Jun 25 01:00:12.169 Self-ping started 19 Jun 25 01:00:12.169 Self-ping enqueued 18 Jun 25 01:00:12.098 Originate Call 17 Jun 25 01:00:12.098 CSPF: computation result accepted 10.8.11.2 10.8.23.2 10.8.32.2
The Record Route Object (RRO) has a series of hops, each with an address followed by a flag. The flags identify the protection capability and status of the downstream node:
0x01—Local protection available. The link downstream from this node is protected by a local repair mechanism. 0x02—Local protection in use. A local repair mechanism is in use to maintain this tunnel. 0x03—Combination of 0x01 and 0x02. 0x04—Bandwidth protection. The downstream routing device has a backup path providing the same bandwidth guarantee as the protected LSP for the protected section. 0x08—Node protection. The downstream routing device has a backup path providing protection against link and node failure on the corresponding path section. 0x09—Detour is established. Combination of 0x01 and 0x08. 0x10—Preemption pending. The preempting node sets this flag if a pending preemption is in progress for the traffic engine LSP. This flag indicates to the ingress legacy edge router (LER) of this LSP that it should be rerouted. 0x20—Node ID. Indicates that the address specified in the RRO’s IPv4 or IPv6 sub-object is a node ID address, which refers to the router address or router ID. Nodes must use the same address consistently.
From the above output on R1, the router R2—10.8.11.2—includes the flag=09 in its RRO within the Resv message. This informs the ingress router (R1) that a successful detour has been established that protects both the downstream node and link.
And the router R3—10.8.23.2—includes the flag=01 in its RRO to indicate that a detour has been established only to protect the next downstream link. The egress router (R4) is the next downstream node to R3, so it is not possible to avoid the egress router and only the downstream link is protected.