Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Known Issues

This section lists the known issues in Juniper Routing Director.

Device Life-Cycle Management

  • When you import devices in bulk into Routing Director, any device that is part of a network implementation plan may cause the plan to be locked while the configuration from the plan is being committed. During this period, imports for other devices in the batch can fail with the error code, HTTP 423 Locked.

    You cannot import the devices that fail to import by adding them to a new batch because they have already been registered in the inventory as part of the original batch. In large batches, the network implementation plan locks may remain active for an extended period, as configuration commits must complete on all devices in the batch before the lock is released. As a result, device import failures can persist until all the device onboarding operations associated with the Network Implementation Plan have finished.

    Workaround:

    1. Wait until the network implementation plan is no longer locked. That is, Routing Director finishes onboarding the devices already in progress and the status of the device is Imported on the Device Batches page (Inventory > Devices > Device Batches > Created At column> Date and time link).

    2. Release the failed device from inventory:

      1. Navigate to Inventory > Devices > Network Inventory.

      2. Select the device.

      3. Click Release Router to remove it from inventory.

    3. Add the device to a new batch and start the import again.

  • The following unintended configurations, which are part of the paragon-service-orchestration group, are automatically pushed to ACX devices at the time of onboarding.

    Workaround: None.

  • Changing the router ID of a device after onboarding might create a duplicate node in the topology.

    Workaround: If you want to change the router ID, you must offboard the device, update the router ID in the configuration, and then onboard the device again.

Observability

  • The system rules are not automatically enabled for recommendation when you upgrade a Routing Director setup that has custom rules with the specific topic “custom”.

    Workaround: Use the Rules page (Observability > Health > Smart KPI Assistant > KPI Workspace > Rules) to manually enable the system rules for recommendation and set them to auto-deploy.

  • The approval status of a recommended KPI may remain unchanged even after the recommendation is removed.

    Workaround: Manually update the approval status to the appropriate value on the Recommendation Details page (Observability > Health > Smart KPI Assistant > KPI Recommendations > Detection column > click the link).

  • While creating or editing a device profile, if you have enabled ORE and Smart KPI Engine toggle buttons, then AI-ML-related rules are not instantiated.

    Workaround: None.

  • Under high load, the summarization of licensing information shown on the Features tab (Observability > Health > Troubleshoot Devices > Device-Name > Inventory) may be delayed. However, the licensing information will eventually be consistent with the network.

    Workaround: None.

  • While editing a rule (Observability > Health > Smart KPI Assistant > KPI Workspace > Rules > Edit option), if you modify any organization-level variable, then all other unmodified variables are reset to empty strings, overriding their default values.

    Workaround: While modifying organization-level variables, you must also set default values for all other variables to preserve their intended defaults.

  • When configuring Document Connector Configuration (Settings Menu > System Settings > Organization Settings page > Configure LLM Connector title > Documentation tab > + ), the base URL must not end with a trailing slash (/). URLs ending with / are currently not supported and may cause errors during connector operations.

    Workaround: Ensure the base URL is entered without a trailing slash. For example, use https://routing.ai.juniper.net instead of https://routing.ai.juniper.net/.

  • The MCP server's command blocklist only covers operational mode commands. Destructive configuration commands — such as delete, rollback factory, load factory-default, and their NETCONF equivalents — are not blocked and can be executed if triggered by a user prompt or LLM-generated action, potentially causing loss of critical device configuration.

    Workaround: We recommend that you avoid prompts that may trigger destructive configuration changes. Additionally, enable the MCP approval workflow to require manual confirmation before any configuration-changing commands are executed on devices.

  • When the http_url in the MCP configuration file (config.json) ends with a trailing slash (/) and when the Routing Director's MCP server functionality (junos_config_commit tool call) for pushing commits onto the Junos device is called, the MCP server incorrectly constructs the API URL with a double slash (//). This results in a 400 Bad Request error and fails to execute the tool call.

    Workaround: Ensure the http_url in the MCP server’s config.json does not include a trailing slash. Use http_url": "http://<ip-address>" instead of http_url": "http://<ip-address>/".

  • When using the LLM connector in Firefox, the response text appears garbled in streaming mode. The same response renders correctly from Conversation History.

    Workaround: We recommend that you use Chrome or Safari. Alternatively, open the Conversation History drawer and select the conversation thread to render correctly in Firefox.

  • The victoria‑metrics service in routingbotdb may crash because the required cache folder is not created under /vm-data during deployment. This causes the victoria‑metrics pods to restart after running for some time.

    Workaround: Run the paragon-vmstorage-cache-fix script to identify if the cache folder is missing, and also automatically create the missing cache folder.

  • When querying the MCP server, inconsistent argument naming for MAC address parameters across multiple tools (For example, mac, router_mac, device_mac) causes the AI model to hallucinate incorrect argument names.

    Workaround: If you are encountering this issue, you can retry the query or explicitly specify the correct argument name in the prompt to guide the MCP co-pilot toward the right parameter. You can refer to the MCP tool documentation for the exact expected parameter name, which can help avoid hallucination errors.

  • When restoring from a backup, if the restore fails with the following error message, then data for some devices may be lost in Devices and Adjacencies tabs of the Route Explorer page (Observability > Routing):

    Deployment Failed, Please check the log under /root/epic/config for more details.

    Workaround: None.

  • When using LLM Connector, you can change models within the chat window during an active conversation. However, selecting a different model does not actually switch the model. The LLM Connector continues to use the originally selected model, which can be confusing if you are expecting a live model change.

    Workaround: To use a different model, go to the LLM Connector Configuration page (Settings Menu > System Settings > Configure LLM Connector tile > Add (+) icon) and manually mark the required model as Active before starting a new conversation.

  • For devices running on Junos OS or Junos OS Evolved Release 22.3R1 or later, IS-IS interface statistics are streamed at the IS-IS level. This behavior can cause duplicate counter processing for the same interface, which may result in false interface‑level ISIS alerts.

    The following KPIs are impacted: CSNP drops, ESH drops, IIH drops, ISH drops, LSP drops, PSNP drops, and unknown drops.

    Workaround: None.

  • After upgrading Juniper Routing Director from release 2.7.0 to release 2.9.0, historical graph data for Traffic Loss (Observability > Health > Troubleshoot Devices > Device-Name > Overview > Routing and MPLS accordion > Traffic Loss Alert link) is not visible. While alerts are captured correctly, alerts do not appear on graphs for the pre‑upgrade period. This issue does not occur when upgrading from release 2.8.0 to release 2.9.0.

    Workaround: None.

  • The Junos syslog query using syslog-filter on the device intermittently does not return data as expected. This can result in delays beyond the normal pull frequency of 3 minutes when fetching syslog data from the device. Due to this, syslog data availability in the GUI may be delayed. Applications dependent on timely syslog ingestion, such as AIOps FPC reset prediction, may experience reduced accuracy or delayed insights.

    Workaround: None.

  • When you upload custom rules for Nokia 7250 IXR-x and Nokia 7250 IXR-e devices, the graph on the KPI tab (Observability > Health > Smart KPI Assistant > KPI Workspace > Rule Instances > Instance-Name > Monitor Instance-Name) displays no data for the check-ntp-synchronization-status rule.

    Workaround: None

  • For PTX10002-36CD, the graphs on the following pages do not display any data:

    • Pluggable details for Device-Name (Observability > Health > Troubleshoot Devices > Device-Name > Overview > Interfaces (accordion) > Pluggables)

    • Interfaces details for Device-Name (Observability > Health > Troubleshoot Devices > Device-Name > Overview > Interfaces (accordion) > Input/Output > Signal Functionality/FEC Uncorrect)

    Workaround: None.

  • When an adjacency fails or is established, Routing Observability detects these events and reports them on the Events page (Observability > Health > Events). However, the same adjacency event may be reported multiple times.

    Workaround: Treat these repeated events as a single event by correlating the self and neighbor ID combination.

  • When devices under monitoring fail catastrophically and are subsequently offboarded from Routing Directory, these stale devices may still show up in the Route Explorer's devices table (Observability > Routing > Devices tab).

    Workaround: Remove stale devices by manually deleting them from the Routing Director's internal database.

  • Alerts are not displayed on the Relevant Events section of all accordions on the Passive Assurance tab (Orchestration > Instances > Service Instances > Service-Instance-Name hyperlink).

    Workaround: You can view the alerts on the Events page (Observability > Event) or on the respective graphs.

  • Even with auto-refresh enabled, the alerts listed and the data shown in the graph on the IS-IS Routing Details for Device-Name page (Observability > Health > Troubleshoot Devices > Device-Name > Overview > Routing and MPLS > IS-IS > IS-IS Adjacency Flap) may not be synchronized.

    Workaround: Close and reopen the IS-IS Routing Details for Device-Name page to see the latest data.

  • When KPIs continuously oscillate between fixed values in a repeating pattern, the boundary initially adapts as expected, but after a few hours, it begins to readjust even though the oscillation pattern remains unchanged. This behavior can persist even after full adaptation, causing the boundary to continue oscillating unnecessarily.

    Workaround: None.

  • In setups with parallel links between two nodes, adjacency or link flaps are reported only on a complete loss or restoration of connectivity between the nodes, rather than on individual link transitions.

    Workaround: None

  • There is an unexpected delay in reporting an anomaly related to a sudden decrease in nodes. The anomaly is reflected only after the total delay period has passed.

    Workaround: You can use the REST API to view information related to this anomaly.

  • After a device is onboarded, Routing Director continuously monitors the KPIs related to device health. For each KPI, Routing Director monitors the KPI, forecasts the range, and detects any anomalies that occur. If a KPI value changes, the forecasted range takes approximately two hours to stabilize.

    Workaround: None.

  • While adding a device profile for a network implementation plan, if you enable Routing Protocol Analytics then the routing data is collected for the devices listed in the device profile. When you publish the network implementation plan, even though the onboarding workflow appears to be successful there might be errors related to the collection of routing data for these devices. Because of these errors, the devices will not be configured to send data to Routing Director and therefore the routing data will not be displayed on Route Explorer page of the Routing Director GUI. This issue occurs while offboarding devices as well, where the offboarded devices continue to send data to Routing Director.

    This issue also occurs when you have not configured ASN or Router ID on the devices, or when you have locked device configuration for exclusive editing.

    Workaround: To fix this issue:

    1. Do one of the following:

      • Check the service logs by running the request paragon debug logs namespace routingbot app routingbot service routingbot-apiserver Shell command. Take the necessary action based on the error messages that you see in Table 1.

        Table 1: Error Messages
        Error Messages Issue

        Failed to get device profile info for dev_id {dev_id}: {res.status_code} - {res.text}

        Failed to get device info for dev_id {dev['dev_id']}. Skipping device.

        		 The API call to PAPI to get the device information has failed.

        No results found in the response for dev_id {dev_id}

        Failed to get device info for dev_id {dev['dev_id']}. Skipping device.

        		 The API call to PAPI returns a response with no data.

        Complete device info not found in the response for dev_id {dev_id} : {device_info}

        		 The API call to PAPI returns a response with incomplete data.
        No data found for dev_id {dev_id} from PF The API call to Pathfinder to get the device information has failed.
        Required data not found for dev_id {dev_id} from PF data:{node_data}

        The API call to Pathfinder to get device information returns a response with incomplete data.
        EMS config failed with error, for config: {cfg_data} or EMS Config push error {res} {res.text} | try: {retries}. Failed to configure BMP on device {mac_id} BGP configuration has failed.

        Invalid format for major, minor, or release version : {os_version}

        		 The device's OS version is not supported.
        Error POST {self.config_server_path}/api/v2/config/device/{dev_id}/ {data} {res.json()} Playbook application has failed.
        Error PUT:{self.config_server_path}/api/v2/config/device/{dev_id}/ {data} {res_put.json()} Playbook removal has failed.
        Error PUT:{self.config_server_path}/api/v2/config/device/{dev_id}/ {data} {res_put.json()} Device or playbook application to device-group has failed.

        Error PUT {self.config_server_path}/api/v2/config/device-group/{site_id}/ {data} {res_put.json()}

        Device or playbook removal from device-group has failed.

      • Examine the device configuration to check whether the device shows unexpected absence or presence of the configuration. For example, you can,

        • View the configurations present under set groups paragon-routing-bgp-analytics routing-options bmp.

        • Check the device configuration in the JTIMON pod.

    2. After resolving the above issues, edit the device profile of the network implementation plan that you have applied for the device. Based on whether you are onboarding or offboarding devices, enable or disable the Routing Protocol Analytics option in the device profile.

    3. Publish the network implementation plan.

    4. Verify whether the required results are seen based on the data that is displayed on the Route Explorer page of the Routing Director GUI.

  • On the Interfaces accordion, FEC uncorrected errors charts are available only on interfaces that support speeds equal to or greater than 100-Gbps.

  • After you apply a new configuration for a device, the Active Configuration for Device-Name page (Observability> Troubleshoot Device > Device-Name > Configuration accordion > View active config link) does not display the latest configuration immediately. It takes several minutes for the latest changes to be reflected on the Active Configuration for Device-Name page.

    Workaround: You can verify whether the new configurations are applied to the device by logging in to the device using CLI.

  • Not all optics modules support all the optics-related KPIs. See Table 2 for more information.

    Workaround: None.

    Table 2: KPIs Supported for Optics Modules

    Module

    Rx Loss of Signal KPI

    Tx Loss of Signal KPI

    Laser Disabled KPI

    SFP optics

    No

    No

    No

    CFP optics

    Yes

    No

    No

    CFP_LH_ACO optics

    Yes

    No

    No

    QSFP optics

    Yes

    Yes

    Yes

    CXP optics

    Yes

    Yes

    No

    XFP optics

    No

    No

    No

  • For PTX100002 devices, the following issues are observed on the Interface accordion (Observability > Health > Troubleshoot Devices > Device-Name > Overview):

    • On the Pluggables Details for Device-Name page (Interfaces accordion > Pluggables data-link), the Optical Tx Power and Optical Rx Power graphs do not display any data.

    • On the Input Traffic Details for Device-Name page (Interfaces accordion > Input Traffic data-link), the Signal Functionality graph does not display any data.

