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 includes frequently asked questions and troubleshooting scenarios that users may encounter while working with the CX Cloud Agent.
A. Yes, for some specific deployment scenarios the redirection to cloudfront.net is expected. Ounbound access should be allowed with redirection enabled on port 443 for these FQDN’s.
A. Yes
A. OVA and VHD
A. For OVA
For VHD
A. Yes, the IP address assignment during IP configuration is detected. However, the IP address change expected for the CX Cloud Agent in the future is not supported. It is recommended that customers reserve the IP for the CX Cloud Agent in their DHCP environment.
A. No, only IPV4 is supported.
A. Yes, IP address syntax and duplicate IP address assignment are validated.
A.The OVA deployment depends on the speed of the network copying the data. IP configuration takes approximately 8-10 minutes including Kubernetes and container creations.
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.
A. No, the pairing code can only be generated when the CX Cloud Agent is not registered.
A.Bandwidth is not a constraint when the CX Cloud Agent and Cisco Catalyst Center are in the same LAN/WAN network in the customer environment. The minimum required network bandwidth is 2.7Mbit/sec for inventory collections of 5000 devices +13000 Access Points for an Agent to Cisco Catalyst Center connection. If syslogs are collected for Level 2 insights, the 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 CX Cloud Agent..
A. Syslogs for Agent VM can be accessed from the local VM login using the following two paths:
/var/log/syslog.1 (accessed via cxcadmin and cxcroot logins)
/var/log/syslog (accessed using root)
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.
A. To locate and upgrade to the latest CX Cloud Agent:
A. cxcadmin.
A. Passwords are set during network configuration.
A. No specific option is provided by the CX Cloud Agent to reset the password, but you can use the Linux commands to reset the password for cxcadmin.
A. Password policies are:
A. To confirm SSH reachability:
Iptables -A OUTPUT -p tcp -m tcp --dport 22 -j ACCEPT
To disable the SSH ports enabled above in the CX Cloud Agent:
iptables -L OUTPUT --line-number | grep dpt | grep ssh | awk '{print $1}'
iptables -L OUTPUT <Line number>
A. To confirm SNMP reachability:
iptables -A OUTPUT -p udp -m udp --dport 161 -j ACCEPT
iptables -A OUTPUT -p udp -m udp --dport 161 -j ACCEPT
snmpwalk -v2c -c cisco IPADDRESS
To disable the SNMP ports enabled above in the CX Cloud Agent:
iptables -L OUTPUT --line-number | grep dpt | grep ssh | awk '{print $1}'
iptables -L OUTPUT <Line number2 Number>
iptables -L OUTPUT <Line number1 Number>
A. To set the Grub password:
A. The password expires in 90 days.
A. Yes, the account is disabled after five (5) consecutive unsuccessful attempts. The lockout period is 30 minutes.
A. To generate a passphrase:
A. Yes, but to use hostname, user must provide the Domain Name Server (DNS) IP during network configuration.
A. The following ciphers are supported:
A. To log in:
A. Yes, they are logged as part of the "var/logs/audit/audit.log". file
A. SSH session timeout occurs if the CX Cloud Agent is idle for five (5) minutes.
A. These following ports are available:
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 listed domains, when EMEA or APJC customers reinstall the CX Cloud Agent, the agent.us.csco.cloud domain must be allowed in the customer firewall.
The agent.us.csco.cloud domain is no longer required 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. Customers must allow port 443 in their firewall to receive data from CX Cloud.A. Cisco Catalyst Center is the Cloud Agent that manages the customer premise network devices. CX Cloud Agent collects device inventory information from the configured Cisco Catalyst Center and uploads the inventory information available in the Asset View of CX Cloud.
A. During the Day 0 - CX Cloud Agent setup, users can add the Cisco Catalyst Center details from the CX Cloud portal. During Day N operations, users can add additional Cisco Catalyst Centers from Admin Settings > Data Source
.
A. Ten (10) Cisco Catalyst Center clusters or 20 Cisco Catalyst Center non-clusters can be added.
A. To remove a connected Cisco Catalyst Center from CX Cloud Agent, contact the Technical Assistance Center (TAC) to open a support case from the CX Cloud portal.
A. The user role can be either admin or observer.
A. Execute the cxcli agent modifyController command from the CX Cloud Agent console:
Contact support for any issues during Cisco Catalyst Center credentials update.
A. All data including credentials of CX Cloud Agent connected controllers (e.g., Cisco Catalyst Center) and directly connected assets (e.g., via seed file, IP range), are encrypted using AES-256 and stored in the CX Cloud Agent database which is protected with a secured user ID and password.
A. Yes, the CX Cloud Agent is unable to handle discovery operations for larger subnet IP ranges. Cisco recommends using minimized subnet ranges limited to 10,000 IP addresses.
A. Cisco does not recommend using a public IP subnet for the following reasons:
A public IP subnet can be used if it is solely assigned to a customer organization and set up over the customer network.
A. The rediscovery operation should only be performed if there is a change in the customer network (e.g., after devices are added or deleted within the network).
A. The workflow is as follows:
A. HTTPS over TLS 1.2 is used for the communication between Cisco Catalyst Center and CX Cloud Agent.
A. CX Cloud Agent collects data from the Cisco Catalyst Center about network devices and uses the Cisco Catalyst Center command runner interface to talk to end devices and execute CLI commands (show command). No config change commands are executed.
A.
A. Refer to this document for more information.
A. CX Cloud Agent uploads the inventory data via TLS 1.2 protocol to Cisco backend server.
A. Collection is triggered as per the user-defined schedule and is uploaded to the Cisco backend.
A. Yes, an option is available from Admin Center > Data Sources to modify the schedule information.
A. Timeouts are categorized as follows:
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).
A. The scanned results are stored and profiled in the Cisco backend.
A. No, duplicates are filtered such that only the unique devices are extracted.
A. The device scan completely stops and is marked as unsuccessful.
A. Executing multiple diagnostic scans simultaneously can slow the scanning process and potentially result in scan failures. Cisco recommends scheduling diagnostic scans or initiating on-demand scans at least 6-7 hours apart from inventory collection schedules so they do not overlap.
A. Application logs, Pod status, Cisco Catalyst Center details, audit logs, system details, and hardware details.
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"
}
}
}
A. With CX Cloud Agent, the health service (servicability) streams the data to the Cisco backend.
A. The CX Cloud Agent’s health data log retention policy in the backend is 120 days.
A.
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 through the portal with the reinstall option provided in the Admin Center
page.
Issue: How do I verify that services are up and running after registration?
Solution: Follow the steps below to confirm that pods are up and running:
Pods can be in any state (Running, Initializing, or Container creating). After 20 minutes, the pods must be in Running state.
If state is is not running or Pod Initializing, check the pod description with the kubectl describe pod <podname> command.
The output will have 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:
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 Catalyst Center |
{ |
If the requested device is not reachable from Cisco Catalyst Center |
{ |
If the requested device is not reachable from Cisco Catalyst Center |
{ |
If the requested command is not available in the device |
{ |
If the requested device does not have SSHv2 and Cisco Catalyst 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 Catalyst Center |
{ |
If the Command Runner Task failed to get created in Cisco Catalyst Center |
{ |
If the Collection microservice is not receiving a response for a Command Runner request from Cisco Catalyst Center |
{ |
If Cisco Catalyst Center is not completing the task within the configured timeout (5 mins per command in Collection microservice) |
{ |
If the Command Runner Task failed and the file ID is empty for the submitted task by Cisco Catalyst Center |
{ |
If the Command Runner Task failed and the file ID tag is not returned by Cisco Catalyst Center |
{ |
If the device is not eligible for command runner execution |
{ |
If the command runner is disabled for the user |
{ |
Scan failures and the causes can be from any of the listed components.
When users initiate a scan from the portal, occasionally it results as “failed: Internal server error”.
The cause for the issue is one of the listed components
To see the logs:
The table below displays the error snippet seen under the 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 are block-listed on the Collection microservice |
{ |
If the device for a 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 the Cisco Catalyst Center |
No device found with id 02eb08be-b13f-4d25-9d63-eaf4e882f71a |
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 Catalyst Center for the device |
All requested devices are already being queried by command runner in another session. Please try other devices |
If the device is not supported for scan |
Requested devices are not in inventory, try with other devices available in inventory |
If the device attempted for scan is unreachable |
"Error occurred while executing command: show udi\nError connecting to device [Host: x.x.x.x:22] No route to host : No route to host |
If Cisco Catalyst 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 Catalyst Center |
{ |
Use Case |
Log Snippet in Control Point Agent Microservice |
If the scan request has schedule details missing |
Failed to execute request |
If the scan request has device details missing |
Failed to create scan policy. No valid devices in the request |
If the connection between the CPA and connectivity is down |
Failed to execute request |
If the requested device for scan is not available in Diagnostic Scans |
Failed to submit the request to scan. Reason = {\"message\":\"Device with Hostname=x.x.x.x' was not found\"} |
Revision | Publish Date | Comments |
---|---|---|
3.0 |
26-Sep-2024 |
Updated the document to reflect Cisco DNA Center name change to Cisco Catalyst Center. |
2.0 |
25-Jul-2024 |
New Q and A's are added for v2.4 |
1.0 |
31-Oct-2022 |
Initial Release |