Description

This issue arises due to a compatibility problem between newer Junos releases (starting from version 22.4) and older releases running on the Paragon controller. The problem occurs when an LSP (Label Switched Path) is created from the controller via NETCONF, making it impossible to subsequently modify the LSP via PCEP from the controller. This issue is due to pathnames no longer being reported via PCEP for SR-MPLS and SRv6 LSPs starting from Junos 22.4.

Symptoms

When attempting to modify an LSP via PCEP from the controller, the following errors and logs are encountered:

  • PCE Server Error:

{"@timestamp":"2023-06-26T14:13:03.356661+00:00", "host":"ns-pceserver-5cc7dc684b-6fzhl", "level":"err", "facility":"local6", "syslog-tag":"pce_server:", "source":"pce_server", "msg":" LSP pcc_control_sr_1687788675\/pcc_control_sr_1687788675 is not provisioned in pcc 172.16.18.103"}
  • Router Logs:

On the router for the LSP, we see the Routing-status as “locally routed” which means PCE is not sending the node with the ERO.

Control-status: Externally controlled  <-- indicates that LSP is deligated
Routing-status: Locally routed  <-- Indicate that path computation is done locally 

Extensive output of LSP:

Name: test2-r1-r2
Tunnel-source: Static configuration
Tunnel Forward Type: SRMPLS
To: 192.0.2.1
State: Up
Telemetry statistics:
Sensor-name: 192.0.2.1-30d40, Id: 3758096393
Path: test2-r1-r2
Path Status: Up
Outgoing interface: NA
Delegation info:
Control-status: Externally controlled
Routing-status: Locally routed
Auto-translate status: Enabled Auto-translate result: Success
Compute Status: Disabled, Compute Result: N/A, Compute-Profile Name: N/A
FD status: N/A, BFD name: N/A
BFD remote-discriminator: N/A
Segment ID: 128
<..>

From the PCEP output and traceoptions, the router is not receiving any ERO from the PCEP server. Also, an attempt to reprovision the LSP fails. This is due to the compatibility issue between Junos running version 22.4 or higher and the older release of Paragon.

show path-computation-client lsp extensive

LSP Name                 : test2-r1-r2
PathName                 : -
From                     : 192.0.2.1
To                       : 192.0.2.1
Path Setup Type          : spring-te
State                    : Up    
Active Path              : Yes
Link Protection          : none
LSP Type                 : ext-cntled
P2mp tree                : NULL
Path cspf status         : external_cspf
Controller               : PCE-CONTROLLER
Template                 : NULL
PLSP-ID                  : 8
LSP-ID                   : 0
RSVP Error               : 0x0
Requested AutoBw         : 0bps
Record Route             : 0.0.0.0->192.0.2.2(Label=127) 0.0.0.0->192.0.2.3(Label=228) 0.0.0.0->192.0.2.4(Label=182571)
From PCE ERO (received)  : NULL <-- No ERO received from PCEP server
From RPD ERO (reported)  : 0.0.0.0->192.0.2.2(Label=127) 0.0.0.0->192.0.2.3(Label=228) 0.0.0.0->192.0.2.4(Label=182571)
Configured ERO on PCC    : Not Supported
<...>
Last Rpt/Pcreqest received from RPD at       : 16:33:53.000
Last Update sent to PCE at                   : 01:00:00.000
Last PcUpdate/PcCreate received from PCE at  : 01:00:00.000
Last error sent to PCE at                    : 01:00:00.000
Last 5 reasons to send Report/Pcrequest      : , , , ,

Solution

The root cause of this issue is Due to Multi-segment support for SR-TE Path the pathnames are no longer being reported via PCEP for SR-MPLS and SRv6 LSPs starting from Junos 22.4. As a result, if the LSP is created from the controller via NETCONF, the user will not be able to subsequently modify the LSP via PCEP from the controller. This is because the LSP is created with the pathname in the controller, and the subsequent order to modify the LSP will have a pathname. However, since PCC doesn’t report the pathname, the PCE server will reject the order and complain the LSP is not provisioned on PCC.

Workaround:

To mitigate this issue, you can create a delegated LSP from PCC.

Permanent Fix:

The fix for this issue is included in Paragon version 23.1-SP1 and forward. Ensure both the Junos and Paragon versions are updated to the latest compatible releases to prevent this issue from occurring.

Modification History

2024-07-03 : Article Created