Known Issues

This section lists the known issues in Paragon Automation.

• The timeline graph on the Tests (Observability > Active Assurance) page does not display the start and end time of a Test. Instead, the graph displays the number of times Tests are run for a selected duration.

  Workaround: None.

• The Hardware accordion does not display the following information for the listed devices:

  • Chassis temperature (chassis-temperature) for MX204, MX240, MX304, MX10004, MX10008, and MX10016 devices.

  • Charts related to the speed of the fan (rpm-percent) for MX480, MX960, MX10004, MX10008, and MX10016 devices.

  • Power supply module temperature (psm-temperature) information for MX204, MX480, and MX960 devices.

  • Line card charts for some ACX Series and MX Series devices as the flexible PIC concentrator (FPC) fields are not supported on these devices. See Table 1 for more information.

    Table 1: Line Card Charts Support

    Device Family	Device Series	FPC Fields Not Supported
    ACX Series	ACX7100-32C, ACX7100-48L, ACX7024, ACX7024X, ACX7509, ACX7348	fpc-temperature, fpc-cpu-utilization, fpc-buffer-memory-utilization
    MX Series	MX204, MX240, MX304, MX480, MX960, MX10004, MX10008, MX10016	fpc-temperature, fpc-cpu-utilization

• On the Interfaces accordion, forward error correction (FEC) corrected errors and FEC uncorrected errors charts are available only on interfaces that support speeds equal to or greater than 100-Gbps.

• On the Identity & Location accordion (Intent > Device Onboarding > Put Devices into Service > Device-Name), even though the status of the device is displayed as Healthy, sometimes you might notice a yellow triangle icon (indicating minor alert) instead of a green circle icon.

  Workaround: None.

• If a node in the cluster is inoperational, the status of the vector pod from the inoperational node is displayed as Running, even though the node status is reported as Not Ready. This is due to an existing Kubernetes issue. See https://github.com/kubernetes/kubernetes/issues/117769.

  Workaround: You can do one of the following:

  • Monitor the metric, kube_daemonset_status_number_ready. When the value for this metric drops to three, you can manually check from which vector the data is missing.

  • Set a query and an alert for the kube_daemonset_status_number_ready metric in Grafana.

• You might encounter RKE2-related issues if you change the hostname after you set up a cluster.

  We recommend that you do not change the hostname after a cluster is set up.

  Workaround: None.

• You cannot delete a Monitor from the Monitor-Name page (Observability > Active Assurance > Monitors > Monitor-Name).

  Workaround: None.

• The REST API, api-aggregator, does not capture events that are related to Active Assurance.

  Workaround: None.

• If you have specified a value for VLAN for an interface at the time of Service Order creation, after the placement configuration is generated and committed on the devices, the interface VLAN is displayed as 0 on the UI.

  Workaround: Log in to the service orchestration cMGD CLI, synchronize the service order with the order manager (request service order sync), and modify the service order (request service order modify) in service orchestration cMGD CLI to remove the selected interface option.

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

• Sometimes, the apply insights configuration (appy_insights-config) fails if you try to provision a service without properly deleting a previously provisioned service or a device.

  For example, if you release the router without off-boarding or delete a service, then the apply insights configuration fails when the same service or device is used in another organization.

  Workaround:

  • If there are stale services and devices, run the following REST APIs from the cMGD container of the foghorn namespace to delete stale services and devices, and rerun the workflow:

    • curl --request DELETE <http://config-server.healthbot:9000/api/v2/config/services/device-group/<device-group> name>/

    • curl --request DELETE <http://config-server.healthbot:9000/api/v2/config/device-group/<device-group> name>/

    • curl --request POST http://config-server.healthbot:9000/api/v2/config/configuration/

  • If there are stale network-groups, run the following REST APIs from the cMGD container of the foghorn namespace to delete the stale network-groups, and rerun the workflow:

    • curl --request DELETE <http://config-server.healthbot:9000/api/v2/config/services/device-group/<network-group> name>/

    • curl --request DELETE <http://config-server.healthbot:9000/api/v2/config/device-group/<network-group> name>/

    • curl --request POST http://config-server.healthbot:9000/api/v2/config/configuration/

