Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Resolved Issues

This section lists the issues resolved in Juniper Routing Director Release 2.7.0:

  • In some cases, when you offboard a device from Routing Director, the BMP configuration on the router may not be removed. This causes any further attempts at onboarding and offboarding devices fail, and leads to inconsistent entries in the Routing Explorer > Devices and Routing Explorer > Adjacencies tables.

  • When you click the Distribution tab on the Application-Name page (Observability > Health > Health Dashboard > Active Assurance (Tab) > Applications (Accordion) > View Details), the page hangs and you might not be able to see metrics and site-related data for a Measurement.

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

  • If the configuration database is locked exclusively by a root terminal session, then tunnel provisioning fails and the status is displayed as Unknown.

  • You might not be able to increase the disk size on an already installed system.

  • After the placement of a logical tunnel using either the Update Placements option or through successful provisioning, if you try to assign a possible placement again using the Update Placements option, then all Logical Tunnel interfaces and ranges are not displayed on the Logical Tunnel Placement section

  • When you run the request deployment troubleshooting information command, the output includes syslog files from the previous execution.

  • If different L3VPN services are running on the same IFD using different MTU values, then service provisioning fails.

  • A report is not generated when you run a what-if failure simulation for shared risk link groups (SRLGs).

  • Planner reports are deleted based on the retention policy settings. However, reports older than the retention period are deleted only when the scripts are run. The cleanup scripts are scheduled to run at midnight everyday.

    Workaround: None.

  • When creating SR tunnels with a Count value greater than 1, the same color is applied to all the tunnels, which results in an error.

  • In a scaled environment when you provision multiple VPN instances parallelly, some of the instances may fail with the following error in the workflow:

  • While provisioning multihoming for an EVPN service, if multiple cvlan_ids are provided for the same site network access, then the same ESI ID is allocated to all the access circuits provisioned for that site network access.

  • The Logical tunnel (LT) interface configuration is not persisting through Device Profile Placement Resources.

  • After you upgrade to Release 2.5.0, you might notice that the following pages might take more than 10 minutes to display device-related information:

    1. Inventory page (Observability > Troubleshoot devices > Device-Name)

    2. Devices tab on the Topology page (Observability > Topology)

  • After you perform the Undelete operation, the commit operation for the Test Agent fails. This issue occurs regardless of the interface involved.

  • If the specified Tunnel Delay Violation Interval is lesser than the LSP Latency Interval (default value is 5 minutes), then the threshold maximum delay rerouting will not happen.

  • When a new unmonitored device is added to the ISIS database for the first time, it takes around 10 minutes for its prefixes to be reflected in the IGP heatmap.

  • LDAP authentication may not work for users that are not included in the CN=Users container.

  • In an air-gapped installation, the cluster deployment might fail with the following error:

    TASK 2376 [jcloud/airflow2 : Install Helm Chart]

  • If the cluster VMs are in different geographical locations or if the latency between VMs is equal to or more than 25ms, you must increase the timeout period.

    Log in to the Linux root shell of one of the primary VMs and run the following patch commands: