Support Support Downloads Knowledge Base Case Manager My Juniper 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

[MX] RSVP LSP does not re-optimize to IGP shortest path due to CSPF failure

0

0

Article ID: KB35449 KB Last Updated: 28 Feb 2020Version: 1.0
Summary:

This article discusses one of the scenarios where RSVP LSP fail to re-optimize to IGP shortest path when there is a network change and the following message is seen:

CSPF: computation result ignored, new path less avail bw

Symptoms:

Topology:




The above topology has two LSPs created. One LSP To-R5 is from R1 to R5 using strict path as R2->R3->R4->R5 and reserved bandwidth of 900mbps. Another LSP To-R4 is from R2 to R4, which does not contain any path explicitly configured. It has two paths to R4 (i.e one directly connected to R4 and another via R3) . The To-R4 LSP chooses the directly connected path to R4 since IGP chooses the best path as the cost is 1.
lab@R2# run show route 4.4.4.4 

inet.0: 14 destinations, 15 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

4.4.4.4/32         *[OSPF/10] 00:00:10, metric 1
                    > to 10.1.24.4 via ge-0/0/1.0

If for some reason, a change is needed in OSPF metric so that the LSP from R2 to R4 re-routed via R3->R4. If we change the OSPF metric on directly connected interface to R4 ge-0/0/1 to 5, our OSPF will choose ge-0/0/2 as the best path whereas RSVP would still choose the old path and the error message is seen from 'show mpls lsp extensive' output:
lab@R2#set protocols ospf area 0 interface ge-0/0/1.0 metric 5 

lab@R2# run show route 4.4.4.4 

inet.0: 14 destinations, 15 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

4.4.4.4/32         *[OSPF/10] 00:00:06, metric 2
                    > to 10.1.23.3 via ge-0/0/2.0 <-- IGP chose the lesser metric path

inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

4.4.4.4/32         *[RSVP/7/1] 00:00:01, metric 2
                    > to 10.1.24.4 via ge-0/0/1.0, label-switched-path to-R4 <-- RSVP did not choose the same path as IGP.

lab@R2# run show mpls lsp extensive                                
Ingress LSP: 1 sessions

4.4.4.4
  From: 2.2.2.2, State: Up, ActiveRoute: 0, LSPname: to-R4
  ActivePath:  (primary)
  LSPtype: Static Configured, Penultimate hop popping
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary                    State: Up
    Priorities: 7 0
    OptimizeTimer: 2
    SmartOptimizeTimer: 180
    Reoptimization in 0 second(s).
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 5)
 10.1.24.4 S 
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          10.1.24.4
    8 Jan 26 21:34:43.683 CSPF: computation result ignored, new path less avail bw 
    7 Jan 26 21:33:50.507 CSPF: computation result ignored, new path no benefit[3 times]
Cause:
Since the existing LSP from R1 to R5 has a reserved BW of 900mbps, which has a strict path R2->R3->R4->R5. While RSVP tries to re-optimize to choose the path as IGP, it identifies the available BW on the newer path is lesser than the old path
lab@R2# run show rsvp interface 
RSVP interface: 3 active
                  Active Subscr- Static      Available   Reserved    Highwater
Interface   State resv   iption  BW          BW          BW          mark
ge-0/0/0.0  Up         1   100%  1000Mbps    1000Mbps    0bps        0bps       
ge-0/0/1.0  Up         1   100%  1000Mbps    1000Mbps    0bps        0bps       
ge-0/0/2.0  Up         1   100%  1000Mbps    100Mbps     900Mbps     900Mbps  <-- Available BW is 100Mbps

This is the expected behavior as per the topology and the configuration.

By default, traffic engineering support is disabled in OSPF. To enable, below configuration need to be done to populate the traffic engineering database. The traffic engineering database is used exclusively for calculating explicit paths for the placement of LSPs across the physical topology. The Constrained Shortest Path First (CSPF) algorithm uses the traffic engineering database to compute the paths that MPLS LSPs take. RSVP uses this path information to set up LSPs and to reserve bandwidth for them.

#set protocols ospf traffic-engineering

To learn more, refer to the technical documentation on Examples: Configuring OSPF Traffic Engineering

For more on the criteria for re-optimization results to be accepted, refer to Optimizing Signaled LSPs
Solution:
After clearing the LSP, it will take the same path as IGP best path to form the LSP.
lab@R2# run clear mpls lsp 

lab@R2# run show mpls lsp extensive 
Ingress LSP: 1 sessions

4.4.4.4
  From: 2.2.2.2, State: Up, ActiveRoute: 0, LSPname: to-R4
  ActivePath:  (primary)
  LSPtype: Static Configured, Penultimate hop popping
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary                    State: Up
    Priorities: 7 0
    OptimizeTimer: 2
    SmartOptimizeTimer: 180
    Reoptimization in 0 second(s).
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 2)
 10.1.23.3 S 10.1.34.4 S 
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          10.1.23.3 10.1.34.4
   16 Jan 26 21:37:17.640 CSPF: computation result ignored, new path no benefit
   15 Jan 26 21:37:15.737 Selected as active path
   14 Jan 26 21:37:15.724 Record Route:  10.1.23.3 10.1.34.4
   13 Jan 26 21:37:15.724 Up
   12 Jan 26 21:37:15.660 Originate Call
   11 Jan 26 21:37:15.660 CSPF: computation result accepted  10.1.23.3 10.1.34.4
   10 Jan 26 21:37:15.660 Clear Call    
    9 Jan 26 21:37:15.659 Deselected as active
    8 Jan 26 21:34:43.683 CSPF: computation result ignored, new path less avail bw
    7 Jan 26 21:33:50.507 CSPF: computation result ignored, new path no benefit[3 times]
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