Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 

Known Behavior

This section lists known behavior, system maximums, and limitations in hardware and software in Juniper Networks CSO Release 3.3.

AWS Spoke Site

  • The AWS device activation process takes up to 30 minutes. If the process does not complete in 30 minutes, a timeout might occur and you must retry the process. You need not download the cloud formation template again.

    To retry the process:

    1. Log in to the Customer Portal.
    2. Access the Activate Device page, enter the activation code, and click Next.
    3. After the CREATE_COMPLETE message is displayed on the AWS server, click Next on the Activate Device page to proceed with device activation.
  • When an AWS spoke site is being provisioned, a new route table is included to forward traffic to the vSRX device (running on the NFX Series device). The new route table includes the private subnet details of the existing customer. When the vSRX device is coming up, all traffic is stopped for at least 16 to 30 minutes. Once the device is activated and if the customer has configured intent-based policies, the traffic flows as configured.
  • The cloud formation template includes a new route table to forward traffic to the vSRX device. If you have configured manual routing between your subnets and VMs, then the new route table replaces the manual routing with only one route forwarding the traffic to the vSRX device.
  • When you create a cloud spoke site, the default links and backup link fields are not applicable.

Application Visiblity

  • Application Visibility data is displayed only when there is at least one SD-WAN policy configured on the SD-WAN CPE.


  • Deployments where CSO is behind NAT require spokes and hubs to be able to reach the VRR without NAT.
  • For SD-WAN deployments, CPE behind NAT is not supported.
  • If the Kubernetes minion node in the central or regional microservices VM goes down, the pods on the minion node are moved to the Kubernetes master node. When you bring the minion node back up, the pods do not automatically rebalance across the nodes.
  • In CSO Release 3.3, the virtual machine (VM) on which the virtual route reflector (VRR) is installed supports only one management interface.
  • Before upgrading vSRX by using CSO, execute the request system storage cleanup command on the vSRX by using Junos OS CLI.

Policy Deployment

  • The deployment of fiirewall policies with UTM profiles fails on sites (devices) on which UTM licenses are not present. Ensure that you install the required licenses before deploying firewall policies that are associated with UTM profiles.

    In addition, when you add new sites or departments, firewall policies that are automatically deployed to the sites might fail if licenses are not installed. In such cases, install the licenses on the applicable sites and re-deploy the failed policy.

  • After ZTP of SD-WAN CPE, you must install APBR licenses and app signatures prior to deploying SD-WAN policies through the administrator portal GUI .
  • An SD-WAN policy deployment is successful even if there is no matching WAN link meeting the SLA. This is expected behavior and is done so that when a WAN link matching the SLA becomes available, traffic is routed through that link.
  • When you are creating an SLA Profile and want to specify the advanced configuration, then you must specify maximum upstream rate, maximum upstream burst size, maximum downstream rate and maximum downstream burst size.

Security Management

  • In CSO Release 3.3, intrusion prevention system (IPS) is not supported. Therefore, in the IPS report, the attack name from the IPS signatures is displayed as UNKNOWN.
  • In CSO Release 3.3, SSL Proxy is not supported on SRX300 and SRX320 series devices.
  • Firewall rules are pushed to the device depending on the order in which the firewall policy intents are resolved.

