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

Device Management

  • The SRX4100 and SRX4200 devices supports all existing SD-WAN features, except the following:

    • Phone home client—The CPE devices must be manually activated by copying the stage-1 configuration from the Administration Portal, pasting it to the console of the SRX4100 and SRX4200 devices, and then committing the stage-1 configuration.

    • LTE and xDSL interfaces.

    • Service chaining.

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

Dynamic VPN (DVPN)

  • Creation and deletion of DVPN tunnels based on the DVPN create and delete thresholds are governed by the MAX_DVPN_TUNNELS and MIN_TUNNELS_TO_START_DVPN_DEACTIVATE parameters, respectively. However, MAX_DVPN_TUNNELS and MIN_TUNNELS_TO_START_DVPN_DEACTIVATE are not honored when DVPNs are created or deleted from the CSO UI. This might cause the total active DVPN tunnels count on the Site > WAN tab to show a greater value than the MAX_DVPN_TUNNELS value configured for that site.

  • DVPN create and delete thresholds are based on the APPTRACK_SESSION_CLOSE messages. When APPTRACK_SESSION_CLOSE messages reach the specified threshold, an alarm is generated for creating or deleting a DVPN tunnel. However, the alarms are not cleared until the APPTRACK_SESSION_CLOSE message count goes below the threshold (for create alarms) or above the threshold (for delete alarms) to trigger a fresh cycle. This causes the create and delete alarms to remain active and prevent further alarms and to, thus, slow down the creation or deletion of tunnels.

  • Passive probes created by an SD-WAN policy time out because of inactivity in 60 seconds and causes CSO to close the corresponding sessions and trigger APPTRACK_SESSION_CLOSE messages. The APPTRACK_SESSION_CLOSE messages are tracked by CAN, and are added to the number of sessions closed. The sessions closed count is used to calculate the DVPN delete threshold.

Policy Deployment

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

  • 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

  • Advanced SLA configurations, such as CoS rate limiting, are not supported during local breakout if no specific application is selected; that is, if Application is set to ANY. Choose specific applications if you want to enable advanced SLA configurations, such as CoS rate limiting.

  • If two or more SD-WAN policy rules are configured for the same application with different levels of granularity, such as all, sites, and departments, then CSO applies the CoS rate limiter in the same order in which you have created the intents.

  • Between spoke 1 (attached to the cloud hub) and spoke 2 (attached to the cloud hub and the gateway site), traffic occurs in the following paths:

    • From spoke 1 to spoke 2, forward traffic goes through the cloud hub (to spoke 2) and reverse traffic goes through the gateway site (to spoke 1).

    • From spoke 2 to spoke 1, forward traffic goes through the gateway site (to spoke 1) and the reverse traffic goes through the cloud hub to spoke 2.

  • Default application traffic profile parameters will get modified during CSO upgrade.

  • On the WAN tab of the Site-Name page, the link metrics graph displays aggregated data. Therefore, in cases where the aggregation interval overlaps between source and destination link data, the link metrics graph displays incorrect data.

  • Use breakout profiles to define all types of static SD-WAN policies.

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

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

  • When an SD-WAN policy is deployed and a high rate of traffic flows through the CPE device, this might lead to network congestion and introduce delays or cause traffic. However, even though an SLA violation is reported, the traffic does not switch to a different link.

  • In device redundancy mode, when you reboot a node, the device fails to generate a few system logs. Because a few system logs are not generated, the link switch event in CSO displays the source interface same as the destination interface.

  • Sometimes duplicate link switch events are displayed on the Link Switch Events page.

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.

