Known Issues

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.

• When a vMX is deployed using I2C ID 161, all commit operations will fail after a subscriber is created.

  Workaround: Delete the subscribers and then commit the configuration.

• Routing Director triggers the configuration templates included in a device profile and interface profile only during the initial onboarding of the device. You cannot use the configuration templates included in the device profiles and interface profiles to apply additional configuration on a device after the device is onboarded.

  Workaround: If you need to apply additional configuration on a device after the device is onboarded, you need to manually apply the configuration using the CLI or by executing the configuration templates through the Routing Director GUI.

Observability

• Inconsistent Y-axis scaling in the Input, Output and Drop Rate graph on the Traffic Loss page (Observability > Health > Troubleshoot Devices > Device-Name > Overview > Routing and MPLS accordion > Traffic Loss Alert link) causes a misleading representation of traffic rates.

  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 both L1 and L2 are enabled simultaneously, the IGP Prefixes tab (Observability > Routing > Route Topology) does not display prefixes for both levels. Instead, only L1 prefixes are displayed. Dual-level (L1 + L2) prefix support is not supported.

  Workaround: To view prefixes correctly, on the Analytics tab of the Device Profile page (Inventory > Devices > Device and Interface Profiles > Add > Device Profile), select LSDB for a device in L1 or in L2 only. Avoid selecting a device configured for both L1 and L2.

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

• After restoring a backup, the Adjacencies tab (Observability > Routing > Route Explorer) may display an incorrect state for BGP peers.

  Workaround: Flap the BGP peers on the monitored device.

• Under certain conditions, transient traffic loss may cause a Packet Drop (Major) alert to be misclassified as a Blackhole (Critical) alert. You can identify such alerts by checking for identical start and end times.

  Workaround: None.

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

• Although the Documentation mode is configured, the Conversation mode is erroneously activated when you open an LLM Connector chat window.

  Workaround: Switch the interaction mode to Documentation manually before initiating a prompt. Once selected, the session operates as expected.

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

• SASL Username and Password fields are cleared unexpectedly when you enable the Use TLS Encryption toggle button on the Add Destination page (Management > Export Manager > Manage Destination).

  Workaround: Re-enter the SASL Username and Password fields after you enable the Use TLS Encryption toggle.

• In spite of auto-refresh, alerts listed and data displayed on the graph might not be synchronized on the Output Traffic Details for Device-Name page (Observability > Health > Troubleshoot Devices > Device-Name > Overview > Interfaces (accordion) > Output Traffic).

  Workaround: Close and reopen the Output Traffic Details for Device-Name page (Observability > Health > Troubleshoot Devices > Device-Name > Overview > Interfaces (accordion) > Output Traffic) to see the latest data.

• Starting with Release 2.8.0, Juniper Routing Director initiates the gNMI dial-in connection to Juniper devices to collect telemetry data. You must ensure that the corresponding firewall rules allow traffic towards devices on port 32767 from the Routing Director collector.

  We have disabled certificate verification by default. If you want to re-enable certificate validation, ensure that the devices in your network run on any releases other than Junos OS or Junos OS Evolved Releases 24.2R1, 24.2R2, and 24.4R1. Use the following REST API command to re-enable certificate validation:

• Sometimes, there is a mismatch in the severity level that is displayed in the Severity column of the Troubleshoot Devices page (Observability > Health > Troubleshoot Devices) and the Device tab of the Topology page (Observability > Network > Topology).

  Workaround: None.

• The Traffic Loss link on the Routing and MPLS accordion (Observability > Health > Troubleshoot Devices > Device-Name > Overview tab) shows zero alerts when there is a delay in raising an alert due to slow data processing. This may result in an inaccurate active alert count.

  The issue gets resolved when the data is processed. You can see a non-zero active alert count again when the data is processed.

  Workaround: None

• You might see duplicate blackhole alerts on the Traffic Loss page (Observability > Health > Troubleshoot Devices > Device-Name > Overview > Routing and MPLS accordion > click Traffic Loss Alert link) even though traffic is continuous. This issue occurs only when you upgrade from Release 2.5.0 to Release 2.6.0 or Release 2.7.0. You won't encounter this issue if you have installed Release 2.7.0 afresh.

  Workaround: If you have upgraded to release 2.7.0, delete the blackhole index, by running the curl -X DELETE "http://$(kubectl get svc -n common opensearch-cluster-master -ojsonpath='{.spec.clusterIP}'):9200/blackhole_detection command.

  Note: You might lose all the data processed before the upgrade.

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

• The Device Count column on the IGP Prefixes tab (Observability > Routing > Route Topology) might display inaccurate data. It takes approximately 30 minutes for the device count to be updated when a new device starts originating the prefix or when a device stops originating the prefix.

  Workaround. Device count may not immediately reflect recent changes and may be inaccurate for up to 30 minutes. We recommend that you wait for approximately 30 minutes to get the latest device count.

• When the responses are delayed, the LLM Connector chat window auto-scrolls up and down unexpectedly.

  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:

  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.

• The number of unhealthy devices listed on the Troubleshoot Devices and Health Dashboard pages (Observability > Health) do not match.

  Workaround: None.

• You cannot delete unwanted nodes and links from the Routing Director GUI.

  Workaround: Use the following REST APIs to delete nodes and links:

  • REST API to delete a link:

    [DELETE] https://{{server_ip}}/topology/api/v1/orgs/{{org_id}}/{{topo_id}}/links/{{link_id}}

    Note:

    You can follow the steps described here to get the actual URL.

    For example,

    • URL: 'https://10.56.3.16/topology/api/v1/orgs/f9e9235b-37f1-43e7-9153-e88350ed1e15/10/links/15'

    • Curl:

  • REST API to delete a node:

    [DELETE] https:// {{Server_IP}}/topology/api/v1/orgs/{{Org_ID}}/{{Topo_ID}}/nodes/{{Node_ID}}

    Note:

    You can follow the steps described here to get the actual URL.

    For examples,

    • URL: ' https://10.56.3.16/topology/api/v1/orgs/f9e9235b-37f1-43e7-9153-e88350ed1e15/10/nodes/1'

    • Curl:

    Use the following procedure to get the actual URL that you use in CURL for deleting a link or a node:

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

    2. Open the developer tool in the browser by using the CTRL + Shift + I buttons in the keyboard.

    3. In the developers tool, select Network and select the XHR filter option.

    4. Identify the link index number or node number. To identify the link index number to the node number:

       1. On the Topology page of the Routing Director GUI, double click the link or the node that you want to delete.

          The Link Link-Name page or the Node Node-Name page appears.

       2. Navigate to the Details tab and note the link index number or the node number that is displayed.

    5. In the developers tool, select and click the row based on the link index number or the node number that is related to the link or the node that you want to delete.

    6. Copy the URL that you need to use to delete the link or node in CURL.

• 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

• MX104 and ACX2200 devices do not support gNMI rules. Therefore, the Passive Assurance tab (Orchestration > Instances service-instance-name hyperlink > Service-Instance-Name Details) does not display Physical Interfaces and Logical Interfaces accordions for these devices.

  Workaround: None.

• If you use service designs created in Release 2.6.0 or earlier, we recommend that you upgrade your service designs to the latest version.

  Service configurations previously hard-coded in the GUI for older service designs are now automatically generated based on the service design definition. If you continue to use the older service design, ensure that you manually enter the IPv4 loopback address using the GUI.

• If you try to delete (deprovision) a service instance that previously ran in Dry-Run mode, the system mistakenly executes the delete action in Dry-Run mode. As a result, the service instance is not removed, and its status remains unchanged.

  Workaround: Do one of the following:

  • Run Provision on the instance to reset its state. Once provisioning is complete, run Deprovision.

  • Use the DELETE /service-orchestration/api/v1/orgs/{orgId}/order/customers/{custId}/instances/{instId} REST API to bypass the Dry-Run behavior.

• Not all devices are listed in the L3VPN accordion on the Passive Assurance tab (Orchestration > Instances > service-instance-name hyperlink > Service-Instance-Name Details).

  Workaround: The issue primarily occurs during upgrades. Restart all iTSDB pods simultaneously to resolve the issue.

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

• The description for the interfaces is missing in the Description column of the Add or Edit Devices section of the Add Network Implementation Plan page (Inventory > Device Onboarding > Network Implementation Plan > +).

  Note that the description for sub-units will be the same as that of the main interface description. If the descriptions for sub-units et-0/0/9.100 and et-0/0/9.200 are missing, you can refer to the description of the main interface, et-0/0/9.

  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.

• The following accordions on the Passive Assurance tab (Orchestration > Instances > Service-Order-Name Details) displays incorrect or no data:

  • BGP accordion—The VPN State column displays incorrect data for customer edge (CE) or provider edge (PE) devices with IPv4 or IPv6 neighbors.

  • OSPF accordion—There are no IPv6 entries in the Neighbor Address column for CE or PE devices with IPv6 neighbors.

  • L3VPN accordion—The VPN State column displays incorrect data for OSPF and BGP protocols. The Neighbor Session and VPN State columns are blank for CE or PE devices with static IPv4 or IPv6 address.

  This issue occurs only for an L3VPN service.

  Workaround: None.

• For an MX 240 device, the OSPF-related data is not populated on the Passive Assurance tab (Orchestration > Instances > Service-Order-Name Details).

  Workaround: Configure OSPF on the customer edge (CE) device.

• When you click the Refresh icon on the Service-Instance-Name Details page (Orchestration > Instances > Service-Instance-Name), you may not see the latest events in the Relevant Events section.

  Workaround: To view the latest events, instead of using the Refresh icon go to the Service Instance page (Orchestration > Instances) and select the service instance for which you need to see the latest events.

• The Order History tab on the L3VPN-Name Details page (Orchestration > Instances > Service-Instance-Name hyperlink) lists all the order history if you deprovision a service instance and later provision a service using the same details as that of the deprovisioned service.

  Workaround: None.

• In a scaled setup, you cannot upgrade service instances in bulk.

  Workaround: We recommend that you upgrade only a few service instances (less than 4) at a time.

Active Assurance

• If you upload an invalid plugin in the Plugin Inventory page (Inventory > Active Assurance), the UI does not display a clear error message and remains stuck at 0%.

  Workaround: Upload a valid .nap file.

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

• Only one path maximum transmission unit (Path MTU) server–client measurement pair can run at a time on the same server agent interface. When multiple Path MTU server measurements are started on the same agent interface, only the first server starts successfully. Subsequent servers produce error reports with the message: Failed to create test socket: Address already in use.

  Currently, when you create a Task for a Test execution, the GUI allows you to select one Server Agent and multiple client agents for the Path MTU plug-in, and therefore, you might encounter this issue.

  Workaround: None.

• 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

• The Container LSP feature is not supported in Release 2.8.0. The Container LSP Normalization check box on the Organization settings page (Settings Menu > System Settings) and container LSP-related REST APIs in the API Reference Guide are non-functional.

  Workaround: None.

• The path computation engine (PCE) of Routing Director does not use the delay type chosen by users in the Interface Delay Type field (Settings Menu > System Settings > Organization Settings > Network Optimization Settings) for computing paths for tunnels that are delay-based or have a maximum delay constraint. Instead, the PCE always uses the average delay value.

  Workaround: None.

• Bulk deletion for Path Computation Element Protocol (PCEP) segment routing (SR) LSPs on Cisco IOS XR is not supported.

  Workaround: Delete the LSPs individually.

• When traffic on a label-switched path (LSP) drops to 0, Junos OS telemetry doesn’t report a 0 value because zero-suppression is enabled by default. This can lead to unexpected results for features, such as bandwidth sizing and LSP rerouting on threshold crossing. The Routing Director’s path computation engine continues to use the last known traffic value of the LSP during events requiring LSP rerouting.

  Workaround: Disable zero-suppression on the router by using the set services analytics zero-suppression no-zero-suppression command.

• Events listed on the Events page Observability > Network > Topology > Tunnels tab > Tunnel-Name > View > Event History) do not contain route information of SR and SRv6 LSPs. Due to this issue, the Show Path Changes option might not work for SR and SRv6 LSPs.

  Workaround: None.

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

• Not all columns in the Event History table (Observability > Network > Topology > Tunnels tab > Tunnel-Name > View > Event History) are applicable to event history. So, you might see blank columns.

  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.

• When a router which resides on an MPLS LSP path raises the overload (OL) bit in its IGP domain, sometimes, the tunnel may not get rerouted away from that router.

  Workaround: Manually specify a large delay on a node with the overload bit.

• Due to Kafka message size limitation, you can delete only 200 LSPs at a time.

  Workaround: None.

• 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

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

• Planner incorrectly uses TE metrics to compute SR tunnel paths when the routing method is set to routebydevice.

  Workaround: You can change the tunnel’s routing method to ISIS or OSPF so that Routing Director can compute the tunnel path based on the IGP metric.

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

• SR-LSP-related modeling requires you to create a network model using the Import from Live option. Currently, a network model created using Import from Config won’t contain complete SR-related information.

  Workaround: Use Import from Live instead of Import from Config for SR networks.

• In an offline model, if there are links without interfaces, then the exhaustive failure simulation might fail and a report is not generated.

  Workaround: None.

• If you log out of the Routing Director GUI and re-login using the same tab or window of a browser, you may not be reconnected to Planning Offline Model or simulation notification services.

  Workaround: Refresh the browser before you re-login.

• The admin-group constraint that is set in a tunnel is not considered during the what-if failure simulation.

  Workaround: None.

• 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

• In the case of a scale deployment, when the system is under resource stress, you may notice that the papi-mon service pod restarts. This happens as part of the self-healing recovery, so that the service is restored.

  Workaround: None.

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

  Workaround: None.

Installation and Upgrade

• You might encounter the following error while upgrading or redeploying Routing Director configured with multiple network interface cards (NICs):

  This issue occurs because the /root/epic/host.ip file is populated with IP address used by the other NIC in the VM or is empty.

  Workaround: Verify and re-populate /root/epic/host.ip with the appropriate IP address before upgrading or redeploying Routing Director.

  You can also optionally make the /root/epic/host.ip file immutable to prevent overwrites by using chattr +i /root/epic/host.ip.

• Sometimes, it takes longer (approximately 10 minutes) to log in to the deployment shell of the cluster nodes. You see the following message before you can log in:

  Workaround: Manually delete the /root/temp folder by using the rm -rf /root/temp command. This forces the start.sh script to rerun the initialization.

• 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

• In a multinode setup, taking a backup after a node has failed may cause the backup operation to fail.

  Workaround: To perform a backup or restore operation, a fully operational setup with all services running is required. If a node is non-operational for any reason, we recommend that you resolve the issue before executing the backup or restore operation.

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