Known Issues

This section lists the known issues for the Juniper Networks CSO Release 3.2.

• In a three-node setup, two nodes are clustered together, but the third node is not part of the cluster. In addition, in some cases, the RabbitMQ nodes are also not part of the cluster. This is a rare scenario, which can occur just after the initial installation, if a virtual machine reboots, or if a virtual machine is powered off and then powered on.

  Workaround: Do the following:

  Procedure

  1. Log in to the RabbitMQ dashboard for the central microservices VM (http://central-microservices-vip:15672) and the regional microservices VM (http://regional-microservices-vip:15672).
  2. Check the RabbitMQ overview in the dashboards to see if all the available infrastructure nodes are present in the cluster.
  3. If an infrastructure node is not present in the cluster, do the following:

     Procedure

     1. Log in to the VM of that infrastructure node.
     2. Open a shell prompt and execute the following commands sequentially:

        rabbitmqctl stop_app

        service rabbitmq-server stop

        rabbitmqctl stop_app command

        rm -rf /var/lib/rabbitmq/mnesia/

        service rabbitmq-server start

        rabbitmqctl start_app

  4. In the RabbitMQ dashboards for the central and regional microservices VMs, confirm that all the available infrastructure nodes are present in the cluster.

  [CXU-12107]

• Data in the Maria database instances of a cluster mode can go out of sync when a central Infrastructure fails.

  Workaround: You must manually synchronize the Maria database instances. Contact Juniper Technical Support for instructions. [CXU-13128]

• In an HA deployment, when one of the central infrastructure hosts goes down, the SD-WAN workflow fails.

  Workaround: Contact Juniper Technical Support. [CXU-16273]

• CSO may not come up after a power failure.

  Workaround: Contact Juniper Technical Support. [CXU-16530]

• Data in Maria DB instances in cluster mode may go out of sync upon central infrastructure failures.

  Workaround: You must manually synchronize the Maria DB instances. Contact Juniper Technical Support for instructions. [CXU-13128’

• In HA deployment, when one of the central infrastructure host is down, SD-WAN workflows fail.

  Workaround: Contact Juniper Technical Support. [CXU-16273]

• Sometimes CSO may not come up after power failure.

  Workaround: Contact Juniper Technical Support. [CXU-16530]

• In a HA setup, the time configured for the CAN VMs might not be synchronized with the time configured for the other VMs in the setup. This can cause issues in the throughput graphs.

  Procedure

  Workaround:

  1. Log in to can-vm1 as root.
  2. Modify the /etc/ntp.conf file to point to the desired NTP server.
  3. Restart the NTP process.

  After the NTP process restarts successfully, can-vm2 and can-vm3 automatically re-synchronize their times with can-vm1.

  [CXU-15681]

• The WAN link status does not change in the Site Management page of the Administration Portal when there are Link Up and LInk Down alarms.

  Workaround: Use the Monitor > Alerts & Alarms > Alerts windows to check the status of the WAN links. [CXU-16636]

• Automatic Policy deployments on new Site addition (for example, auto NAT, firewall, SD-WAN) can sometimes fail due to trusted certificate installations on the device happening in parallel.

  Workaround: To redeploy the failed job, open the Configuration > Deployments > History window, select the failed job and click Re-Deploy. [CXU-16652]

• If you create a firewall policy and deploy it to the device, and subsequently create one or more firewall policy intents without re-deploying the policy, the firewall policy is automatically deployed to the device when there's a change in the topology, such as the addition of a new site, department, or LAN segment.

  Workaround: Create firewall policy intents when you intend to deploy them to the device and re-deploy the policy. [CXU-15794]

• ZTP for SRX Series devices will not work with a redirect server because a BOOTSTRAP complete message is not received when ZTP is initiated through a redirect server.

  Workaround: Use a CSO regional server instead of a redirect server for CPE activation. [CXU-14099]

• ZTP fails on SRX 3xx Series device CPE because DHCP bindings already exist on CPE.

  Workaround: Manually clear the DHCP bindings on the CPE and restart ZTP. [CXU-13446]

• The tenant delete operation fails when CSO is installed with an external Keystone.

  Workaround: You must manually delete the tenant from the Contrail OpenStack user interface. [CXU-9070]

• When both the OAM and data interfaces are untagged, ZTP fails when using a NFX Series platform as CPE.

  Workaround: Use tagged interfaces for both OAM and data. [CXU-15084]

• When configuring the SRX spoke in the multihoming topology with a cloud hub and enterprise hub, the administration portal displays a Primary Hub and Secondary Hub must belong to a same Device Familyerror message.

  Workaround: Click OK to dismiss this error. You can ignore this error message. [CXU-16662]

• Site-to-site traffic in the reverse direction in the hub-spoke topology, it may not take the desired path from the hub to the originating spoke.

  Workaround: None. [CXU-16070]

• Sorting by Administrator in the tenant page displays an error message.

  Workaround: This is an invalid error message. Click OK to continue. [CXU-16642]

• If sites are removed without first undeploying the associated policies, the removal of SLA profiles fails.

  Workaround: Delete and deploy all the associated SD-WAN policies before removing sites. [CXU-13179]

• If you create a report definition that is scheduled to run at a later date and time, the report is not generated.

  Workaround: Modify the report definition to run the report immediately and then generate the report. [CXU-11677]

• If you create VNF instances in the Contrail cloud by using Heat Version 2.0 APIs, a timeout error occurs after 120 instances are created.

  Workaround: Please contact Juniper Technical Support. [CXU-15033]