Site and Tenant Workflow

  • In the Configure Site workflow, use IP addresses instead of hostnames for the NTP server configuration.

  • Ensure that tenants use unique site names so that no two tenants have sites with the same name.

  • Though the tenant creation workflow UI supports negative values for the Max Tunnels per Tenant parameter, always ensure that you use a positive value for the Max Tunnels per Tenant parameter.

  • 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), after you upgrade an NFX Series device to Junos OS Release 15.1X53-D473 or later, 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.

  • If an NFX250 CPE device is pre-staged to use CSO as the phone-home server, bypassing the redirect service from Juniper Networks, you must add the following configuration to prevent the CSO certificate from being overwritten during a reboot:

    set system phone-home ca-certification-file /root/phcd-ca.crt
  • Do not create departments that have names starting with default, default-reverse, mpls, internet, or default-hub because CSO uses the following departments for internal use:

    • Default-vpn_name

    • Default-reverse-vpn_name

    • mpls-vpn_name

    • internet-vpn_name

    • Default-hub-vpn_name

  • Before you onboard a cloud hub with PKI as the VPN authentication method, ensure that the NTP server is configured on the device. After the device is onboarded, add the NTP server details manually on the cloud hub or in the stage-2 configuration.

    Before you do a ste upgrade, ensure that you configure NTP server details on the device manually or in the stage–2 configuration.

Topology

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

  • On-premise hubs are not supported.

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.

  • When you copy and paste a stage–1 configuration from Chrome version 71.0.3578.98, insert a new line, as shown in the following example, in the private key text:

    If you do not insert the new line, the private key fails.

General

  • Installer VM needs to be rebooted after you upgrade CSO to Release 4.1.0.

  • A LAN segment deploy job is handled in two parts in the following sequence:

    1. LAN segment-related policies are deployed.

    2. Firewall policies are deployed.

    However, the deploy job status is updated as soon as the first part is completed. Because of this, a deploy job for a LAN segment is shown as a success even though the associated firewall policy deployment is still in progress.

  • Ensure that you enable port number 443, which is required for phone home services and device activation. Previously, port number 444 was supported for phone home services and device activation.

  • The following are the limitations of doing image upgrade from the Image Landing page:

    • JDM images cannot be upgraded parallely. The upgraded have to be done in a sequence because the connection to CSO gets reestablished when the primary JDM reboots and that affects the upgrade operation of the other JDM.

    • GWR cluster nodes should not be upgraded (neither parallely nor sequentially) from the Image Landing page because the cluster nodes should always run the same version.

    We recommend that you use the Site Upgrade workflow which handles the image upgrade of both JDM and GWR cluster appropriately

  • 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_4.1.0/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.
  • The Ubuntu VNF interface toward the LAN segment of the vSRX gateway router is not automatically provisioned by CSO. You must manually provision the interface as follows:

    • On a LAN segment that does not use a VLAN, execute the ifconfig ens5 ip-prefix command, where ip-prefix is the IP prefix of the LAN subnet.

    • On a LAN segment that uses a VLAN, execute the following commands:

      vconfig add ens5 vlan-id
      ifconfig ens5.vlan-id ip-prefix

      where vlan-id is the VLAN ID of the LAN and ip-prefix is the IP prefix of the LAN subnet.

  • Class-of-service (CoS) configuration on Layer 2 interfaces (ge-0/0/*) is not supported on NFX150 CPE devices.

  • Image upgrade of a vSRX gateway router on NFX Series devices from the Image Landing page is not supported.

    Workaround: Upgrade the image by using the Site Upgrade workflow from the Site Landing Page.

  • In CSO Release 4.0.1, the collection of service metrics is disabled by default for SRX Series and NFX150 devices, so the get_service_metrics API does not return any data.

    To enable the collection of service metrics:

    1. On the infrastructure VM or, if regions are present, the regional infrastructure VM, log in as root and execute the etcdctl set /telemetry-agent/metric_collection ENABLE command.
    2. To restart the telemetry agent microservice:
      • If no regions are present, log in to the microservices VM as root and execute the kubectl delete pods csp.csp-telemetry-agent -n regional command.

      • If regions are present, log in to the regional microservices VM as root and execute the kubectl delete pods csp.csp-telemetry-agent command.

    The collection of service metrics data is enabled, and you can use the get_service_metrics API to obtain the data.

  • LAN routes are not advertised to the neighbor in case of a data center department on a gateway site that uses routing protocols such as BGP or OSPF. In such cases, configure source NAT on the gateway site from the CSO UI or configure reverse routes on the routing device.

  • Overlapping LAN segments are not supported across a CSO installation.