Site and Tenant Workflow

  • In the Configure Site workflow, use IP addresses instead of hostnames for the NTP server configuration.
  • CSO uses hostname-based certificates for device activation. The regional microservices VM hostname must be resolvable from CPE.
  • You can use the Administration Portal to upload licenses to CSO; however, you cannot use the Administration Portal to install licenses on physical or virtual devices that CSO manages. You must use the APIs or the license installation tool to install licenses on devices.
  • CSO uses RSA key based authentication when establishing an SSH connection to a managed CPE device. The authentication process requires that the device has a configured root password, and you can use the Administration Portal to specify the root password in the device template.

    To specify a root password for the device:

    1. Log in to the Administration Portal.
    2. Select Resources>Device Templates.
    3. Select the device template and click Edit.
    4. Specify the encrypted value for the root password in the ENC_ROOT_PASSWORD field.
    5. Click Save.
  • In CSO Release 3.3, when you try to deploy a LAN segment on an SRX Series spoke device, the CSO GUI allows you to select more than one port for a LAN segment. However, for SRX Series devices, only one port for a LAN segment can be deployed; multiple ports in a LAN segment can be deployed only on NFX Seriesdevices.
  • Tenant Administrator users cannot delete sites.
  • On a site with an NFX Series device, if you deploy a LAN segment without the VLAN ID specified, CSO uses an internal VLAN ID meant for internal operations and this VLAN ID is displayed in the UI. There is no impact on the functionality.
  • Site names across tenants must be unique, that is, you cannot use the same site name across tenants.
  • In rare cases, site routes are not advertised to the hub, which results in the sites not being reachable.

    Workaround: Delete the LAN segments for the sites that are not reachable and add the LAN segments again.


  • Changing the DHCP IP address on the OAM interface is not supported.
  • Hybrid-WAN and SD-WAN deployments using the same MX as a hub is not supported.
  • When using MX as a SD-WAN hub, NAT configuration must be done on MX Series routers using Stage-2 configuration templates.
  • DHCP configuration on WAN links on a SD-WAN hub is not supported.
  • CSO Release 3.3 does not support automatic hub-meshing. Hub-meshing must be performed manually in order for traffic to flow between the hubs.
  • IP addresses of the first two WAN interfaces of a site that is part of a full mesh topology deployment cannot be changed once it is provisioned.
  • The preferred link for the underlay is not displayed in the GUI.

User Interface

  • When you use Mozilla Firefox to access the CSO GUIs, a few pages do not work as expected. We recommend that you use Google Chrome version 60 or later to access the CSO GUIs.


  • In CSO Release 3.3, when you edit a tenant, changing the deployment plan from Hybrid WAN to SD-WAN or vice versa is not supported, although the field is displayed as editable.
  • For a centralized deployment, use the following procedure to check that the JSM Heat resource is available in Contrail OpenStack on the Contrail Controller node.

    Note: This procedure must be performed on all the Contrail Controller nodes in your CSO installation.

    1. Log in to the Contrail Controller node as root.
    2. To check whether the JSM Heat resource is available, execute the heat resource-type-list | grep JSM command.

      If the search returns the text OS::JSM::Get Flavor, the file is available in Contrail OpenStack.

    3. If the file is missing, do the following:
      1. Use Secure Copy Protocol (SCP) to copy the file to the following directory:
        • For Heat V1 APIs, the /usr/lib/python2.7/dist-packages/contrail_heat/resources directory on the Contrail Controller node.
        • For Heat V2 APIs, the /usr/lib/python2.7/dist-packages/vnc_api/gen/heat/resources directory on the Contrail Controller node.

        Note: The file is located in the /root/Contrail_Service_Orchestration_3.3/scripts directory on the VM or server on which you installed CSO.

      2. Rename the file to in the Heat resource directory to which you copied the file.
      3. Restart the Heat services by executing the service heat-api restart && service heat-api-cfn restart && service heat-engine restart command.
      4. After the services restart successfully, verify that the JSM Heat resource is available as explained in Step 2. If it is not available, repeat Step 3.
  • In vCPE deployments, when a tenant object is created through Administration Portal or the API for a centralized deployment, ContrailOpenStackadds a default security group for the new tenant. This default security group denies inbound traffic and you must manually update the security group in Contrail OpenStack to allow ingress traffic from different networks. Otherwise, Contrail OpenStack might drop traffic.
  • In vCPE deployments, CSO does not provide a remote procedure call (RPC) to get the device identifier for a specific site. You can use multiple API calls or the license installation tool to obtain the device identifier for a specific site.
  • From CSO Release 3.3, the Silver Peak VX VNF is not supported.
  • After you successfully upgrade from CSO Release 3.2.1 to Contrail Service Orchestration (CSO) Release 3.3, ensure that you download the application signatures before installing signatures on the device. This is a one-time operation after the upgrade.

Modified: 2018-03-29