Resolved Issues | Juniper Networks

Sometimes, the onboarding workflow might restart for a device that is already onboarded. This is harmless, as the workflow will observe that the node is already onboarded, report the observation, and exit.

Airflow scheduler pod may crash when multiple onboarding DAGs are triggered simultaneously.

By default, Airflow allocates 10 GB of disk space in the PVC mount directory (/opt/airflow/mount/). When multiple onboarding DAGs are triggered simultaneously, excessive logs are generated thereby filling up the disk space and potentially causing the Airflow scheduler pods to crash.

You cannot release a Cisco device using the Release Router option. This issue occurs if you have added the Cisco device to Paragon Automation from the Inventory page (Inventory > Devices > Network Inventory) and you have used non-alphanumeric characters for the MAC address.

For PTX10001, PRX10004, and PTX10016 devices, the PSM Temperature graph on the Hardware Details for Device-Name page (Observability > Troubleshoot Devices > Device-Name > Hardware accordion > PSUs) does not display any data.

Sometimes, data points on the graphs on the Input/Output Traffic Details for Device-Name pages (Observability > Health >Troubleshoot Devices > Device-Name > Overview > Interfaces (accordion) > Input/Output Traffic data link) are displayed as critical even though the traffic is below the threshold level.

When the LACP state of a child interface is down, the aggregated interface speed also comes down based on how many child interfaces are active at the point of data collection. However, when the LACP state of the child interface is up, the aggregated interface speed also increases. Because the child interface LACP state is toggling, the aggregated interface speed also toggles and alerts are raised as the input/output traffic utilization is beyond the threshold with the reduced speed. But in the graph, since the latest thresholds are plotted, alerts might be raised even though the traffic is below the threshold.

The Connectivity accordion (Observability > Troubleshooting Devices > Device-Name) shows no data although connectivity tests are properly run and passed.

You cannot delete a Test from the Test-Name page (Observability > Active Assurance > Test > Test-Name > Test-Name > More > Delete). The following error is displayed and the Test that you tried to delete is retained:

Failed to delete Test

On rare occasions, e-mails might not be sent out due to Kafka connection issues. The mail service logs display the following error:

"message":"dial tcp
          10.x.x.43:9092: connect: connection refused"

This issue can occur anytime, but more commonly when the cluster has been upgraded or when a cluster node has been rebooted.

The following limitations are seen when you use the service orchestration cMGD CLI to modify the placement-interface information of an L3VPN service:

The initial placement-interface options that were populated when the service order was created are not displayed.
You can select the interface for the site access from all the interfaces present on the CE or PE device.
When you modify the PE topology and the available ports in the topology, you must:
1. Delete the existing placement-interface and placement-options from the site network access by using either REST API or the service orchestration cMGD CLI.
2. Execute the request service order modify command to regenerate the service order with the modified values for the placement-options.

While configuring an EVPN service order, the GUI does not throw a validation error even if you specify a value that is equal to 1 Tbps for CBS and CIR fields.

Scheduling provisioning of service orders is a Beta feature in Release 2.1.0. Except in fresh installations, scheduling may not work consistently.

While modifying a resource instance, if you update VLAN with a value higher than the current specified value then the Modify Resource Instance operation fails.

The service order fails with the error message, Invalid XML document, namespace is missing.

On the Customer Inventory page (Orchestration > Customers), when you click the View Instances hyperlink to view the service instances provisioned for the customer, a filter for the Customer field is automatically applied on the Service Instances page. Since filtering is not supported for the customer field, you may not see any data.

While creating an L3VPN service instance if you click Reset Placements, the resources are cleared from the UI. However, these resources are not released from the back end.

When you click Update Placements while modifying services, a confirmation message appears that the placements are successfully updated even though the REST API returns an error.

You must configure access diversity while creating an EVPN service order with all-active or single-active redundancy modes. However, the Access Diversity section is not populated in the UI.

After you upgrade Paragon Automation from Release 2.1.0 to Release 2.2.0, the vpn resource instance does not appear on the Resource Instances page (Orchestration > Service > Resource Instances). This issue occurs because the vpn service design has been renamed to vpn-resources in Release 2.2.0.

While provisioning an EVPN service order, if you mark an access interface as untagged, the placement may still pick up a tagged interface from interface resources defined in the topology file.

For example, if et-0/0/2 is defined as untagged and et-0/0/3 is defined as a tagged interface in the topology resources, then the service order sets the access interface as untagged and the automatic placement may still pick up the tagged et-0/0/3 interface.

If you modify an L3VPN service to update the routing protocol then the changes are not reflected in the L3VPN accordion (Orchestration > Instances > Service Instances > Service-Instance-Name hyperlink > Passive Assurance).

We recommend that you do not enable LDP for IPv6 for the L2 circuit.

Sometimes, the Interface Status column on the Passive Assurance tab of the L3VPN-Name Details page (Orchestration > Instances > Service-Instance-Name hyperlink) may not display data. Occasionally, you may not see any data on the Interface Status graph.

Sometimes you may notice that the previously-available Test Agents and previously-provisioned Monitors are not shown in the GUI. In addition, the performance tests are timing out and the measurements are stopped.

If you try to adopt Cisco devices using the GUI or try to register Cisco devices in bulk using the REST APIs then the system does not trigger a connection to the devices. Therefore, the device status is shown as disconnected.

The order state of a network implementation plan does not reflect the onboarding status of individual devices in the plan. The order status may show as a success even if the device onboarding has failed.

On the Tests page (Observability > Active Assurance), the Test summary that is displayed on the info card is not based on the time range that you have selected. Instead, the Test summary is based on the number of Tests listed on a specific page.