In the RSVP-TE environment when IGP overload is configured on the transit router, use of suboptimal path for the LSP are observed when LSP continues across the transit router even though the transit router has been marked as overload.

When IGP 'overload' is configured on the transit router, it triggers a re-optimization to find an alternate path. If the Patherr is received for the re-optimized path, the path is scheduled for CSPF with an exponential backoff. (The backoff time is determined by the RSVP error hold time and an exponentially increasing value). At this point if the CSPF computation is triggered before the backoff timer, leading to no CSPF (re-optimization) happening for the LSP, resulting in LSP continuing across the overload path (across the transit router).

Sample logs:
<timestamp> CSPF: Reroute due to re-optimization--> CSPF computed due to backoff timer expiry at 27 seconds, backoff now set to be 29 seconds
<timestamp> <y.y.y.y> Requested bandwidth unavailable: re-optimized path --> Patherr received which triggers backoff with 27 seconds
<timestamp> Originate make-before-break call
<timestamp> CSPF: computation result accepted  <x.x.x.x> <y.y.y.y> <z.z.z.z> 
<timestamp> CSPF: Reroute due to re-optimization  ---> Reoptimisation triggered due to overload
<timestamp> Make-before-break: Cleaned up old instance: Adaptive teardown
<timestamp> Make-before-break: Switched to new instance

This is a software defect and has been addressed from 23.2R2 onwards.

Please refer the following PR for the further details:

Juniper Networks - Problem Report Search

External-TriggerThis issue might be seen if the following conditions are met:
* On Junos and Junos Evolved platforms
* RSVP-TE is configured
* Configure IGP overload on the transit routers
* Patherr is received for the re-optimized path and CSPF computation is triggered before the backoff timer