Resolved Issues
This section lists the issues resolved in Juniper Routing Director Release 2.9.0:
-
In a multinode setup, taking a backup after a node has failed may cause the backup operation to fail.
-
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.
-
Not all devices are listed in the L3VPN accordion on the Passive Assurance tab (Orchestration > Instances > service-instance-name hyperlink > Service-Instance-Name Details).
- 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.
-
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.
-
Bulk deletion for Path Computation Element Protocol (PCEP) segment routing (SR) LSPs on Cisco IOS XR is not supported.
-
You cannot delete unwanted nodes and links from the Routing Director GUI.
-
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.
-
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.
-
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:
-
Install Release 2.7.0 afresh.
-
Upgrade from Release 2.6.0 or Release 2.70 to Release 2.8.0. Ensure that the fabric drop is not enabled.
.
-
-
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.
-
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.
-
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).
-
After restoring a backup, the Adjacencies tab (Observability > Routing > Route Explorer) may display an incorrect state for BGP peers.
-
In a scaled setup, you cannot upgrade service instances in bulk.
-
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.
-
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.
-
-
Due to Kafka message size limitation, you can delete only 200 LSPs at a time.
-
When traffic on a label-switched path (LSP) drops to 0, Junos OS telemetry doesn’t report a 0 value because
zero-suppressionis 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. -
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.
-
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.
-
The admin-group constraint that is set in a tunnel is not considered during the what-if failure simulation.
-
In an offline model, if there are links without interfaces, then the exhaustive failure simulation might fail and a report is not generated.
-
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.
-
Planner incorrectly uses TE metrics to compute SR tunnel paths when the routing method is set to routebydevice.
-
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.
-
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%.
-
The number of unhealthy devices listed on the Troubleshoot Devices and Health Dashboard pages (Observability > Health) do not match.
-
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:
Awaiting configuration synchronization from the primary node ...
-
You might encounter the following error while upgrading or redeploying Routing Director configured with multiple network interface cards (NICs):
Current host IP: 10.123.42.1 Master Node 1 IP: 192.168.69.5 error: This host is not master node 1, where this Deployment cluster was initially installed from! Please run upgrade from master node 1: 192.168.69.5
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.
-
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.
-
When the responses are delayed, the LLM Connector chat window auto-scrolls up and down unexpectedly.
-
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.
-
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.
-
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).
-
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:
curl -X PUT -H "Content-Type: application/json" \ -u test@test.com:Test-Password \ "https://VIP-1/api/v1/orgs/{org-id}/gnmi/options" \ --data '{"device": {"client-certificate-request": "require-certificate-and-verify"}}' --insecure -
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).
-
Although the Documentation mode is configured, the Conversation mode is erroneously activated when you open an LLM Connector chat window.
-
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.