Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Known Behavior

 

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

AWS Spoke

  • When an AWS spoke site is being provisioned and the vSRX instance is coming up, all traffic from the LAN and WAN subnets (configured during site creation) is stopped for 16–30 minutes. After the device is activated and if intent-based policies are configured, 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.

  • The current supported Junos OS release for the AWS spoke is Junos OS Release 15.1X49.D133. When a new qualified image is posted in AWS marketplace, the procedure to update the Amazon Machine Image (AMI) ID is as follows:

    1. Log in to Administration Portal.
    2. Select Resources > Device Templates.

      The Device Template page appears.

    3. Select vSRX_AWS_SDWAN_Endpoint_option_1.
    4. Select Edit Device Template > Template Settings.

      The Template Settings page appears.

    5. Modify the image ID to the AMI ID for your region.
    6. Click Save.
    7. Proceed with the workflow for the cloud formation template in AWS.
  • When you create a cloud spoke site, the default link fields and backup link fields are not applicable.

Policy Deployment

  • The deployment of firewall 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 an SD-WAN CPE device is activated by using ZTP, you must install APBR licenses and application signatures before deploying SD-WAN policies through the Administration 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.

  • The policy intents defined for a firewall or an SD-WAN policy must not have conflicts with other policy intents in that policy because such conflicts lead to inconsistent behavior. For example:

    • You cannot define an SD-WAN policy with one policy intent for application X and SLA profile S-1 and another policy intent for application X and SLA profile S-2.

    • You cannot define two firewall policy intents with the same source and destination endpoints but one with action Allow and another with action Deny.

SD-WAN

  • If the SD-WAN mode is Real-Time Optimized and a path switch is triggered because a link goes down, sometimes the link switch event displayed in the CSO GUI does not contain the SLA violation metric details.

  • In a full mesh topology, if a site uses the same underlay to connect to a site and a hub, the link score of the overlay between the site and the hub is displayed as poor instead of N/A (not applicable).

  • On the SD-WAN Events page, when you mouse over the Reason field of link switch events, sometimes Above Target is displayed instead of the absolute SLA metric value for very large values (for example, for an SLA metric value that is 100 times the target value).

  • Using unique IP addresses for the OAM and WAN interfaces of an MX Series hub device is not supported. Therefore, ensure that you use the same IP address for the OAM and WAN interfaces for the OAM_AND_DATA link of an MX Series hub device.

Security Management

  • Intrusion prevention system (IPS) is not supported. Therefore, in the IPS report, the attack name from the IPS signatures is displayed as UNKNOWN.

  • 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 the CPE device.

  • 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 Administration Portal to specify the root password in the device template.

    To specify a root password for the device:

    1. Log in to Administration Portal.
    2. Select Resources > Device Templates.
    3. Select the device template and click Edit.
    4. Specify the plain text root password in the ENC_ROOT_PASSWORD field.
    5. Click Save.
  • 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 Series devices.

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

  • CSO does not push the default class-of-service configuration on the hub device. You must configure this configuration manually to ensure that the hub configuration is synchronized with the spoke configuration.

  • On a cloud hub shared by multiple tenants, by default, CSO does not add a default route and no security policies are configured for the traffic to reach the Internet. You must add the default route and the required security policies for the site traffic to reach the Internet through the cloud hub.

  • If you do not use the redirect service from Juniper Networks (redirect.juniper.net), then is not being used, after you upgrade an NFX Series device to Junos OS Release 15.1X53-D473, the device is unable to connect to the regional server because the phone home server certificate (phd-ca.crt) is reverted to the factory default.

    Workaround: Manually copy the regional certificate to the NFX Series device.

Topology

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

  • Automatic hub-meshing is not supported. Hub-meshing must be performed manually in order for traffic to flow between the hubs.

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.

General

  • 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 jsm_contrail_3.py 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 jsm_contrail_3.py file is located in the /root/Contrail_Service_Orchestration_3.3.1/scripts directory on the VM or server on which you installed CSO.

      2. Rename the file to jsm.py 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, Contrail OpenStack adds 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.

  • On an NFX Series device:

    • To activate a virtualized network function (VNF), perform the following steps:

      1. Add the VNF to the device.
      2. Initiate the activation workflow and ensure that the job is 100% completed.
    • To retry the activation of a VNF that failed, perform the following steps:

      1. Deactivate the VNF.
      2. Remove the VNF.
      3. Add the VNF to the device.
      4. Initiate the activation workflow and ensure that the job is 100% completed.
  • Service chaining with 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.1, ensure that you download the application signatures before installing signatures on the device. This is a one-time operation after the upgrade.

  • If you want to roll back CSO Release 3.3.1 to Release 3.3.0 on a CSO setup configured on an ESXi server, to ensure that the rollback process succeeds, perform the following steps:

    1. Log in to the installer VM.
    2. Navigate to the Contrail_Service_Orchestration_3.3.1 folder.
    3. Execute the following commands:

      echo "revert_status:" >> upgrade/upgrade.conf

      echo " revert_vm_snapshot: not_required" >> upgrade/upgrade.conf

      echo " pre_revert_processes: not_required" >> upgrade/upgrade.conf

    4. Initiate the rollback by executing the ./revert.sh script.
  • To upgrade Network Service Controller Release 3.2.1 or Release 3.3.0 to Release 3.3.1, do the following:

    1. Login to installer VM.
    2. Navigate to the Distributed_Cloud_CPE_Network_Service_Controller_3.3.1 folder
    3. Execute the sed -i '8s/Contrail_Service_Orchestration_/Distributed_Cloud_CPE_Network_Service_Controller_/' upgrade/upgrade_ms.py;sed -i '23s@cso_maintenance_enable, upgrade_selective_infra, microservice_upgrade@cso_maintenance_enable,upgrade_selective_infra,micro_services_upgrade@' upgrade/upgrade_compatibility_matrix.conf command.
    4. Initiate the upgrade by executing the ./upgrade.sh script.