The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes Cisco's Customer Experience (CX) Cloud Agent. Cisco's (CX) Cloud Agent is a modernized modular on-premise software platform that hosts lightweight containerized microservice capabilities. These capabilities can be installed, configured, and managed on customer premise from the cloud. CX Cloud Agent expedites the monetization of new offers, scales capabilities, and helps to develop next-generation services driven by big data, analytics, automation, Machine Learning/Artificial Intelligence (ML/AI), and streaming.
Note: This guide is intended for CX Cloud Agent v2.0 users. Please refer to the Cisco CX Cloud Agent for other related information.
CX Cloud Agent Architecture
Note: Images (and the content within) in this guide are for reference purpose only. Actual content can vary.
CX Cloud Agent runs as a Virtual Machine (VM) and is available for download as an Open Virtual Appliance (OVA) or a Virtual Hard Disk (VHD).
Requirements to deploy:
Other notes on CX Cloud Agent:
To start the CX Cloud journey, users require access to these domains.
Major Domains |
Other Domains |
cisco.com |
mixpanel.com |
csco.cloud |
cloudfront.net |
split.io |
eum-appdynamics.com |
appdynamics.com |
|
tiqcdn.com |
|
jquery.com |
Domains specific to region:
AMERICAS |
EMEA |
APJC |
cloudsso.cisco.com |
cloudsso.cisco.com |
cloudsso.cisco.com |
api-cx.cisco.com |
api-cx.cisco.com |
api-cx.cisco.com |
agent.us.csco.cloud |
agent.us.csco.cloud |
agent.us.csco.cloud |
ng.acs.agent.us.csco.cloud |
agent.emea.csco.cloud |
agent.apjc.csco.cloud |
ng.acs.agent.emea.csco.cloud |
ng.acs.agent.apjc.csco.cloud |
The prerequisites outlined in this section must be met prior to the upgrade to CX Cloud Agent v2.0.
Exit
.Note: Versions prior to 1.10 must upgrade to v1.10 first, followed by incremental upgrades to v1.12.x, and then to v2.0. Users can upgrade from Admin Settings > Data Sources in CX Cloud portal. Click View Update
to complete the upgrade.
Following conditions to be met for successful setup:
Certified single node and HA Cluster Cisco DNA Center versions are from 1.2.8 to 1.3.3.9 and 2.1.2.0 to 2.2.3.5.
Multi-Node HA Cluster Cisco DNA Center
For the best experience on Cisco.com, we recommend the latest official release of the these browsers:
To deploy CX Cloud Agent:
Campus Network
and navigate to ASSETS & COVERAGE
tile.Note: Images (and the content within) in this guide are for reference purpose only. Actual content can vary.
5. Click Continue. The Set Up CX Cloud Agent - Accept the strong encryption agreement window opens.
6. Verify the pre-populated information in the First Name,Last Name,E-mail, and CCO User Id fields.
7. Select the appropriate Business division’s function.
8. Select the Confirmation
check box to agree to the usage conditions.
9. Click Continue. The Set Up CX Cloud Agent - Download image file window opens.
10. Select the appropriate file format to download the image file required for installation.
11. Select the I accept check box to agree to the Cisco End User License Agreement.
12. Click Download and Continue. The Set Up CX Cloud Agent - Deploy and pair with your virtual machine window opens.
13. Refer to Network Configuration for OVA installation and continue to the next section to install the CX Cloud Agent.
3. Enter data and click Connect This Data Source. The confirmation message “Successfully Connected“ displays.
Note: Click Add Another Cisco DNA Center
to add multiple DNACs.
4. Click Done Connecting Data Sources. The Data Sources window opens.
Any of the these options can be selected to deploy the CX Cloud Agent:
This client allows the deployment of CX Cloud Agent OVA by use of the vSphere thick client.
File > Deploy OVF Template.
Next
.OVF Details
and click Next
.Unique Name
and click Next
.Disk Format
and click Next
(Thin Provision is recommended).Power on after deployment
checkbox and click Finish
.This client deploys CX Cloud Agent OVA by use of the vSphere web.
Virtual Machine > Create / Register VM
.Deploy a virtual machine from an OVF or OVA file
and click Next
.Next
.Standard Storage
and click Next
.Next
.Finish
.Console > Open browser console
.Hosts and Clusters
.Action > Deploy OVF Template
.Next
.Next
.Next
.Next
.Next
.Next
.Finish
.This client deploys CX Cloud Agent OVA though the Oracle Virtual Box.
Oracle VM
File
> Import Appliance
.Import
.Start
.Import Virtual Machine
.Next
.Next
.Copy the virtual machine (create a new unique ID)
radio button and click Next
.Next
.Next
.Finish
.Virtual Switch
from the drop-down.Connect
to start the VM.
VM Console
Set Password
to add a new password for cxcadmin OR click Auto Generate Password
to get a new password.Set Password
is selected, enter the password for cxcadmin and confirm it. Click Set Password
and go to Step 3.OR If Auto Generate Password
is selected, copy the password generated and store it for future use. Click Save Password
and go to Step 4.
Save Password
to use it for authentication.IP Address
, Subnet Mask
, Gateway
, and DNS Server
and click Continue
.Yes,
Continue
.Yes,
Set Up Proxy
or click No, Continue to Configuration
to complete the configuration and go to Step 8.Proxy Address
, Port Number
, Username
, and Password
.Begin Configuration
. The configuration can take several minutes to complete.Pairing Code
and return to CX Cloud to continue the setup.
Pairing Code
10. If the Pairing Code expires, click Register to CX Cloud
to obtain the code again.
Code Expired
11. Click OK
.
Registration Successful
12. Return to the Connecting CX Cloud Agent to CX Cloud section and perform the listed steps.
Users can also generate a pairing code by using CLI options.
To generate a pairing code through the use of CLI:
Pairing Code
and return to CX Cloud to continue the setup. For more information, refer to Connecting to Customer Portal.Supported Cisco DNA Center versions are from 1.2.8 to 1.3.3.9 and from 2.1.2.0 to 2.2.3.5.
To configure Syslog Forwarding to CX Cloud Agent in Cisco DNA Center using UI, perform these steps:
Design
> Network Settings
> Network
.Notes:
- Once configured, all devices associated with that site are configured to send syslog with level critical to CX Cloud Agent.
- Devices must be associated to a site for enabling the syslog forwarding from the device to CX Cloud Agent.
- When a syslog server setting is updated, all devices associated with that site are automatically set to default critical level.
To make Syslog Information level visible, perform the these steps:
Tools
>
Telemetry
.
Tools Menu
2. Select and expand the Site View
and select a site from site hierarchy.
Site View
3. Select the required site and select all devices using the Device name
check box.
4. From the Actions
drop-down, select Optimal Visibility
.
Actions
CX Cloud Agent assures the customer of end-to-end security. The connection between CX Cloud and CX Cloud Agent is encrypted. CX Cloud Agent's Secure Socket Shell (SSH) supports 11 different ciphers.
Deploy CX Cloud Agent OVA image in a secured VMware server firm. The OVA is shared securely through Cisco software download center. Bootloader (single user mode) password is set with a randomly unique password. Users must refer to FAQ to set this bootloader (single-user mode) password.
CX Cloud users can only get authentication and access the Cloud Agent APIs.
On deployment, the cxcadmin user account is created. Users are forced to set a password during the initial configuration. cxcadmin user/credentials are used to access both the CX Cloud Agent APIs and to connect the appliance over SSH.
The cxcadmin user has restricted access with the least privileges. The cxcadmin password follows the security policy and is one-way hashed with an expiry period of 90 days. The cxcadmin user can create a cxcroot user using the utility called remoteaccount. The cxcroot user can gain root privileges. Passphrase expires in two days.
The CX Cloud Agent VM can be accessed using ssh with cxcadmin user credentials. Incoming ports are restricted to 22 (SSH), 514(Syslog).
Password based authentication: Appliance maintains a single user - ‘cxcadmin’ which enables the user to authenticate and communicate with the CX Cloud Agent.
cxcadmin user can create cxcroot user, using a utility called remoteaccount. This utility displays an RSA/ECB/PKCS1v1_5 encrypted password which can be decrypted only from SWIM portal (https://swims.cisco.com/abraxas/decrypt). Only authorized personnel have access to this portal. cxcroot user can gain root privileges using this decrypted password. Passphrase is valid only for two days. cxcadmin user needs to recreate the account and get the password from SWIM portal post password expiry.
CX Cloud Agent appliance follows CIS hardening standards.
CX Cloud Agent appliance does not store any customer personal information.
Device credential application (running as one of the pods) stores encrypted Cisco DNA Center server credentials inside secured database. Cisco DNA Center collected data is not stored in any form inside the appliance. The data collected is uploaded to the backed soon after the collection is complete, and the data is purged from the agent.
The registration package contains the required unique X.509 device certificate and keys to establish secure connection with Iot Core. Using that agent establishes a secure connection using MQTT over TLS v1.2
Logs do not contain any form of sensitive information. Audit logs capture all security-sensitive actions performed on the CX Cloud Agent appliance.
Security Features |
Description |
Bootloader Password |
Bootloader (Single user mode) password is set with a randomly unique password. User must refer FAQ to set his bootloader (single user mode) password. |
User Access |
SSH:
|
User Accounts |
|
cxcadmin password policy |
|
cxcroot password policy |
|
ssh login password policy |
|
Ports |
Open Incoming Ports – 514(Syslog) and 22 (SSH) |
Data Security |
No Customer information stored. No Device data stored. Cisco DNA Center server credentials encrypted and stored in the database. |
Q - With "Re-install" option, can the user deploy the new Cloud Agent with new IP Address?
A - Yes
Q - What are the available file formats for installation?
A - OVA and VHD
Q - What is the environment on which the installable can be deployed?
A - OVA
VMWare ESXi version 5.5 or later
Oracle Virtual Box 5.2.30 or later
VHD
Windows Hypervisor 2012 to 2016
Q - Can CX Cloud Agent detect IP address in a DHCP environment?
A - Yes, in case of DHCP environment, the IP address assignment during IP configuration is taken care. However, the IP address change expected for the CX Cloud Agent at any point in future is not supported. Also, the customer is recommended to reserve the IP for the Cloud Agent in their DHCP environment.
Q - Does CX Cloud Agent support both IPv4 and IPv6 configuration?
A - No, only IPV4 is supported.
Q - During IP configuration, is IP address validated?
A - Yes, IP address syntax and duplicate IP address assignment will be validated.
Q - What is the approximate time taken for the OVA deployment and IP configuration?
A - The OVA deployment depends on the speed of the network to copy the data. The IP configuration takes approximately 8-10 minutes that includes Kubernetes and container creations.
Q - Is there any limitation with respect to any hardware type?
A - The host machine on which OVA is deployed must meet the requirements provided as part of the CX portal setup. The CX Cloud Agent is tested with VMware/Virtual box running on a hardware with Intel Xeon E5 processors with vCPU to CPU ratio set at 2:1. If a less powerful processor CPU or larger ratio is used, the performance can degrade.
Q - Can we generate the pairing code anytime?
A - No, the pairing code can be generated only if the Cloud Agent is not registered.
Q - What are the bandwidth requirements between DNACs (for upto 10 clusters or 20 non-clusters) and Agent?
A -The bandwidth is not a constraint when the Agent and DNAC are in the same LAN/WAN network in the customer environment. The minimum required network bandwidth is 2.7 Mbits/sec for inventory collections of 5000 devices +13000 Access Points for an Agent to DNAC connection. If syslogs are collected for L2 insights, minimum required bandwidth is 3.5 Mbits/sec covers for 5000 devices +13000 Access Points for inventory, 5000 devices syslogs and 2000 devices for scans - all run in parallel from Agent.
Q - What are the different kinds of versions listed for the upgrade of CX Cloud Agent?
A - Shown here are the set of the released versions of CX Cloud Agent that are listed:
where A is a long-term release spread across 3-5 years span.
Q - Where to find the latest released CX Cloud Agent version and how to upgrade the existing CX Cloud Agent?
A - Go to Admin Settings
> Data Sources
. Click the View Update
and perform the instructions shared on screen.
Q - What is the default user of the CX Cloud Agent Application?
A - cxcadmin
Q - How is the password set for the default user?
A - Password is set during network configuration.
Q - Is there any option available to reset the password after Day-0?
A - No specific option is provided by the agent to reset the password, but you can use the linux commands to reset the password for cxcadmin.
Q - What are the password policies to configure CX Cloud Agent?
A - Password policies are:
Q - How to set Grub password?
A - To set the Grub Password, perform these steps:
Q - What is the expiry period for password of cxcadmin
?
A - The password expiry in 90 days.
Q - Does the system disable the account after consecutive unsuccessful login attempts?
A - Yes, the account gets disabled after 5 consecutive unsuccessful attempts. The lockout period is 30 minutes.
Q - How to generate passphrase?
A - Perform these steps,
Q - Does proxy host support both hostname and IP?
A - Yes, but to use hostname, user must provide the DNS IP during network configuration.
Q - What are the ciphers supported by ssh shell?
A - chacha20-poly1305@openssh.com, aes256-gcm@openssh.com, aes128-gcm@openssh.com , aes256-ctr, aes192-ctr, aes128-ctr
Q - How to login to console?
A - Follow the steps to login:
Q - Are SSH logins logged?
A - Yes, they are logged as part of the var/logs/audit/audit.log.
Q - What is the idle session out time?
A - SSH session timeout occurs if the Cloud Agent is idle for five (5) minutes.
Q - What are the ports kept open by default on the CX Cloud Agent?
A - These ports are available:
Outbound port
: The deployed CX Cloud Agent can connect to Cisco backend as indicated in the table on HTTPS port 443 or via a proxy to send data to Cisco. The deployed CX Cloud Agent can connect to Cisco DNA Center on HTTPS port 443..
AMERICAS |
EMEA |
APJC |
cloudsso.cisco.com |
cloudsso.cisco.com |
cloudsso.cisco.com |
api-cx.cisco.com |
api-cx.cisco.com |
api-cx.cisco.com |
agent.us.csco.cloud |
agent.emea.csco.cloud |
agent.apjc.csco.cloud |
ng.acs.agent.us.csco.cloud |
ng.acs.agent.emea.csco.cloud |
ng.acs.agent.apjc.csco.cloud |
Note: In addition to the domains listed, when EMEA or APJC customers reinstall the Cloud Agent, the domain agent.us.csco.cloud must be allowed in the customer firewall.
The domain agent.us.csco.cloud is no longer needed after successful reinstallation.
Note: Ensure that return traffic must be allowed on port 443.
Inbound port
: For local management of the CX Cloud Agent, 514(Syslog) and 22 (ssh) must be accessible. The customer must allow port 443 in their firewall to receive data from CX Cloud.Q - What is the purpose and relationship of Cisco DNA Center with CX Cloud Agent r?
A - Cisco DNA Center is the Cloud Agent that manages the customer premise network devices. CX Cloud Agent collects the inventory information of the devices from the configured Cisco DNA Center and uploads the inventory information that is available as “Asset View” in CX Cloud.
Q - Where can the user provide Cisco DNA Center details on the CX Cloud agent?
A - During the Day 0 - CX Cloud Agent setup, the user can add the Cisco DNA Center details from CX Cloud portal. In addition, during Day N operations, users can add additional DNA Centers from Admin Settings > Data source
.
Q - How many Cisco DNA Centers can be added?
A - Either 10 Cisco DNAC clusters.or 20 DNAC non-clusters.
Q - What role the Cisco DNA Center user can have?
A - The user role can be either admin
or observer
.
Q – How to reflect the modifications in CX Agent due to changes in connected DNA Center credentials?
A - Execute these command from the CX Cloud Agent console:
cxcli agent modifyController
Contact support for any issues during DNAC credentials update.
Q - How are the Cisco DNA Center details stored in CX Cloud Agent?
A - Cisco DNA Center credentials are encrypted using AES-256 and stored in CX Cloud Agent database. CX Cloud Agent database is protected with a secured user ID and password.
Q - What kind of encryption will be used while accessing Cisco DNA Center API from CX Cloud Agent?
A - HTTPS over TLS 1.2 is used for the communication between Cisco DNA Center and CX Cloud Agent.
Q - What are the operations performed by CX Cloud Agent on the integrated Cisco DNA Center Cloud Agent?
A - CX Cloud Agent collects data that Cisco DNA Center has about the network devices and uses the Cisco DNA Center command runner interface to talk to end devices and execute CLI commands (show command). No config change commands are executed
Q - What are default data collected from Cisco DNA Center and uploaded to backend?
A-
Q - What are the additional data collected from Cisco DNA Center and uploaded to Cisco backend?
A - You get all the information here.
Q - How is the inventory data uploaded to backend?
A - CX Cloud Agent uploads the data via TLS 1.2 protocol to Cisco backend server.
Q - What is the frequency of inventory upload?
A - Collection is triggered as per the user-defined schedule and is uploaded to the Cisco backend.
Q - Can the user re-schedule inventory?
A - Yes, an option is available to modify the schedule information from Admin Settings
> Data Sources
.
Q - When does the connection timeout occur between Cisco DNA Center and Cloud Agent?
A - Timeouts are categorizes as follows:
Q - What are the commands executed on the device for scan?
A - Commands that need to be executed on the device for the scan are dynamically determined during the scanning process. The set of commands can change over time, even for the same device (and not in control of Diagnostic Scan).
Q - Where are the scan results stored and profiled?
A - The scanned results are stored and profiled in Cisco backend.
Q - Are the duplicates (By hostname or IP) in Cisco DNA Center, added to Diagnostic Scan when Cisco DNA Center source is plugged in?
A - No, duplicates will be filtered and only the unique devices will be extracted.
Q - What happens when one of the command scans fails?
A - The device scan will be completely stopped and will be marked as unsuccessful.
Q - What health information is sent to the CX Cloud?
A - Application logs, Pod status, Cisco DNA Center details, audit logs, system details, and hardware details.
Q - What system details and hardware details are collected?
A - Sample output:
system_details":{
"os_details":{
"containerRuntimeVersion":"docker://19.3.12",
"kernelVersion":"5.4.0-47-generic",
"kubeProxyVersion":"v1.15.12",
"kubeletVersion":"v1.15.12",
"machineID":"81edd7df1c1145e7bcc1ab4fe778615f",
"operatingSystem":"linux",
"osImage":"Ubuntu 20.04.1 LTS",
"systemUUID":"42002151-4131-2ad8-4443-8682911bdadb"
},
"hardware_details":{
"total_cpu":"8",
"cpu_utilization":"12.5%",
"total_memory":"16007MB",
"free_memory":"9994MB",
"hdd_size":"214G",
"free_hdd_size":"202G"
}
}
}
Q - How is the health data sent to backend?
A - With CX Cloud Agent, the health service (servicability) streams the data to Cisco backend.
Q - What is the CX Cloud Agent’s health data log retention policy in the backend?
A - The CX Cloud Agent’s health data log retention policy in the backend is 120 days.
Q - What are the types of uploads available?
A - Three types of uploads available,
Issue: Not able to access the configured IP.
Solution: Execute ssh using configured IP. If connection times out, the possible reason is IP misconfiguration. In this case, reinstall by configuring a valid IP. This can be done via portal with the reinstall option provided in the Admin Setting
page.
Issue: How to verify if the services are up and running after the registration?
Solution: Execute the command shown here and verify if the pods are up and running.
The pods can be in any state such as running, Initializing, or Container creating but after 20 minutes, the pods must be in running state.
If state is is not running or Pod Initialaizing, check the pod description with the command shown here
kubectl describe pod <podname>
The output will have the information on the pod status.
Issue: How to verify whether SSL Interceptor is disabled at customer Proxy?
Solution: Execute the curl command shown here to verify the server certificate section. The response has the certificate details of concsoweb server.
curl -v --header 'Authorization: Basic xxxxxx' https://concsoweb-prd.cisco.com/
* Server certificate:
* subject: C=US; ST=California; L=San Jose; O=Cisco Systems, Inc.; CN=concsoweb-prd.cisco.com
* start date: Feb 16 11:55:11 2021 GMT
* expire date: Feb 16 12:05:00 2022 GMT
* subjectAltName: host "concsoweb-prd.cisco.com" matched cert's "concsoweb-prd.cisco.com"
* issuer: C=US; O=HydrantID (Avalanche Cloud Corporation); CN=HydrantID SSL CA G3
* SSL certificate verify ok.
> GET / HTTP/1.1
Issue: kubectl commands failed and shows the error as “The connection to the server X.X.X.X:6443 was refused - did you specify the right host or port”
Solution:
Issue: How to get the details of collection failure for a command/device
Solution:
kubectl get pods
and get the collection pod name.kubectl logs <collectionPodName>
to get the command/device specific details.Issue: kubectl command not working with error "[authentication.go:64] Unable to authenticate the request due to an error: [x509: certificate has expired or is not yet valid, x509: certificate has expired or is not yet valid]"
Solution:Run the commands shown here as cxcroot user
rm /var/lib/rancher/k3s/server/tls/dynamic-cert.json
systemctl restart k3s
kubectl --insecure-skip-tls-verify=true delete secret -n kube-system k3s-serving
systemctl restart k3s
Collection failure cause can be any constraints or issues seen with the added controller or devices present in the controller.
The table shown here has the error snippet for use cases seen under the Collection microservice during the collection process.
Use Case | Log Snippet in collection microservice |
---|---|
If the requested device is not found in Cisco DNA Center |
|
If the requested device is not reachable from Cisco DNA Center |
|
If the requested device is not reachable from Cisco DNA Center |
|
If the requested command is not available in device |
|
If the requested device does not have SSHv2 and Cisco DNA Center tries to connect the device with SSHv2 |
|
If command is disabled in Collection microservice |
|
If the Command Runner Task failed and task URL is not returned by Cisco DNA Center |
|
If the Command Runner Task failed to get created in Cisco DNA Center |
|
If the Collection microservice not receiving response for a Command Runner request from Cisco DNA Center |
|
If Cisco DNA Center is not completing the task within the configured timeout (5 mins per command in Collection microservice) |
|
If the Command Runner Task failed and file ID is empty for the submitted task by Cisco DNA Center |
|
If the Command Runner Task failed and file ID tag is not returned by Cisco DNA Center |
|
If the device is not eligible for command runner execution |
|
If the command runner is disabled for the user |
|
Scan failure and the cause can be from any of the listed components
When the user initiates a scan from the portal, occasionally it results as “failed: Internal server error”
The cause for the issue can be any of the listed components
To see the logs:
kubectl get pods
kubectl logs <collectionpodname>
kubectl logs <connector>
kubectl logs <servicability>
The table shown here displays the error snippet seen under Collection microservice and servicability microservice logs that occurs due to the issues/constraints with the components.
Use case | Log snippet in collection microservice |
---|---|
The device can be reachable and supported, but the commands to execute on that device is block-listed on the Collection microservice |
|
If the device which is attempted for scan is not available. Occurs in a scenario, when there is a sync issue between the components such as portal, diagnostic Scan, CX component, and Cisco DNA Center |
|
If the device that is attempted for scan is busy, (in a scenario) where the same device is been part of other job and no parallel requests are handled from Cisco DNA Center for the device. |
|
If the device is not supported for scan |
|
If the device attempted for scan is unreachable |
|
If Cisco DNA Center is not reachable from Cloud Agent or Collection microservice of the Cloud Agent is not receiving response for a Command Runner request from Cisco DNA Center |
|
Use Case | Log snippet in Control Point Agent microservice |
---|---|
If the scan request has schedule details missing |
|
If the scan request has device details missing |
|
If the connection between the CPA and connectivity is down |
|
If the requested device for scan is not available in Diagnostic Scans |
|
Revision | Publish Date | Comments |
---|---|---|
7.0 |
22-Mar-2022 |
Version 2.0 |
6.0 |
21-Oct-2021 |
Minor updates |
5.0 |
08-Oct-2021 |
Minor formatting updates |
4.0 |
08-Oct-2021 |
Minor formatting updates. |
3.0 |
28-Sep-2021 |
Minor formatting |
2.0 |
22-Sep-2021 |
Initial Release |
1.0 |
05-Aug-2021 |
Initial Release |