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

  • Administration portal fails to load when the internet connection is slow.

    Workaround: Append ?debug=true to the administration portal URL. [CXU-16873]

  • On DHCP-enabled internet links, signature download fails during Zero Touch Provisioning of spoke devices.

    Workaround: Install a static route on spoke devices to enable direct download of signature files. [CXU-16558]

  • When you delete a site, the SLA profile associated with the site does not get deleted even though the profile is not associated with any other site. This problem occurs if the corresponding SD-WAN policy is not deployed after the associated rules are deleted.

    Workaround: To delete an SLA profile when you delete the only site associated with the profile, ensure that you delete the rules associated with the corresponding SD-WAN policy and deploy the policy before you delete the site associated with the profile. [CXU-13179]

  • Zero Touch Provisioning of a device fails when the management-only interface is VLAN tagged.

    Workaround: Use untagged management interfaces, or use the oam-and-data interface for all control traffic. [CXU-13375]

  • 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 log in to the CSO GUI for two hours (the configured keystone timeout). This is because of an issue with the synchronization of the MySQL token.

    Workaround: Restart the central infrastructure VM central-infra-vm1. Restarting the VM resynchronizes the MySQL token. Users will then be able to log in to the CSO GUI. [CXU-13541]

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

  • 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.4, 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]

  • During the CSO installation, if you specify that CSO is behind NAT, the deployment fails.

    Workaround: [CXU-12120]

  • 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. An attempt to redeploy the same configuration can cause problems. A sample LAN segment configuration is shown below:
    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

    Workaround: To redeploy the same configuration, first delete the LAN segment configuration from the cloud hub by using the Junos OS CLI, and then redeploy the configuration. A sample delete command is shown below:

    delete groups srx-hub-static-Clouldhub_DefaultVPN-1.4.20.14 routing-options static route192.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 multiple spoke devices, which share a common hub device, at the same time, then in some cases, the activation fails.

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

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

    Workaround: Do the following:

    1. Destroy the corrupted VRR by executing the virsh destroy vrr command from the KVM console.
    2. Delete the image file (/var/lib/libvirt/images/vrr.img) of the corrupted VRR from the physical server.
    3. Copy the VRR image file (vrr.img) packaged with your CSO installation from the server or VM on which you installed CSO to the /var/lib/libvirt/images/directory on the physical server.
    4. Start the VRR by executing the virsh start vrr command from the KVM console.
    5. Load the base configuration of the VRR and modify the IP address of the VRR and the regional microservices VM. A sample configuration is shown below.
      set system root-authentication encrypted-password "$ABC123"
      set system services ssh
      set system services telnet
      set system services netconf ssh
      set system syslog user * any emergency
      set system syslog file messages any notice
      set system syslog file messages authorization info
      set system syslog file interactive-commands interactive-commands any
      set interfaces em0 unit 0 family inet address 192.0.2.6/24
      set interfaces em0 unit 0 family mpls
      set routing-options rib inet.3 static route 0.0.0.0/0 discard
      set routing-options static route 0.0.0.0/0 next-hop 192.0.2.1
      set groups vrr-base-config system host-name vrr-192.0.2.6
      set groups vrr-base-config system services ssh
      set groups vrr-base-config system services telnet
      set groups vrr-base-config system syslog user * any emergency
      set groups vrr-base-config system syslog file messages any notice
      set groups vrr-base-config system syslog file messages authorization info
      set groups vrr-base-config system syslog file interactive-commands interactive-commands any
      set groups vrr-base-config routing-options autonomous-system 64512
      set groups vrr-base-config protocols bgp hold-time 65535
      set groups vrr-base-config protocols bgp group ibgp type internal
      set groups vrr-base-config protocols bgp group ibgp local-address 192.0.2.6
      set groups vrr-base-config protocols bgp group ibgp family inet-vpn unicast
      set groups vrr-base-config protocols bgp group ibgp cluster 192.0.2.6
      set apply-groups vrr-base-config
      
    6. Create a dummy tenant by using the CSO GUI.

      CSO pushes the configuration to the new VRR including the previously configured tenants and sites, and the network is restored.

    [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.4 to use an external keystone, tenants created in the external keystone (without using the CSO GUI) are visible in the scope switcher in 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, which results in a failure in pushing the configuration to the device through CSO. This issue is caused by the event-options configuration.

    Workaround: Log in to the spoke device, and use the Junos OS CLI to remove the event-options configuration in the spoke by executing the following commands:

    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]

  • 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 the last LAN segment for the department (referenced in the policy) and redeploy the firewall policy, then a deployment error occurs. If you modify the firewall policy intent to remove the department and then 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, redeploy the firewall policy; after the deployment is successful, 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 the 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 an HA setup, after a central microservices VM fails over, the Tenant, Site, and Service Manager (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 an 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]

  • In an HA setup, with three 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 an HA setup, the time configured for the Contrail Analytics Node (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 the root user.
    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 try to create a tenant and the tenant creation fails, retrying the creation of the same tenant fails and the following error message is displayed: 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: None. However, this issue does not occur after the job services re-establish the connection to the RabbitMQ server. [CXU-15844]

  • If you provision an SRX300 CPE device by using ZTP, deploy a firewall policy, and then perform the steps to configure and 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]

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

    Workaround: None. [CXU-16162]

  • In an 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 sometimes fails.

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

  • In an AWS HAProxy setup, after the HAProxy master goes down, the backup HA takes over as the master and the CSO GUI is reachable within two minutes. However, in some cases, workflows triggered after the switchover do not progress up to 30 minutes.

    Workaround: None [CXU-16828]

  • In an AWS HAProxy setup, when the master HAProxy node goes down, the backup HAProxy node takes over as the master and services requests. However, when the HAProxy node that was down comes back up, it regains the mastership, causing another mastership switch.

    Workaround: None. [CXU-16829]

  • If you upload a large image file (size greater than 500 MB) in an AWS setup hosted in the Ireland region, the image upload operation times out.

    Workaround:

    1. If you are uploading an image not packaged with the CSO installation, upload the image to Amazon S3 storage; otherwise proceed to the next step.
    2. Use the curl command to upload the file.

    [CXU-16833]

  • 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: 2018-02-12