Support Support Downloads Knowledge Base Juniper Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[M/MX/PTX/T] How to verify link and node protection FRR LSP status

0

0

Article ID: KB37261 KB Last Updated: 23 Aug 2021Version: 1.0
Summary:

The Fast Reroute Extensions to RSVP-TE for LSP Tunnels describes two different types of traffic protection for RSVP-signaled LSPs: 

  1. One-to-one backup—In this method, detour LSPs for each protected LSP is created at each potential point of local repair.

  2. 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.

Solution:

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. 

Related Links

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search