Service Orchestration

  • In EVPN VPWS deployments, placement validation may fail for certain multihomed Customer Edge (CE) topologies when access links connected to the same physical CE device are configured with different CE reference names.

    Workaround: Configure a common CE reference name for all access links that terminate on the same physical CE device. Using a consistent CE reference name across these access links ensures that the service is validated and provisioned correctly.

  • The VLAN ID continues to appear in the VLAN drop-down list of the Edit Connection page (Orchestration > Service > Instances > Modify Service-Instance-Name > Customer Site Settings tab > Edit Site Network Access section) even though it has already been consumed by another site network access (SNA). This incorrect availability leads to an IRB placement error when the same VLAN ID is reused.

    Workaround: None.

  • When you configure an EVPN service instance, both mpls-evpn and pbb-evpn VPN service types are displayed as options. However, only mpls-evpn is supported on Routing Director GUI and is the default service type.

    Workaround: None.

  • On the Resource Instances page (Orchestration > Service > Resource Instances), the network-operator:topo resource is a system-managed resource. As a result, the Workflow Run ID column may be empty when the system generates the resources. The Workflow Run ID column is set only if you click the Update button.

    Workaround: None.

  • In rare high-load scenarios, provisioning of an EVPN instance may fail due to the unavailability of temporary back-end resources.

    Workaround: Try provisioning the service again.

