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 Issues

This section lists known issues for the Juniper Networks Cloud CPE Solution Release 3.1.2.

  • On an NFX Series device, application tracking is enabled for department security zones only on pushing an SD-WAN APBR policy. When there is only a firewall policy deployed without SD-WAN, no application visibility is displayed for the NFX Series device.

    Workaround: Deploy an SD-WAN APBR policy to enable application visibility on the NFX Series device. [CXU-12154]

  • If the oam-and-data interface goes down, the IBGP session is lost and traffic stops flowing. This causes communication with CSO to be lost and Syslogs are not sent even though there are other WAN interfaces up and running.

    Workaround: None. [CXU-12346]

  • For a site, when DHCP is configured on the WAN interface and the LAN segment, the device activation fails.

    Workaround: None. [CXU-13432]

  • On the Site Management page, the information displayed on the Overlay Links tab for the cloud hub is incorrect.

    Workaround: The correct information is displayed in the WAN tab of the cloud hub. [CXU-13579]

  • If you configure a static SD-WAN policy and a link goes down, it might take approximately three minutes for the gr-0/0/0 interface to be removed from the MPLS/Internet routing table.

    Workaround: None. [CXU-13528]

  • If the central infrastructure VM central-infra-vm2 goes down, users might not be able login to the CSO GUI for two hours (the configured keystone timeout). This is because of an issue with the MySQL token sync.

    Workaround: Restart the central infrastructure VM central-infra-vm1, which will resync the MySQL token. Users will then be able to login to the CSO GUI. [CXU-13541]

  • If you create an SD-WAN and a firewall policy with the source as a department and the department is not associated with a site or a LAN segment, the job created to apply the SD-WAN and firewall policies after ZTP fails.

    Workaround: Associate the department with a site or a LAN segment before performing ZTP. [CXU-13542]

  • For sites with device-initiated connections, by default, all site traffic is source NATted at the hub. You cannot apply a different source NAT rule to the hub because the default rule overrides any user-configured source NAT rule.

    Workaround: None. [CXU-13558]

  • If you have a tenant with more than one site and deploy a firewall policy to a single site, the policy is deployed only to that site. However, jobs are created to push a dummy firewall policy to other sites, which causes a performance issue on setups with a large number of devices.

    Workaround: None. [CXU-13562]

  • On SRX 3xx Series devices, phone home activation might fail because of a conflict with default configuration on the device.

    Workaround: Copy the stage-1 configuration manually to the device and then trigger the phone home activation workflow. [PR 1312703]

  • If you deploy a NAT policy with one or more rules and then delete the policy without first deleting the rules, the configuration on the device is not cleared.

    Workaround: To delete a NAT policy, first delete all the rules associated with the policy and deploy the policy. After the deployment is successful, delete the NAT policy by using the CSO GUI. [CXU-13879]

  • Link switching does not occur even though the throughput threshold configured in the SLA profile is crossed because incorrect interface stats are reported for the GRE interface.

    Workaround: None. [CXU-14127]

  • Some variables in the NSC installer package do not have the correct values.

    Workaround: After you extract the TAR file for the installation package, do the following

    1. Access the installer directory by executing the cd installer-dir command, where installer-dir is the name of the installer directory.

      The installer directory has the same name as the installer package. For example, if the installation package name is nscVersion.tar.gz, the installer directory is nscVersion.

    2. Execute the following command to specify certain text variables in the installation files:
      sed -i '''s@download_url: http.*/@download_url: http://csp-installer:90/csp_components/@g''' confs/roles_csp.conf;sed -i '''s@build_server_url_pattern: http.*/@build_server_url_pattern: http://csp-installer:90/csp_components/@g''' confs/roles_csp.conf;sed -i '''s@download_url: "http.*/@download_url: "http://csp-installer:90/csp_components/@g''' confs/roles_csp.conf;sed -i '''s@build_server_url_pattern: "http.*/@build_server_url_pattern: "http://csp-installer:90/csp_components/@g''' confs/roles_csp.conf;

      Note: When you copy the command, ensure that you copy it as a single command and remove all extra line spaces.

    You can then use the files and tools in the installer directory to perform operations such as provisioning VMs, creating configuration files, and installing the solution.

    [CXU-14981]

  • The device profile srx-deployment-option-1 assigns OAM traffic to the fxp0 interface, which is not available on the SRX Series Services Gateway.

    Workaround: Edit the stage 1 configuration for the CPE device in Customer Portal to use an interface other than fxp0 for OAM traffic. [CXU-3779]

  • The traffic rate value does not change when you monitor a service on an SRX Series Services Gateway in Administration Portal.

    Workaround: None

    [CXU-3822]

  • The NFX250 device does not receive communications to block unicast reverse path forwarding (uRPF) because two interfaces on the NFX250 device communicate separately with one interface on the regional microservices server.

    Workaround: Disable the uRPF check in JDM on all interfaces for each NFX Series device.

    [CXU-3854]

  • Performance metrics for the NFX Series device are collected through the HTTP interface.

    Workaround: None. [CXU-8710]

  • In the detailed view of a site on the Sites page (Sites > Site Management), the Overlay Links tab displays only GRE links and not GRE over IPsec links.

    Workaround: None. [CXU-10170]

  • On the NAT Rules page, if you try to search or use the column filters for departments named Internet or Corporate Network, the search does not work.

    Workaround: None. [CXU-10406]

  • The Activate Device link is enabled even though activation is in progress.

    Workaround: After clicking the Activate Device link, wait for the activation process to complete; the Activate Device link is disabled after activation completes. [CXU-10760]

  • If one of the CSO infrastructure nodes (virtual machines) fails (shuts down or restarts), the topology service repeatedly sends out the error message “Failed to consume message from queue: 'NoneType' object has no attribute 'itervalues'” to the logs.

    Workaround: After the infrastructure node fails over to the backup node, wait for ten minutes before using any workflows. [CXU-11004]

  • If a user who belongs to more than one tenant is deleted, the user is deleted from all tenants.

    Workaround: None. [CXU-11201]

  • On the Site-Name page (Sites > Site-Name), when you click the Device link (in the Connectivity & Devices box on the Overview tab), you are navigated to the Devices page (Resources > Devices) where all available devices are displayed instead of only the device that you selected.

    Workaround: None. [CXU-11339]

  • If you modify a site group that is not used in any policy, a GUI notification incorrectly indicates that policies need to be deployed.

    Workaround: Deploy the indicated policies on the device. However, because there are no changes to be deployed, the configuration is not deployed. [CXU-11395]

  • If an infrastructure node (virtual machine) goes down, the backup node takes over the tasks handled by the primary node. However, after the node that was down recovers, it does not join the cluster and is stuck in slave mode.

    Workaround: Ensure that both nodes are up before you perform the following tasks:

    1. Log in to the infrastructure node as root.
    2. Open a shell prompt and access the redis CLI by executing the redis-cli -h node-IP-p 6379 -c command, where node-IP is the IP address of the infrastructure node that went down.
    3. At the redis CLI prompt, execute the CLUSTER FAILOVER command.
    4. Execute the INFO command.
    5. In the output, under replication, ensure that the node is displayed as Master.
    6. Exit the redis CLI by executing the QUIT command.
    7. Log out of the infrastructure node.

    [CXU-11711]

  • If you create a LAN segment with the name LAN0, LAN1, or LAN2, the deployment of the LAN segment fails.

    Workaround: Do not use the names LAN0, LAN1, or LAN2 when you create a LAN segment. [CXU-11743]

  • In the device template, if the ZTP_ENABLED and ACTIVATION_CODE_ENABLED flags are set to true, you cannot proceed with device activation.

    Workaround: Set the ZTP_ENABLED flag to true and the ACTIVATION_CODE_ENABLED flag to false before proceeding with device activation. [CXU-11794]

  • When you upgrade the gateway router (GWR) by using the CSO GUI, after the upgrade completes and the gateway router reboots, the gateway router configuration reverts to the base configuration and loses the IPsec configuration added during Zero Touch Provisioning (ZTP).

    Workaround: Before you upgrade the gateway router by using the CSO GUI, ensure that you do the following:

    1. Log in to the Juniper Device Manager (JDM) CLI of the NFX Series device.
    2. Execute the virsh list command to obtain the name of the gateway router (GWR_NAME).
    3. Execute the request virtual-network-functions GWR_NAME restart command, where GWR_NAME is the name of the gateway router obtained in the preceding step.
    4. Wait a few minutes for the gateway router to come back up.
    5. Log out of the JDM CLI.
    6. Proceed with the upgrade of the gateway router by using the CSO GUI.

    [CXU-11823]

  • On rare occasions, the Logspout microservice causes the docker daemon to hog the CPU on the microservices virtual machine.

    Workaround: Restart the Logspout microservice by doing the following:

    1. Log in to the central microservices virtual machine as root.
    2. At the shell prompt, run the kubectl get pod command to find out the name of the Logspout pod.
    3. Restart the pod by executing the kubectl delete pod pod-name command, where pod-name is the name of the Logspout pod.

    [CXU-11863]

  • If you trigger a device activation on the Activate Device page, the status of the activation is displayed based on the progress of the activation steps completed. However, the device activation process takes between 20 and 30 minutes and if you click OK to close the Activate Device page, you cannot go back to the Activate Device page to find out the status.

    Workaround:

    1. Wait for 20 to 30 minutes after you trigger the activation.
    2. On the Sites page, hover over the device icon to see the status:
      • If the device status is PROVISIONED, it means that the activation was successful.
      • If the device status is EXPECTED or PROVISION_FAILED, then the device activation has failed.

        Contact your service provider for further assistance.

    [CXU-11878]

  • When a tunnel goes down, the event generated displays different information for the NFX Series and SRX Series devices:
    • When the GRE over IPsec tunnel goes down:
      • The event generated for the vSRX device (running on the NFX Series device) has the description ['Tunnel-id ID is inactive'].
      • The event generated for the SRX Series device has the description GRE over IPSEC is Down.
    • When the GRE-only tunnel goes down:
      • The event generated for the vSRX device (running on the NFX Series device) has the description tunnel-oam-down.
      • The event generated for the SRX device has the description GRE tunnel down.

    Workaround: None. [CXU-11895]

  • If you try to delete one or more LAN segments, the confirmation dialog box does not display the list of LAN segments selected for deletion. However, when you click OK to confirm the deletion, the LAN segments are deleted successfully.

    Workaround: None. [CXU-11896]

  • If the role of an existing user is changed from MSP Operator to MSP Administrator and that user tries to switch the tenant by using the scope switcher in the banner, the tenant switching fails.

    Workaround: Delete the existing user and add an MSP user with the MSP Administrator role. The new user will be able to perform the tenant switch. [CXU-11898]

  • In Cloud CPE Solution Release 3.1.2, editing a site is not supported. When you try to edit a site, the message "unable to retrieve the router info" is displayed.

    Workaround: Delete the site and add the site again with the modified settings. [CXU-11912]

  • If you edit an existing LAN segment that was previously added during site creation, the Department field is changed to Default.

    Workaround: When you edit a LAN segment, ensure that you select the correct department before saving your changes. [CXU-11914]

  • If you apply an APBR policy on a vSRX device or an SRX Series device, in some cases, the APBR rule is not active on the device.

    Workaround:

    1. Log in to the vSRX or SRX Series device in configuration mode.
    2. Deactivate the APBR policy by executing the delete apply-groups srx-gwr-apbr-policy-config command.
    3. Commit the configuration by executing the commit command.
    4. Activate the APBR policy by executing the set apply-groups srx-gwr-apbr-policy-config command.
    5. Commit the configuration by executing the commit command.
    6. Log out of the device.

    [CXU-11920]

  • On the Monitor > Overview page:
    • The number of hub devices is reported as zero even though a cloud hub exists.

      Workaround: The expanded view displays the correct data.

    • When you collapse and expand the map view, the number of links reported is incorrect.

      Workaround: Refresh the page to display the correct data.

    [CXU-11931]

  • For GRE-over-IPsec overlays, in some cases, the event-options configuration fails to re-enable the gr-0/0/0 interface. As a result, the traffic between the spoke and hub overlay stops flowing even though the overlay is up.

    Workaround: Do the following:

    1. Find out which gr-0/0/0 interfaces are down on the spoke device:
      1. Log in to the spoke device as root.
      2. Execute the show interfaces gr-0/0/0.* terse command.

        An example of the command and output follows:

        user@host> show interfaces gr-0/0/0.* terse
          Interface Admin Link Proto Local Remote
        gr-0/0/0.1 up up inet 192.0.2.1/31
                                           mpls
        gr-0/0/0.2 down up inet 192.0.2.2/31
                                           mpls
        gr-0/0/0.3 up up inet 192.0.2.3/31
                                           mpls
        gr-0/0/0.4 up up inet 192.0.2.4/31
                                           mpls
        gr-0/0/0.5 down up inet 192.0.2.5/31
                                           mpls
        gr-0/0/0.6 up up inet 192.0.2.6/31
                                           mpls
        
    2. For each disabled interface on the spoke, execute the show configuration | display set | match "disable" | match "gr-interface-name unit unit-number" command to find out whether any disabled statements are present in the configuration, where gr-interface-name is the name of the interface and unit-number is the unit number that was obtained in Step 2.

      An example of the command and output follows:

      user@host>show configuration | display set | match "disable" | match "gr-0/0/0 unit 5"
      set groups NFX-5-SPOKE_CPE1_WAN_2_GRE_IPSEC_0 interfaces gr-0/0/0 unit 5 disable
    3. Find out whether there is a problem by doing the following:
      1. Execute the show interfaces st0* terse operational command to find out the status of the IPsec tunnels and the IP addresses:

        An example of the command and output follows:

        user@host> show interfaces st0* terse
        Interface Admin Link Proto Local Remote
        st0 up up
        st0.1 up down inet 192.0.2.7/31
        st0.2 up up inet 192.0.2.8/31  # [IP address match]
        st0.3 up up inet 192.0.2.9/31
        
      2. Execute the show interfaces gr-down-interface-name command, where gr-down-interface-name is the name of the interface that was down (obtained in Step 2).

        Note: You must execute this command for all the interfaces that were down.

        An example of the command and output follows:

        user@host> show interfaces gr-0/0/0.5
          Logical interface gr-0/0/0.5 (Index 139) (SNMP ifIndex 579)
            Flags: Down
        Down Point-To-Point SNMP-Traps 0x4000
        IP-Header 192.0.2.10/31:192.0.2.8/31:47:df:64:0000000000000000  # [IP address match]
        Encapsulation: GRE-NULL
            Gre keepalives configured: Off, Gre keepalives adjacency state: down
            Input packets : 0
            Output packets: 0
            Security: Zone: trust
            Allowed host-inbound traffic : bootp bfd bgp dns dvmrp igmp ldp msdp nhrp
            ospf ospf3 pgm pim rip ripng router-discovery rsvp sap vrrp dhcp finger ftp
            tftp ident-reset http https ike netconf ping reverse-telnet reverse-ssh
            rlogin rpm rsh snmp snmp-trap ssh telnet traceroute xnm-clear-text xnm-ssl
            lsping ntp sip dhcpv6 r2cp webapi-clear-text webapi-ssl tcp-encap
            Protocol inet, MTU: 9168
              Flags: Sendbcast-pkt-to-re
              Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
                Destination: 192.0.2.11/31, Local: 192.0.2.5/31
            Protocol mpls, MTU: 9156, Maximum labels: 3
        
      3. For each IP address obtained in Step a, search the output from Step b for a match. (In the sample outputs, the IP address of the st0.2 interface (192.0.2.8/31) matches the IP address in the IP-Header parameter.)
      4. If the st0 interface corresponding to the matched IP address is up and the corresponding gr-0/0/0 interface is down, then there is a problem with the configuration.
    4. Modify the configuration on the spoke as follows:
      1. Log in to the spoke device as root.
      2. Delete the disabled statements found in Step 3 by executing the delete command. An example is provided below:
        user@host# delete groups NFX-5-SPOKE_CPE1_WAN_2_GRE_IPSEC_0 interfaces gr-0/0/0 unit 5 disable
      3. Commit the configuration by executing the commit command.
    5. Repeat Step 2 through Step 5 for the hub device.
    6. Verify that the links are up by following the procedure in Step 1.

    [CXU-11996]

  • If an SLA profile is defined with only the throughput metric specified, in some cases, the SLA profile is assigned to a link that is down.

    Workaround: In addition to the throughput metric, ensure that you specify at least one more metric (for example, packet loss or latency) for the SLA profile. [CXU-11997]

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

    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:
      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]

  • If you create a site group and add a hub site that references that site group, the creation of the hub site fails.

    Workaround: Add the hub site without using a site group. [CXU-13753]

  • If you delete an existing LAN segment, the configuration related to the LAN segment is not deleted from the cloud hub as shown in the following sample output:
    set groups srx-hub-static-Clouldhub_DefaultVPN-1.4.20.14 routing-options static route 192.0.2.0/24 next-table Default-Clouldhub_DefaultVPN-Clouldhub.inet.0

    This can cause problems if you attempt to redeploy the same configuration.

    Workaround: To redeploy the same configuration, first delete the LAN segment configuration from the cloud hub by using the Junos OS CLI using the following command, and then redeploy the configuration:

    delete groups srx-hub-static-Clouldhub_DefaultVPN-1.4.20.14 routing-options static route 192.0.2.0/24

    [CXU-13812]

  • In some cases, when the activation of a spoke device fails, the UI logs do not display the relevant information.

    Workaround: Access the Kibana logs to view the relevant information. [CXU-13941]

  • If you try to activate spoke devices, which share a common hub device, at the same time, in some cases, the activation fails.

    Workaround: Retry the activation on the spoke devices for which the activation fails and the activation is successful. [CXU-14066]

  • After you restart the physical server that hosts the VRR VM, the VRR VM fails to come back online.

    Workaround: None. [CXU-14922]

  • If you configure a site with Internet breakout, the CSO GUI displays a core attachment point on the Site-Name page. If you try to start a service on the site, an error message is displayed.

    Workaround: None. [CXU-14924]

  • If you configure Cloud CPE Solution Release 3.1.2 to use an external keystone, tenants created in the external keystone (without using the CSO GUI) are visible in the scope switcher in the Administration Portal.

    Workaround: Before using an external keystone for CSO, ensure that it does not contain any data. [CXU-14931]

  • In some scenarios, the configuration database is locked by the CSP user which results in a failure to push the configuration to the device through CSO. This issue is caused by the event-options configuration.

    Workaround: Unconfigure event-options in the spoke using the delete groups VF-SPOKE1_CPE1_WAN_0_GRE_IPSEC_0 event-options command.

    set groups VF-SPOKE1_CPE1_WAN_0_GRE_IPSEC_0 event-options policy VF-SPOKE1_CPE1_WAN_0_GRE_IPSEC_0_down then change-configuration commands "set groups VF-SPOKE1_CPE1_WAN_0_GRE_IPSEC_0 interfaces gr-0/0/0.1 disable"
     set groups VF-SPOKE1_CPE1_WAN_0_GRE_IPSEC_0 event-options policy VF-SPOKE1_CPE1_WAN_0_GRE_IPSEC_0_up then change-configuration commands "delete groups VF-SPOKE1_CPE1_WAN_0_GRE_IPSEC_0 interfaces gr-0/0/0.1 disable"
     set groups VF-SPOKE1_CPE1_WAN_1_GRE_IPSEC_0 event-options policy VF-SPOKE1_CPE1_WAN_1_GRE_IPSEC_0_down then change-configuration commands "set groups VF-SPOKE1_CPE1_WAN_1_GRE_IPSEC_0 interfaces gr-0/0/0.2 disable"
     set groups VF-SPOKE1_CPE1_WAN_1_GRE_IPSEC_0 event-options policy VF-SPOKE1_CPE1_WAN_1_GRE_IPSEC_0_up then change-configuration commands "delete groups VF-SPOKE1_CPE1_WAN_1_GRE_IPSEC_0 interfaces gr-0/0/0.2 disable" 

    [CXU-15025]

  • 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: If you want to create more than 120 instances (up to a maximum of 500 instances), use the Heat Version 1.0 APIs instead. [CXU-15033]

  • For the centralized CPE use case, during the ns-terminate operation (to terminate the VNF), the message 4ca27229-4f0e-3a6e-907f-4ea7706a04e9 exception: es index not present might be present in some logs. However, this does not cause any problems.

    Workaround: None. [CXU-15047]

  • For the centralized CPE use case, during the ns-terminate operation (to terminate the VNF), the message EMS device with id id-number might be present in some logs. However, this does not cause any problems.

    Workaround: None. [CXU-15082]

  • If you create a site, activate the spoke device using ZTP, and create an SD-WAN policy and deploy it on the site, the job is created and runs successfully. However, even though the policy is deployed on the site, the policy is still listed as awaiting deployment in the UI.

    Workaround: None. [CXU-15101]

  • If you deploy a firewall policy with departments (to which LAN segments are linked) and, after the policy is deployed successfully, delete a LAN segment that is last LAN segment for the department (referenced in the policy) and re-deploy the firewall policy, a deployment error occurs. When you modify the firewall policy intent to remove the department and deploy the policy, all the firewall rules are deleted from the device.

    Workaround: Create a LAN segment that is associated with the department referenced in the firewall policy and deploy the LAN segment. After the deployment is successful, re-deploy the firewall policy; on successful deployment, the firewall rules are pushed to the device. [CXU-15138]

  • If you add a tenant but do not add any sites to the tenant and then delete a tenant, error messages are displayed in the Administration Portal GUI. However, the tenant is deleted successfully.

    Workaround: None [CXU-15253]

  • If you activate an NFX Series device from the CSO GUI, the device status does not change from Expected to Activate for approximately 20 minutes.

    Workaround: None [CXU-15282]

  • In a HA setup, after a central microservices VM fails over, the TSSM API server is sluggish in responding to requests.

    Workaround: Wait for two to three minutes and the TSSM API server responds normally. [CXU-15283]

  • In a HA setup, if the central load-balancer VM (as the Virtual Router Redundancy Protocol [VRRP] master) goes down, the switchover takes place in less than a minute and the services run properly with the new VRRP master. However, no jobs are created for approximately 10 minutes.

    Workaround: None. [CXU-15388]

  • The CPU utilization of the Tenant, Site, and Service Manager (TSSM) core microservice might be high in a long-running setup with a large number (greater than 100) of service instances.

    Workaround: Restart the TSSM core Docker containers by deleting the respective pods and the CPU utilization returns to normal. [CXU-15434]

  • In a HA setup, with 3 load-balancer VMs, if the master load-balancer goes down, one of the remaining load-balancer VMs is switched over as the master. However, after the original load-balancer VM comes up, it is switched over as the master again.

    Workaround: None. [CXU-15441]

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

    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]

  • If you activate a spoke device by using ZTP and trigger a recall of the device, the APBR, Class of Service (CoS), and tenant configurations are not deleted from the device.

    Workaround: Before initiating the recall operation, do the following:

    1. Delete the policy intents from the SD-WAN policy.
    2. Deploy the policy to ensure the removal of all APBR- and CoS-related configurations from the device.
    3. After the deployment is successful, initiate the recall operation.

    [CXU-15815]

  • If you try to create a tenant and the tenant creation fails, retrying the tenant creation for the same tenant fails with an error message The resource specified already exists.

    Workaround: None. [CXU-15824]

  • If the central server (hosting the csp-central-msvm3, csp-central-infravm3, and csp-central-lbvm3 VMs) goes down, jobs are displayed twice or thrice.

    Workaround: Workaround: None. However, this issue does not occur once the job services re-establishes the connection to the RabbitMQ server. [CXU-15844]

  • If you provision an SRX300 CPE device by using ZTP, deploy a firewall policy, and then configure an deploy an SD-WAN policy, the SD-WAN policy deployment fails even though the policy is pushed to the device.

    Workaround: None. [CXU-15918]

  • If you create an SD-WAN policy applicable to all sites and deploy the policy on a spoke device, the policy is deployed successfully. When you provision a new spoke device by using ZTP, the deployment of the SD-WAN policy on the new device is triggered automatically. However, the SD-WAN policy deployment fails because of an error in the Central microservices VM.

    Workaround: None. [CXU-15949]

  • In a HA setup, if one of the central servers is restarted, HAProxy reports that the microservices are flapping (disconnecting and reconnecting).

    Workaround: Depending on the location of the restarted server (Central or regional), restart the kubemaster and kubeminions (msvms). [CXU-16161]

  • SLA profile deletion fails. However, the corresponding SD-WAN policies are deleted successfully.

    Workaround: None. [CXU-16162]

  • In a HA setup, if one of the infrastructure microservices VMs goes down and you trigger report generation, reports are not generated.

    Workaround: Ensure that the VM that was down comes back up and then trigger report generation. [CXU-16222]

  • After creating a new spoke site, when you configure and activate the site, site provisioning fails sometimes.

    Workaround: Retry the failed job. [CXU-16349]

  • The throughput graphs in the WAN page of the spoke site might not reflect the actual throughput seen in the CPE interfaces running the vSRX image 15.1X49-D123.2

    Workaround: None. [CXU-16471]

  • When a redirect server is used for ZTP, the ’PHS bootstrap complete’ message is not sent to the CSO regional server, because of which ZTP fails.

    Workaround: None. [PR 1315524]

Modified: 2017-12-13