• If you modify an existing Monitor and then restart the Monitor, the events that are raised before modifying the Monitor are not cleared.

  Workaround: None.

• 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 numbers of Tests listed in a specific page.

  Workaround: None.

• When you enable e-mail notification for alerts and alarms, e-mails are sent to the recipients even if system-wide SMTP is not configured through Paragon Shell.

  Workaround: None.

• When SMTP is configured through Paragon Shell, and you enable e-mail notification for alerts and alarms, the e-mails are sent from no-reply@mailservices.juniper.net, instead of what is configured through Paragon shell.

  Workaround: Run the kubectl edit -n papi configmap eop-papi command and then change the default values for the following in the configuration file:

  EMAIL_SENDING_DOMAIN = 'mailservices.juniper.net'

  DEFAULT_EMAIL_FROM = f'no-reply@{EMAIL_SENDING_DOMAIN}'

• 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 almost 3 to 6 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.

• When you enable the Show LEDs, Ports & Cables on Chassis toggle button on the Hardware accordion (Observability > Troubleshoot Device > Device-name > Overview Tab), the chassis view displays the port status incorrectly.

  Workaround: None.

• The customer name and the VPN ID must be unique when you create an L3VPN service order. Otherwise, the service order creation fails.

  Workaround: You need to manually ensure that customer names and the VPN IDs are unique in an organization.

• If you modify an existing L3VPN service to update certain fields such as access diversity, zip code, or device reference, the service provisioning fails as the outdated placement-related information is sent to the REST API.

  Workaround: To ensure successful provisioning after modifying access diversity, zip code, or device reference:

  1. Delete the existing network access connection.

  2. Create a new network access connection with the desired settings that might affect placement.

• There is no synchronization between accessing and configuring devices. The workflow might fail if another service order is used to configure a device.

  Workaround: If two different service orders are likely to affect the same device, we recommend that you wait until the first service order is executed before you start the next service order.

• When you use the Release Router option to release the device from being managed by Paragon Automation, the device might not be released as the service orchestration engine might still be referencing the device that you want to release.

  Workaround: Before you use the Release Router option, update the network implementation plan and service instances so that the services no longer use the device you are trying to release. Also, the node should be removed from the pool of resources.

• While creating or modifying an L3VPN service, you cannot set the Access Diversity settings parameters on the Site Network Access page and set the device references simultaneously. The placement fails to place the site network access on an available port.

  Workaround: None.

• If the device onboarding fails, the device onboarding status is displayed as Status is not available in the Devices section of the Network Implementation Plan page (Inventory > Device Onboarding).

  Workaround: For such devices, initiate the outbound SSH connection on the router so that the onboarding workflow restarts.

• When you deprovision a service, the service orchestration engine attempts to remove the configuration from the device. In case, the service deprovision fails, the service orchestration engine retries this operation three more times. In spite of multiple retries, sometimes, the service instance is not removed and the service deprovisioning status is erroneously displayed as success. Check the workflow of the service order for a detailed status.

  Workaround: None.

• When the worker node is down, there might be issues if you create an organization or onboard a device.

  Workaround: Do not create an organization or onboard a device when a worker node is down. You must wait until the cluster recovers and then create an organization or onboard a device. Recovered state is when all the pods are either in Running or Pending state and are not in any intermediate states like Terminating, Crashloopback, and so on.

• When you navigate to chassis view (Observability > Troubleshoot Device > Device-name > Overview Tab > Hardware accordion) and either try to access the minimize/maximize controls or wait for a minute or two, sometimes an “Error occurred in the component” message is displayed and the entire Overview tab blanks out.

  Workaround: Refresh the browser or go back to the Troubleshoot Devices page and re-navigate to chassis view.

• The VPN ID field on the Add or Modify L3VPN page is restricted to 9 characters to avoid failure of L3VPN service provisioning. This restriction is due to a configuration field size limit on Junos OS.

  Workaround: None.

• When you modify the VPN ID for an existing L3VPN service, the provisioning fails because the PAA RPM monitor refers to the old routing instance.

  Workaround: Delete the paa-dmgw-plugin-rpm_ping-mmt-* groups, apply-groups manually on the devices and republish the L3VPN service.