Active Assurance

  • When a small number of Monitors are spread across many Test Agents (For example, 1,000 Monitors across 500 Test Agents), the Monitors page (Observability > Active Assurance) shows an error when fetching all Monitors. The API call fails as the requested string length exceeds the limit.

    Workaround: You can view all measurements for a specific device on the Measurement page (Inventory > Test Agents > Measurement), or you can apply a filter on the Monitors page to filter Monitors based on Test Agents.

  • Deleted Test Agents are not listed on the Test Agents tab of the Applications page (Observability > Health > Health Dashboard > Active Assurance (Tab) > View Details > Application page > Affected Items).

    Workaround: None.

  • The Test Agent application cannot be installed on devices running Junos OS Evolved Release 25.4R1 and Junos OS Evolved Release 25.4R2.

    Workaround: None.

  • Monitors do not enforce a limit on the number of measurements they can generate, and Routing Director does not restrict the number of monitors you can create. In large‑scale setups, starting or stopping a very high number of measurements (for example, 25,000) across multiple monitors at once can trigger a burst of operations. This leads to significant delays before operations are complete.

    Workaround: For better performance, avoid stopping or starting all monitors simultaneously. Instead, trigger operations sequentially in smaller batches. For example, start or stop a subset of monitors, wait until those measurements are running or stopped, and then proceed with the next batch.

  • When a Test Agent is soft deleted using the GUI, the deleted Test Agent is disconnected and moved to the Trashbin tab. If the soft-deleted Test Agent is later permanently deleted from the Trashbin tab, Routing Director cannot send the unregister command to the Test Agent. As a result, credentials remain visible on the Test Agents page even though they are no longer valid.

    Workaround: None.

  • When you download a report from the Monitor page, the report may not capture the Monitor-related data completely and may also display improper formatting.

    Workaround: None.

  • The Task Config section may sometimes not be rendered in the generated PDF when Monitor reports are generated repeatedly.

    Workaround: Refresh the page and retry generating a report.

  • When you download a report for a Monitor that has a large number of Tasks (approximately 100), the report contains incomplete data, and the Measurement Summary section in the report omits some tasks. The report does not render the ten most recent events or the event bar for each measurement.

    Workaround: None.

  • The results produced by the Test Agent are impacted if the Test Agent clock has a large offset. That is, if the local time is in the past or future. This means:

    • Timestamps for Metrics for any Stream produced by a Measurement running on that Test Agent are affected.

    • Event activation time and event deactivation time are affected.

    Therefore, it can result in the incorrect evaluation of Test Execution, as Metrics or Events are not included in the time range the system considers as the Test Execution run time. You may not be explicitly warned about this situation. However, the issue manifests with time shifted metrics or events.

    Workaround: Time synchronization is a requirement for Test Agents. Ensure Test Agent clock is synchronized.

  • When you run a QoS profiling test, the TCP throughput is affected by congestion control.

    QoS policy profiling reflects actual network behavior. So, TCP throughput observed during QoS profiling tests is influenced by TCP congestion control. Drop policers can lower measured TCP performance because packet loss triggers congestion responses and reduces the sending rate. If you see reduced throughput in profiling results, we recommend reviewing the policers in use and consider using a traffic shaper instead. Shapers queue excess packets rather than dropping them, allowing profiling tests to represent the network’s true capacity and performance more accurately.

  • If you reboot an ACX device that has a Test Agent installed, you might notice that Docker is removed and the Test Agent goes offline, affecting active assurance measurements.

    Workaround: Do the following:

    1. Log in to the router.

    2. Deactivate the paa test-agent service

      and commit the changes.

    3. Reactivate the paa test-agent service and commit the changes.

  • In some rare cases, only Test Agents that are in an offline state and due for a plug-in upgrade are upgraded. The plug-in upgrade may not happen for Test Agents that are online and due for a plug-in upgrade.

    Workaround: Changing the active version of one of the plug-ins in the system (not necessarily the same plug-in or in the same organization) will make any pending upgrades to be revisited, causing the upgrade to continue for any online Test Agent pending to be upgraded. You can do this in one of the following ways:

    • You can use the Plugin Inventory page (Inventory > Active Assurance) to change the Active version of a plug-in back and forth between two plug-in versions.

    • Or, alternatively, use the API to re-enable the same plug-in version.

      1. Copy the ID of the plug-in version from the Plugin Inventory page.

      2. Run the following request to re-enable the same plug-in:

  • The Metrics graph shows No Data for a Test that includes a Step with Measurements if:

    • The Test uses self-governed plugin.

    • If you click a Stream that produces Metrics while the Test is executing.

    This issue occurs if you set the same start time and end time.

    Workaround: Ensure that you manually set the Custom Time Range to something meaningful instead. Once the Test execution is complete, the Metrics are shown correctly.

  • When you restore a Routing Director instance, you might notice that some data such as Active Assurance Plugins and Packet Capture files may not be backed up. This is because backups are not done on any Kubernetes volumes.

    Workaround: We recommend that you download Packet capture files before you restore an instance and store them locally to analyze them. In case of Active Assurance Plug-ins, we recommend that you use the Plugin Inventory page (Inventory > Active Assurance) to upload the latest Plugin again on the new (restored) instance.

  • After you take a backup and restore a Routing Director instance, some Test Agents might incorrectly display status as Online.

    Workaround: After the system is fully restored, perform the following steps:

    1. Restart test-agent-gateway one additional time to refresh Test Agents.

    2. Execute the kubectl -n paa delete pod -l app=paa-test-agent-gateway command from the Linux root shell.

  • When you create a Monitor with 600 streams, you might encounter Monitor Creation Timeout error and the Monitor might automatically stop.

    Workaround: Restart the Monitor from the Monitor-Name page (Observability > Active Assurance > Monitors > Monitor-Name) and click More > Start) on the Routing Director GUI.

  • The status of a Test Agent is shown as offline after the device's Routing Engine switches over from the primary Routing Engine to the backup Routing Engine, or vice versa. This issue occurs only if you are using a Junos OS version that is older than 23.4R2.

    Workaround: Reinstall Test Agent after the Routing Engine switchover.

  • When you add a new host to the existing Monitor, the new measurements are not reflected in the Active Assurance tab of the Health Dashboard (Observability > Health).

    Workaround: None.

Network Optimization

  • In some scenarios, after you restart the RESTHandler service, the topology map may stop receiving live updates for link utilization labels and link state changes. The topology data itself remains current; however, updates may not be reflected on the map until the browser is refreshed.

    Workaround: Trigger a topology refresh event for the affected topology ID from a common-utils pod.

  • The Re‑parse option on the Advanced tab of the Topology Settings page (Observability > Network > Topology > Topology Menu Bar > Settings icon) is currently not functional. When invoked, previously-collected device configuration output is not re-parsed as expected.

    Workaround: Trigger a device collection on any one of the devices in the topology:

    1. Navigate to the Topology page (Observability > Network).

    2. Select a device from the Device tab.

    3. Click More > Run Device Collection.

    This re-parses the entire topology and reloads the topology with the collected configuration.

  • When you upgrade to Routing Director Release 2.9.0, the topology filter is unable to process dynamic topology-related information (BGP-LS).

    Workaround: Do the following:

    1. Delete the pf-organizationID namespace.

    2. Restart the ns-configmonitor pod to create pods under pf-organizationID.

  • If you use previously-deleted tunnel names, creation of NETCONF RSVP tunnels sometimes fails on Cisco devices

    Workaround: Perform the Sync operation (Observability > Network > Topology > Topology Menu Bar > Settings icon > Advanced tab) to clear the cache.

  • For links with dual IPv4 or IPv6 interfaces, only the IPv4 address is used as the target ping address when measuring packet loss. For links with IPv6‑only interfaces, no packet loss measurements are created.

    Workaround: None.

  • When a tunnel has no current path, the topology map on the Topology page (Observability > Topology) may still display a highlighted path using the tunnel's required path data. As a result, you may notice a discrepancy between the map visualization and the Current Path column in the Tunnels table.

    Workaround: None.

  • Enabling Active Assurance in the network implementation plan is a prerequisite for collecting packet loss for a device. You cannot enable or disable Active Assurance while modifying a network implementation plan. So, if you have disabled Active Assurance in the network implementation plan and later want to enable it, you need to do one of the following:

    • Offboard and onboard devices, or

    • Create Test Agent for the devices manually.

  • SID Compression does not work as expected after you undelegate an SR LSP.

    Workaround: None.

  • In rare cases, connection errors may appear on the Test Agent's Measurement Explorer page (Observability > Active Assurance > Measurement Explorer), and the Test Agent cannot connect to the target device for collecting the loss statistic. As a result, the loss statistics on the Topology page (Observability > Topology) are potentially out of date.

    Workaround: None. After the Test Agent reconnects to the target device, the packet loss statistics are automatically updated.

  • When you remove the LSP delegation, the routing method is automatically changed from default to routeByDevice.

    Workaround: You must manually update the LSP routing method to the desired option.

  • For bandwidth-sizing-enabled SR LSPs, the bandwidth resizing that is based on aggregate traffic through the LSP might not always happen as per the configured thresholds.

    There could be instances when an SR LSP’s bandwidth gets changed, despite the aggregate LSP traffic value not exceeding the current bandwidth by the adjustment threshold percentage. There could also be instances when the LSP’s bandwidth does not get resized, though the computed aggregate traffic differs from the current bandwidth by the configured threshold.

    This occurs due to incorrect comparison during bandwidth sizing of LSP traffic in accordance with the LSP bandwidth that is set while creating or modifying the LSP using Routing Director GUI or REST API.

  • Incorrect RSVP link utilization can occur in the following scenarios:

    • Due to an LSP constraint, Routing Director reroutes a lower-traffic LSP instead of a higher-traffic LSP during Threshold Crossing Rerouting.

    • In the next path optimization, Routing Director removes the higher-traffic LSP’s current path, including its bandwidth accounting along the path, which results in incorrect RSVP link utilization.

  • Junos OS Release 22.4R1 and later have a limitation with SR-TE LSPs. For PCEP sessions to be established, you must disable the multipath feature using the following command:

    set protocols pcep disable-multipath-capability

    Secondary path is not supported.

  • The status of SR-TE LSPs might be displayed as down after delegating or provisioning. There might be errors (RPD_SPRING_TE_ROUTE_LSP_MISMATCH) in RPD logs if there are parallel SR-TE LSPs (same source or destination nodes) using both node and adjacency SIDs.

    Workaround: All parallel SR-TE LSPs should use either node or adjacency SIDs.

  • If you try to create an LSP using the REST API and if you are reusing an existing LSP name, then the REST API server does not return an error.

    Workaround: None.

  • After you perform a backup or restore operation, the traffic is displayed as 0 percent on the Topology page.

    Workaround: After the backup or restore operation, either restart the pf-telemetry pod or trigger a device collection., and also restart the pcs pod in pf- namespace.

  • Routing Director does not automatically reroute LSPs away from a device with the IS‑IS overload bit set. However, during optimization, LSPs with the routing method set to IS‑IS will be rerouted away from the impacted device.

    Workaround: Manually enable the Faulty setting on all links connected to the device with the overload bit. Later, you should clear the Faulty property of those links once the overload bit has been cleared.

  • If there are multiple ECMP diverse paths and if you have enabled periodic re-optimization, then the diverse LSPs might switch back and forth between two routing paths.

    Workaround: If you do not prefer this behavior, set the Path Type as Preferred on the Modify LSP page.

  • Sometimes, an LSP provisioning might not be successful, and you might see the PCC_Pending error displayed on the tunnels table of the Topology (Observability > Topology) page.

    Workaround: Restart the PCEP session on head-end routers by deactivating and activating the protocols and PCE-related statements in the Junos OS configuration.

  • In broadcast links exist in the network, Segment Routing (SR) LSPs may not be created.

    Workaround: Change broadcast links to point-to-point links in the router configuration.

Network Planner

  • The backup and restore operations executed at the time of installation or upgrade do not include support for the Planner use case. As a result, planner‑related data and configurations are not preserved during backup or restored afterward.

    Workaround: None.

  • Currently, site-level diversity provides only device or node diversity in the paths of pairs of LSPs belonging to the same diversity group. The site information associated with each device is not taken into consideration. As a result, each device is treated as an independent site, which may lead to paths that do not achieve true site‑level diversity.

    Workaround: None.

  • In certain network topologies, Planner may compute an incorrect Explicit Route Object (ERO) for a demand after performing the Update Model and Path operation, causing the demand to be routed along a suboptimal path instead of the expected shortest path.

    Workaround: None.

  • While performing the Update Model and Paths operation, if you select None or Only unplaced, Planner fails to invalidate a tunnel’s computed path if Segment Routing (SR) is disabled on a link it traverses. Instead of marking the route as invalid, Planner incorrectly retains the old path.

    Workaround: None.

  • When you run an exhaustive failure simulation, the Tunnel‑on‑Links report (L2_DVSIM.r0) and the Link Utilization report (DVSIM.r0) incorrectly computes the PeakCnt value for directional link entries. The reports may attribute a non‑zero PeakCnt to a link direction that the rerouted tunnel ERO does not actually traverse.

    Workaround: None.

  • When you run an exhaustive failure simulation, the Traffic on Physical Links report (L2_PHYDVSIM.r0) incorrectly includes pseudo-node link failures.

    Workaround: Remove the pseudo-node link from the topology and rerun the exhaustive failure simulation to get the correct report.

  • When you run an exhaustive failure simulation, the Link Utilization report (DVSIM.r0) computes incorrect values for PeakBw_A and PeakUtilPct_A on links traversed by rerouted demands. The calculation error leads to inaccurate reporting of link bandwidth and utilization metrics.

    Workaround: None.

  • In exhaustive failure simulation, demands that fail to reroute are not reported in the Failed Path report (PeakSimRoute.r0). This occurs because Planner incorrectly routes the demand over a pseudo-node link instead of a valid physical link, causing the failed demand to be omitted from the report.

    Workaround: Remove the pseudo-node link from the topology and rerun the exhaustive failure simulation to get the correct Failed Path report.

  • During exhaustive failure simulation at the tunnel layer, the Traffic on Physical Links report incorrectly counts tunnels traversing a link in opposite directions as multiple tunnels. Specifically, when two tunnels use the same physical link but in different directions (for example, A to B and B to A), the planner reports the value for Tunnel and PeakCnt as 2 instead of 1. This happens because tunnels from both directions are being treated independently instead of being counted together.

    Workaround: None.

  • When the tunnel path traverses ECMP paths, Planner does not route demands generated from SR tunnels configured with Route by Device as the routing method. Affected demands remain unrouted.

    Workaround: None.

  • After you backup and restore a Routing Director cluster, the previously-generated reports for What-if or Exhaustive failure simulations are not retained.

    Workaround: You cannot restore reports generated before the backup operation. Rerun the simulation workflows to recreate the necessary reports after restoring the cluster.

  • Failed path report in demand layer simulation includes information on tunnels as well.

    Workaround: None.

  • If you modify the interface address and bandwidth from the Interfaces tab of the offline Topology page (Planning > Networks > Offline-Model > Open), then the changes are not reflected on the Links tab of the offline Topology page (Planning > Networks > Offline-Model > Open).

    Workaround: None.

  • During path computation in Planner, links marked as down are still considered. Consequently, the computed path may include a down link.

    Workaround: Before you run the simulation, delete the link that is marked as down. You can recreate the link later.

  • On the Offline Topology page (Planning > Networks > Offline Models > Model-Name > Open), deleting a device does not automatically delete its associated links.

    Workaround: Manually delete links attached to the node before you delete a node.

  • A tunnel and demand should not have the same name. Otherwise, the status of the tunnel and demand might be displayed as down.

  • In an offline model, only a primary LSP can be created. You cannot create a secondary LSP or a standby LSP in an existing offline model. You can, however, view the secondary or standby LSP-related details when you import a live network.

    Workaround: None.

