Resolved Issues | Juniper Routing Director 2.6.0

Upgrading from release 2.4.0 to release 2.5.0 or release 2.6.0 fails for all components in routing observability.

Under scale ingest, the service bgp-measurements-compute may restart continuously after crashing. This affects the calculation of aggregates such as the total routes graph in Observability > Routing > Routing Explorer > Routing Status. Other related dashboards and tables are unaffected.

Upgrading from release 2.4.0 to release 2.5.0 for fails for routing observability BGP components due to differences in implementations meant to improve ingest performance.

The following error message is displayed, although the service design upgrade is successful.

Service Design upgrade failed for 1 instance(s)

The incorrect error message is displayed only when you try to upgrade the service design in a VPWS instance that was originally provisioned in Release 2.4.1 and is now upgraded to Release 2.5.0.

In rare cases, the topology-related information might be lost or incomplete. This issue occurs due to the inaccessibility of databases.

Workaround: Restart the toposerver to restore topology information.

To restart the toposerver connect to the primary node of the Routing Director cluster and run the kubectl -n $(kubectl get namespaces -o jsonpath='{.items}' | jq -r '.[] | select(.metadata.name| startswith("pf-"))|.metadata.name') rollout restart deployment toposerver command.

You cannot configure OSPF TE Metric A and OSPF TE Metric Z parameters for a link that has OSPF enabled on it.

Workaround: None.

During heavy ingest scenarios such as onboarding of routers for the first time or router maintenance windows, it takes sometime for the total number of routes to be reflected on the Routing Status graph (Observability > Routing > Routing Explorer Routing Status tab).

If there are any events in the network, the Routing Status graph or the Routing Updates table (Observability > Routing > Route Explorer > Routing Updates) might display the data with substantial latency. We expect that the latency is reasonable during steady state operation of the network.

Also, the statistics in the Device tab (Observability > Routing > Route Explorer > Routing Status) or in the Adjacencies tab (Observability > Routing > Route Explorer) are updated with low latency (1 to 5 minutes).

Workaround: None.

The Alert icon and the alert message are out of sync during the first event change on the Custom KPI Collection page (Observability > Health > Custom KPI Collection).

The device name is not displayed when you hover over the View Details hyperlink in the Relevant Events section of the L3VPN accordion (Orchestration > Instances > Service Instances > Service-Instance-Name hyperlink > Service-Instance-Name Details > Passive Assurance tab).

When you modify the tag type from dot1q to qinq for the existing CE devices (that is, the ce or ces option of the CE Spec field) on the Access page (Orchestration > Resource Instances > Modify Resource-Instance-Name > Resource-Instance-Name > + icon above the Access Interfaces table), the VLAN information displays both tag types resources (numbered and dual numbered).

The Add Access Parameter page displays all options for the Tag Type field (Untagged, dot1q, or qinq), irrespective of whether you have chosen tagged or untagged interfaces for a customer edge (CE) device.

The Service Designs page (Orchestration > Service Catalog) might list certain internal service files. You can ignore these files.

If more than 2600 L3VPN services are provisioned, the placement service intermittently suffers a break in service which may cause service placement to fail. The placement service will automatically recover from this failure.

When creating l2-addr resource instance, adding only the LACP Admin Key without System ID results in a failure.

In a scale set up, the View Network Resources page (Orchestration > Service > Resource Instances > More) might be unresponsive.

On a scaled setup, the Resource Instance page takes a longer time to load due to slower responses of instances and the /service-designs REST API calls.

Workaround: None.

On the LLM Connector (Routing Director chatbot), you might not be able to continue the conversation if the session expires or if you open a new conversation

You might encounter the following error while upgrading or redeploying Routing Director:

This issue occurs because /root/epic/host.ip is empty.

After restoring from a backup, sometimes Airflow installation fails when you try to reinstall all application services using the request paragon service start command. It is possible that the Airflow pods are still shutting down.

Sometimes when taking a backup, the OpenSearch backup status is Not Available but others are successful. For example:

This is due to the status flag not being updated.

If a network implementation plan includes multiple devices, the device onboarding might not start automatically for some devices. However, you might notice that the device status is displayed as Connected on the Inventory page (Inventory > Devices > Network Inventory).

After you upgrade a service design, you must manually upgrade the service design that is used in the existing network implementation plans.

To upgrade the infrastructure service design used by an implementation plan:

On the Network Implementation Plan page (Inventory > Device Onboarding > Network Implementation Plan), select the plan and click More > Upgrade Service Design.

The Upgrade Service Design page appears.
On the Upgrade Service Design dialog box, click the drop-down list to select the service design version to which you want to upgrade the network implementation plan, and click Yes.

A message indicating that the service design upgrade is in process is displayed. After a successful upgrade, the Service Design column displays the new version of the infrastructure service design used by the network implementation plan.

If you upgrade a network implementation plan to the latest service design version and publish it without making changes, the service design is upgraded again instead of publishing the network implementation plan.

In clusters with inter-node delays in the tens of milliseconds, the workflow execution time increases. As a result, the time required to onboard devices and instantiate services also increases.

In a scaled environment, the network implementation plan provisioning might sporadically fail if multiple provisioning jobs are executed consecutively at a high rate. You might see the following error in the workflow GUI:

Provisioning is failing
          at upload-network-resources due to the error "numbered is in use and cannot be deleted;
          app.ErrorCode:3"

The link utilization reroute threshold feature works only if the same threshold values are specified on the nodes of a link.

Ensure that you specify the same values for Util Reroute Threshold AZ and Util Reroute Threshold ZA fields on the Edit Link page (Observability > Network > Topology > Link tab > Link-Name > Edit).