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 chapter describes how to troubleshoot the ASA and ASAv and includes the following sections:
Because debugging output is assigned high priority in the CPU process, it can render the system unusable. For this reason, use debug commands only to troubleshoot specific problems or during troubleshooting sessions with Cisco TAC. Moreover, it is best to use debug commands during periods of less network traffic and fewer users. Debugging during these periods decreases the likelihood that increased debug command processing overhead will affect system use. To enable debugging messages, see the debug commands in the command reference.
Capturing packets may be useful when troubleshooting connectivity problems or monitoring suspicious activity. We recommend that you contact Cisco TAC if you want to use the packet capture feature.
To capture packets, enter the following command:
To support cluster-wide troubleshooting, you can enable capture of cluster-specific traffic on the master unit using the cluster exec capture command, which is then automatically enabled on all of the slave units in the cluster. The cluster exec keywords are the new keywords that you place in front of the capture command to enable cluster-wide capture.
The “cluster” interface name is the default name for the cluster control link and is not configurable. You specify “cluster “ as the interface name to capture the traffic on the cluster control link interface. There are two types of packets on the cluster control link: control plane packets and data plane packets, which both include forwarded data traffic and cluster LU messages. The TTL field in the IP address header is encoded to differentiate between these two types of packets. When forwarded data packets are captured, their clustering trailers are included in the capture file for debugging purposes.
In multiple context mode, although the cluster interface belongs to the system context, you can see the interface, so you can configure captures on the cluster link in user contexts. In the system context, both control plane and data plane packets are available. The data plane captures LU packets and forwarded data packets that belong only to the system context. In user contexts, control plane packets are not visible. Only forwarded data packets that belong to a specified user context and LU packets are captured. For security purposes, each context can only see the packets that belong to it.
This section includes the guidelines and limitation for this feature.
Most of the limitations are the result of the distributed nature of the ASA architecture and the hardware accelerators that are being used in the ASA.
copy / pcap capture : Context-name / in-cap tftp :
Where in-cap is the capture configured in the context context-name
– You can only configure one capture for the VLAN; if you configure a capture in multiple contexts on the shared VLAN, then only the last capture that was configured is used.
– If you remove the last-configured (active) capture, no captures become active, even if you have previously configured a capture in another context; you must remove the capture and add it again to make it active.
– All traffic that enters the interface to which the capture is attached is captured, including traffic to other contexts on the shared VLAN.
– Therefore, if you enable a capture in Context A for a VLAN that is also used by Context B, both Context A and Context B ingress traffic are captured.
After you have performed a cluster-wide capture, to copy the same cluster-wide capture file to a TFTP server, enter the following command on the master unit:
Multiple PCAP files, one from each unit, are copied to the TFTP server. The destination capture file name is automatically attached with the unit name, such as filename_A.pcap, filename_B.pcap, and so on. In this example, A and B are cluster unit names. A different destination name is generated if you add the unit name at the end of the filename.
To enable cluster-wide capture on a specified interface, you can add the cluster exec keywords in front of each of the commands shown in the examples. These capture commands can only be replicated from the master unit to the slave units. However, you can still configure a capture on the specified interface for the local unit using any of these capture commands.
The following example shows how to create a cluster-wide LACP capture:
The following example shows how to create a capture for control path packets in the clustering link:
The following example shows how to create a capture for data path packets in the clustering link:
The following example shows how to capture data path traffic through the cluster:
The following example shows how to capture logical update messages for flows that match the real source to the real destination, and capture packets forwarded over CCL that match the real source to the real destination:
The following example shows how to capture a certain type of data plane message, such as icmp echo request/response, that is forwarded from one ASA to another ASA using the match keyword or the ACL for the message type:
The following example shows how to create a capture by using ACL 103 on a cluster control link:
In the previous example, if A and B are IP addresses for the CCL interface, only the packets that are sent between these two units are captured.
If A and B are IP addresses for through-device traffic, then the following is true:
For more information about clustering, see Chapter9, “ASA Cluster”
If the ASA or ASAv crashes, you can view the crash dump information. We recommend that you contact Cisco TAC if you want to interpret the crash dump. See the show crashdump command in the command reference.
A coredump is a snapshot of the running program when the program has terminated abnormally or crashed. Coredumps are used to diagnose or debug errors and save a crash for future off-site analysis. Cisco TAC may request that you enable the coredump feature to troubleshoot application or system crashes on the ASA or ASAv. See the coredump command in the command reference.
The ASAv vCPU usage shows the amount of vCPUs used for the data path, control point, and external processes.
The vSphere reported vCPU usage includes the ASAv usage as described plus:
The following is an example in which the reported vCPU usage is substantially different:
The overhead is used to perform hypervisor functions and to move packets between NICs and vNICs using the vSwitch.
Usage can exceed 100% because the ESXi server can use additional compute resources for overhead on behalf of the ASAv.
In vSphere, click the VM Performance tab, then click Advanced to display the Chart Options drop-down list, which shows vCPU usage for each state (%USER, %IDLE, %SYS, and so on) of the VM. This information is useful for understanding VMware’s perspective on where CPU resources are being used.
On the ESXi server shell (you access the shell by using SSH to connect to the host), esxtop is available. Esxtop has a similar look and feel to the Linux top command and provides VM state information for vSphere performance, including the following:
There are differences in the CPU % numbers between the ASAv and vCenter:
The terms “%CPU utilization” and “%CPU usage” mean different things:
vCenter calculates the CPU % usage as follows:
Amount of actively used virtual CPUs, specified as a percentage of the total available CPUs
This calculation is the host view of the CPU usage, not the guest operating system view, and is the average CPU utilization over all available virtual CPUs in the virtual machine.
For example, if a virtual machine with one virtual CPU is running on a host that has four physical CPUs and the CPU usage is 100%, the virtual machine is using one physical CPU completely. The virtual CPU usage calculation is as follows:
Usage in MHz / number of virtual CPUs x core frequency
When you compare the usage in MHz, both the vCenter and ASAv numbers match. According to the vCenter graph, MHz % CPU usage is calculated as: