Known Issues

This section lists the known issues in Juniper Routing Director.

Device Life-Cycle Management

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

In certain scenarios, link-down anomalies may be detected during real-time anomaly detection but may not be displayed in the GUI if they were not identified during the scheduled periodic detection cycle. This behavior is consistent with the current Day 1 design.

Workaround: None.
Acknowledging an alarm on the Alarms tab (Observability > Health > Events) does not currently update the Urgent Action Needed count on the Troubleshoot Devices page (Observability > Health) and the Put Devices into Service page (Inventory > Device Onboarding > Onboarding Dashboard). In addition, the acknowledgment status might not be consistently reflected between the Alerts and Alarms views.‌

Workaround: None.
After upgrading release 2.8.0 to release 2.10.0, if a device replacement is performed and the new device has a different hostname than the device it replaces, some entries in Route Explorer tables may continue to reference the old device hostname. This occurs because the replacement workflow assumes that the new device retains the same hostname as the original device.

Workaround: Offboard the replacement device and then onboard it again to refresh device references.
When a device is replaced, the routing observability configuration may not be removed from the original device because the device is no longer reachable.

Workaround: Remove the configuration manually by running the following commands on the old device:
When there are no devices enabled for BGP collection, navigating to Route Explorer > Devices might show an error on the GUI. There is no impact when devices with BGP collection enabled have been onboarded.

Workaround: None.
When a BGP peer is down, the adjacencies table will show the BGP peer’s local_as value as 0. The correct value is automatically restored when the peer comes back online.

Workaround: None.
After you upgrade from release 2.8.0 to release 2.10.0, the Route Topology page may take up to 30 minutes to load. This delay is caused by changes introduced in the VMDB endpoints, which require additional processing and data population before route topology information becomes available.

Workaround: Allow sufficient time for the initial topology data processing to complete after the upgrade. Subsequent page loads should occur normally once the data has been populated.
If you try to upload a custom rule that already exists, the upload fails with the following error message, indicating a JSON parsing issue:
Workaround: None.
When reopening a previously-saved conversation that used an Anthropic (Claude) model, tool call parameters may display an unexpected prefix, {}. For example, parameters may appear as:
This issue occurs only when viewing historical conversations.

Workaround: None.
The alerts generated for MX10004, MX304, and MX10008 devices are not listed on the Input Traffic Interface Health alerts page (Observability > Health > Troubleshoot Devices > Device-Name > Overview > Interfaces (accordion) > Input Traffic) and the Events page (Observability > Health > Events). This is caused by an underlying Junos OS issue and is not a limitation of Routing Director.

Workaround: None.
In a scaled setup, you may experience a noticeable delay when accessing the Route Topology page (Observability > Route Topology). The Route Topology page can take approximately 22 seconds to load each time it is opened.

Workaround: None.
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 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.
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.

This issue occurs because these devices do not stream the data. As a result, the graph does not display any data.

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)
This issue occurs because PTX10002-36CD do not stream the data. As a result, the graph does not display any data.

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

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.

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.
Publish the network implementation plan.
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

When updating placement-related parameters (such as the range name, left unit, or right unit values) for a previously provisioned service (such as an L2CKT service with a stitching interface), saving the Service Order and re-provisioning or performing a dry run causes the updated parameters to reset to their original values.

Workaround: Select one of the following methods depending on the service state:
- Before provisioning—Modify the range name, left unit, and right unit values immediately after performing the Update Placements operation before provisioning the service.
- After provisioning—If the service is already provisioned, delete the existing service instance, apply the required placement modifications, and then provision the service again.
When initiating a rollback for an L2VPN service and comparing version changes on the Review Changes page, L3VPN-related parameters (l3vpn_svc and l3vpn_ntw) unexpectedly appear in the differences view alongside the L2VPN service details.

Workaround: None. You can safely ignore the extra L3VPN-related entries since they do not impact the execution or outcome of the L2VPN service rollback.
When a device is adopted into Network Inventory without an associated site (where site_id=None), device onboarding is not automatically triggered, even if a network implementation plan with valid site information is configured. In addition, manually selecting Trigger Onboarding for the device from the Network Implementation Plan page fails with the following error:
device must have mac, id, site_id
Workaround: Assign a site to the device in Network Inventory before adopting the device or before selecting Trigger Onboarding from the Network Implementation Plan page.
When you publish a network implementation plan, the onboarding workflow may occasionally take up to 45 minutes longer than expected to start. This occurs when a duplicate onboarding request is submitted for the same network implementation plan shortly after the initial request, causing the network implementation plan to remain in a queued state for that duration. The onboarding workflow starts automatically after the delay and does not require any manual intervention.‌

Workaround: None
After you update a network implementation plan, you must manually publish the network implementation plan before offboarding a device. Otherwise, a resource conflict might occur during the deletion process.

Workaround: To publish the updated network implementation plan, on the Network Implementation Plan page (Inventory > Device Onboarding), select that plan that you want to publish and click Provision.
If you upgrade a network implementation to a newer infrastructure service design, the updated configuration might not be automatically pushed to the device.