Trust

There are no known issues in this release.

Administration

  • If a superuser triggers a password reset and you have enabled two-factor authentication, then you will be prompted to change your password. However, when you click the change password option, you may encounter the following error:

    Request failed with status code 401

    Workaround: The superuser must remove you from the organization and then add you back. After you log in using the password provided by your administrator, you can re-enable two-factor authentication.

  • When you assign a new site to a device, although you receive a confirmation message about the site change, the change may not be reflected on the Inventory page (Inventory > Devices > Network Inventory) or the Troubleshoot Devices page (Observability > Health).

    Workaround: Retry the site assignment to ensure the change is reflected.

  • You cannot use a Transport Layer Security (TLS) certificate to onboard Nokia devices.

    Workaround: None.

Installation and Upgrade

  • The gnmi-term pod may exhibit a gradual increase in memory usage over time. This behavior is most noticeable in environments where a large number of devices repeatedly fail session creation, typically because the devices have not been onboarded in PAPI. Continuous session creation failures can lead to sustained memory growth in the pod.

    Workaround: The gnmi-term pod may exhibit a gradual increase in memory usage over time. This behavior is most noticeable in environments where a large number of devices repeatedly fail to connect due to misconfiguration or device deletion. Such continuous events can lead to sustained memory growth in the pod over a period of time.

  • Under high system load, the following stream processes may exhibit sustained 100% CPU utilization:

    • alarm-event

    • device-profiles

    • papi-events

    • papi-mon-v2

    • papi-switch-stats

    This behavior occurs when a stream process becomes stuck in a processing loop. No known functional impact has been observed. However, affected processes may consume excessive CPU resources.

    Workaround: Restart the stream processes.

  • After you install or upgrade Routing Director, the status of OpenSearch may be shown as yellow (amber) or red.

    Workaround: Do the following:

    1. Check the latest status of OpenSearch by running the paragon-utils curl http://opensearch-cluster-master.common:9200/_cat/health?v command.

      If the status is green and active_shards_percent is 100%, then OpenSearch is fully functional or has recovered. If not, perform the remaining steps.

    2. Check OpenSearch sharding assignment by running the paragon-utils curl http://opensearch-cluster- master.common:9200/_cat/shards?v command.

      If one or more shards are stuck in the Unassigned state, or are not in the running state, proceed to the next step.

    3. Restart OpenSearch by running the kubectl scale sts -n common opensearch-cluster-master --replicas 0; sleep 120; kubectl scale sts -n common opensearch-cluster-master --replicas 3 command.

      Note:

      This might take several minutes. As the restart is done by stopping all OpenSearch instances at the same time, some pods that need OpenSearch may crash for a while.

    4. Verify OpenSearch status again by using the paragon-utils curl http://opensearch-cluster-master.common:9200/_cat/health?v command.

      At this time, OpenSearch status should be green and active_shards_percent must be 100%.

  • Telemetry backup does not include information about airflow workflows. As a result, when running the following command, you may encounter an error:

    Workaround: We recommend skipping this command when restoring telemetry backups, as the error can be safely ignored.

  • If you have taken a backup of a Juniper Routing Director instance that includes the Active Assurance Victoria Metrics database (used for storing time-series data) and if you are restoring the instance, the GUI will fail to show the restored data. You might see a set of errors in the logs of the metrics-service in the paa Kubernetes namespace.

    Workaround: Restart paa-metrics using the kubectl rollout restart deployment paa-metrics -n paa command

  • When the cluster experiences a high load, some components, especially the Victoria Metrics Operator and ArangoDB Operator pods, may be restarted. This will not impact the cluster’s functionality.

    Workaround: None.