• Even though the Delete L3VPN Service operation is successful, the service order and the resources allocated to the service are not removed.

  Workaround: To remove the service order and the resources allocated to the service, initiate the delete process again.

• If you make multiple changes to a service order before executing a service order then only the last service order has a workflow associated with it. When you delete a service instance the order history also gets deleted.

  Workaround: None.

• The Optical Rx Power and Optical Tx Power charts do not display any data when you click the Input Traffic data-link on the Interfaces accordion (Observability > Health > Troubleshoot Devices > Device-Name > Overview).

  Workaround: None.

• You might be able to execute REST APIs that are not supported.

  Workaround: Use only the REST APIs that are documented in the REST API Reference Guide.

• The request service project add /data-models/projects/project-name command fails if the project that is being added has a dependency on another project. For example, if the onboard.tgz has a dependency on network-resource.tgz, then the request service project add /data-models/projects/onboard.tgz command fails.

  Workaround: Add the force keyword and execute the command.

  request service project add /data-models/projects/project-name force

• On the Hardware accordion (Observability > Troubleshoot Device > Device-Name), the value of available units for CPU and Memory is always displayed one extra compared to the units that are actually available on the device. This issue occurs for the following devices: ACX7100-32C, ACX7100-48L, ACX7024, ACX7024X, ACX7509, ACX7348, MX204, MX240, MX304, MX480, MX960, MX10004, MX10008, MX10016.

  Workaround: None.

• The output of the request paragon storage cleanup command erroneously displays the total reclaimed space as 0 bytes even though multiple files are cleared after executing this command.

  Workaround: None.

• The history of the service orders that are generated for a service instance is saved in the Order History Tab for auditing purposes. However, when you delete the service instance, the service order history gets deleted.

  Workaround: None.

• If an adopted device and a node that is not yet onboarded have the same serial number, then they are listed as two different devices on the Put Device Into Service page (Inventory > Onboarding Dashboard).

  Workaround: When you see two devices with the same serial number, consider these devices as a single device.

• If you modify an L3VPN service, the historical data for Monitors related to the modified L3VPN service are deleted.

  Workaround: None.

• The following ports are reachable from outside the Paragon Automation cluster; we recommend that you block access to these ports: 22, 443, 2222, 2379, 2380, 5473, 6443, 7472, 7946, 8443, 9345, 10250, 10260.

  Note:

  These ports should not be blocked for intra-cluster communication.

  Workaround: None.

• When you run the request paragon ssh-key command, the previously-generated SSH keys in .ssh/authorized_keys and the SSH keys that you have added are cleared, and new SSH keys are generated for nodes.

  Workaround: You need to manually update the SSH keys in the authorized_keys file.

• The service orchestration engine onboards nodes in a network implementation plan sequentially even if the devices are adopted simultaneously. The service orchestration engine can onboard devices in different plans concurrently. We recommend that you do not onboard more than 5 devices, spread across 5 different plans, concurrently.

  Workaround: If onboarding for a device fails due to a recoverable condition, you can resume the device onboarding by flapping the outbound-ssh connection on the device. That is, deactivate and reactivate the outbound-ssh configuration so that the onboarding can be resumed.

• Initially, no data is displayed on the Fans charts when you select time ranges other than 30m on the Hardware Details for Device-Name page in the Hardware accordion (Observability > Troubleshooting Devices > Device-Name). Based on the time range you have selected, you need to wait for the following time duration for the data to be populated:

  • 3h—Approximately 10 minutes.

  • 1d—Approximately 1 hour.

  • 1w—Approximately 7 hours.

  Workaround: None.

• When you upload the topology network resources for a service, you must ensure that the interfaces are not channelized; otherwise, the placement fails.

  Workaround: None.

• Paragon Automation does not push firewall filter configuration to ACX Series devices as firewall filter configuration is not supported on them.

  Workaround: None.

• While configuring a Site Network Access for an L3VPN service, the minimum value that you must specify for Service Input Bandwidth and Service Output Bandwidth fields must be 20,000 bps. Otherwise, the service provisioning fails.

  Workaround: None.