Workaround: After you upgrade a network implementation to a new infrastructure service design, ensure that you perform the Force Sync operation (Inventory > Device Onboarding > Network Implementation plan > More > Force Sync).
In some cases, infrastructure service designs cannot be uninstalled, which prevents upgrading to release 2.9.0. This issue occurs when a service instance has been upgraded but has not been placed, resulting in a mismatch between the Order database and the Placement database after the upgrade.

Workaround: Run a Modify operation on the affected service instance to place the instance. After the instance is successfully placed, the deprovision operation should complete as expected.
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

During Test Agent installation on Junos OS Evolved devices (such as ACX) running software versions earlier than release 23.2R2, the Test Agent might transition to the Installed state even though the Test Agent Docker container fails to start.

Workaround: Hard-delete the Test Agent, then create and install the Test Agent again on the affected device. You can perform a hard delete in one of the following ways:
- Delete the Test Agent by using the Delete option (More > Delete) on the Test Agent page (Inventory > Active Assurance). Deleting the Test Agent using the GUI automatically performs a hard delete.
- Use the REST API and specify force=true in the DELETE request:
Measurements that send test traffic to the device being replaced may experience temporary disruption while the replacement is in progress. During this period, the device may not respond to test traffic, which can result in:
- Measurement errors
- Packet loss reports
- Temporary test failures
- Gaps in measurement results
Workaround: None. Measurements typically resume normal operation once the device replacement process is complete
Under rare circumstances (for example, when PostgreSQL is inaccessible), the device replacement workflow may remain incomplete, causing the affected Test Agent and its measurements/monitors to become non-functional. You might notice the following after you replace a device:
- The Test Agent Device MAC address may not be updated to the replacement device MAC within a reasonable time frame (approximately one hour).
- Events related to the device replacement may not be generated for the affected Test Agent or its associated measurements.
- Test Agent may not be installed on the replacement device.
- Measurements running on the Test Agent Device may fail to configure or report polling results.
Workaround: Manually recreate the Test Agent and any associated Measurements or Monitors.
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.
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.
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.
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.
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.
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 cases, the Topology page (Observability > Network) may not display any links after BGP peering is removed and immediately re-added.

When BGP peering is removed, the BMP pod and its associated resources require time to be fully cleaned up. If the peering configuration is re-added before the cleanup process completes, the BMP pod may be recreated before the required PersistentVolumeClaim (PVC) becomes available. As a result, the BMP pod remains in the Pending state, preventing topology links from being displayed.

Workaround: After removing the BGP peering, wait for the cleanup process to complete before re-adding the peering 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.
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.
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.
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

Planner does not consider secondary and standby LSPs to be related with the corresponding primary LSP. Instead, Planner treats them as independent LSPs, which leads to unexpected simulation results.

Workaround: None.
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.
When a tunnel has no current path, the topology map (Planning > Networks > Offline Models > Working-Model > Open) 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.
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

The End of Engineering (EOE) and End of Life (EOL) dates displayed under Trust > Software EOL, Trust > Software EOE and Network Inventory > Software pages may appear one day earlier than the dates published on the official EOE/EOL support pages.

This issue occurs because the back-end API returns EOE/EOL timestamps normalized to 00:00:00 UTC (midnight UTC). When the GUI renders these timestamps using the your local browser timezone, if you are in timezones behind UTC, you may see the date converted to the previous calendar day. As a result, the dates shown in the GUI can differ by one day from the following EOE/EOL support pages:
- Junos OS Evolved Dates & Milestones
- Junos OS Dates & Milestones
Workaround: None.

Administration

There are no known issues in this release.

Installation and Upgrade

When upgrading a single-node deployment from release 2.9.0, the atom-db-pooler deployment may become stuck during the rolling update process, causing the pod to remain in a Pending state. As a result, the cluster health check may report a Red status.

Workaround: If the upgrade fails and the atom-db-pooler pod is observed in a Pending state, manually scale the deployment down and back up:

kubectl scale deployment -n airflow atom-db-pooler --replicas 0

Wait until the existing pod is removed, then scale the deployment back to one replica:

kubectl scale deployment -n airflow atom-db-pooler --replicas 1

After the pod is running successfully, rerun the upgrade.
On some single-node deployments running release 2.9.0, an atom-db-pooler or OpenSearch pod may already be stuck in a Pending state before the upgrade begins, typically following a previous atom-db-pooler restart. In this condition, the pre-upgrade health check reports an Amber or Red cluster status and prevents the upgrade from proceeding.

Workaround: Apply this workaround if the health check reports an Amber or Red status caused by atom-db-pooler or OpenSearch pods remaining in a Pending state.

For atom-db-pooler, reset the deployment replica count:

kubectl scale deployment -n airflow atom-db-pooler --replicas 0

Wait for the pod to be removed, then restore the replica count:

kubectl scale deployment -n airflow atom-db-pooler --replicas 1

For OpenSearch, run:

paragon-opensearch-overwrite-replica

Verify that cluster health is healthy before rerunning the upgrade.
While upgrading from release 2.9.0 to release 2.10.0, the upgrade may fail if the hostname contains uppercase letters.

Workaround: Before upgrading, ensure that all hostnames contain only lowercase letters.
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.

ON THIS PAGE