Have an account?

  •   Personalized content
  •   Your products and support

Need an account?

Create an account

Cisco ASA Series CLI Configuration Guide, 9.0

Book Contents
Find Matches in This Book
Available Languages
Download Options

Book Title

Cisco ASA Series CLI Configuration Guide, 9.0

Chapter Title

Troubleshooting

Results

Updated:
September 25, 2018

Chapter: Troubleshooting

Troubleshooting

This chapter describes how to troubleshoot the ASA and includes the following sections:

Viewing Debugging Messages

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

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:

 

Command
Purpose
cluster exec ] capture capture_name [ type { asp-drop all [ drop-code ] | tls-proxy | raw-data | lacp | isakmp [ikev1 | ikev2] | decrypted | webvpn user webvpn-user [ url url] }] [ capture ] [ access-list access_list_name ] [ buffer buf_size ] [ ethernet-type type ] [ interface interface_name ] [ reinject-hide ] [ packet-length bytes ] [ circular-buffer ] [ trace trace_count ] [ real-time ] [ trace ] [ match prot { host source - ip | source - ip mask | any }{ host destination - ip | destination-ip mask | any } [ operator port ]
 
hostname# capture captest interface inside
 

Enables packet capture capabilities for packet sniffing and network fault isolation.

The access-list access_list_name keyword argument pair captures traffic that matches an access list. In multiple context mode, this is only available within a context. The any keyword specifies any IP address instead of a single IP address and mask. The all keyword captures all the packets that the ASA drops. The asp-drop [ drop-code ] keyword argument pair captures packets dropped by the accelerated security path. The drop-code specifies the type of traffic that is dropped by the accelerated security path. See the show asp drop frame command for a list of drop codes. If you do not enter the drop-code argument, then all dropped packets are captured. You can enter this keyword with the packet-length, circular-buffer, and buffer keywords, but not with the interface or ethernet-type keyword. In a cluster, dropped forwarded data packets from one unit to another are also captured. In multiple context mode, when this option is issued in system context, all dropped data packets are captured; when this option is issued in a user context, only dropped data packets that enter from interfaces belonging to the user context are captured. The buffer buf_size keyword argument pair defines the buffer size used to store the packet in bytes. When the byte buffer is full, packet capture stops. When used in a cluster, this is the per-unit size, not the sum of all units. The capture_name argument specifies the name of the packet capture. Use the same name on multiple capture statements to capture multiple types of traffic. When you view the capture configuration using the show capture command, all options are combined on one line. The circular-buffer keyword overwrites the buffer, starting from the beginning, when the buffer is full. The cluster exec keyword is used only in a clustering deployment as a wrapper CLI prefix, can be used with the capture and show capture commands, and enables you to issue the capture command in one unit and run the command in all the other units at the same time. The decrypted keyword enables decrypted TCP data to be encapsulated with L2-L4 headers, then captured by the capture engine. The ethernet-type type keyword argument pair selects an Ethernet type to capture. Supported Ethernet types include 8021Q, ARP, IP, IP6, IPX, LACP, PPPOED, PPPOES, RARP, and VLAN. An exception occurs with the 802.1Q or VLAN type. The 802.1Q tag is automatically skipped and the inner Ethernet type is used for matching. The host ip keyword argument pair specifies the single IP address of the host to which the packet is being sent. The interface interface_name keyword argument pair sets the name of the interface on which to use packet capture. You must configure an interface for any packets to be captured. You can configure multiple interfaces using multiple capture commands with the same name. To capture packets on the dataplane of an ASA, you can use the interface keyword with “asa_dataplane” as the interface name.You can specify “cluster” as the interface name to capture the traffic on the cluster control link interface. The interface names "cluster" and "asa-dataplane" are fixed and not configurable. If the type lacp capture is configured, the interface name is the physical name. The isakmp keyword captures ISAKMP traffic. This is not available in multiple context mode. The ISAKMP subsystem does not have access to the upper layer protocols. The capture is a pseudo capture, with the physical, IP, and UDP layers combined together to satisfy a PCAP parser. The peer addresses are obtained from the SA exchange and are stored in the IP layer. Use the ikev1 or ikev2 keywords to capture only IKEv1 or IKEv2 protocol information. The lacp keyword captures LACP traffic. If configured, the interface name is the physical interface name. The trace, match, and access-list keywords cannot be used together with the lacp keyword.

 

Command (continued)
Purpose (continued)

 

The mask argument specifes the subnet mask for the IP address. When you specify a network mask, the method is different from the Cisco IOS software access-list command. The ASA uses a network mask (for example, 255.255.255.0 for a Class C mask). The Cisco IOS mask uses wildcard bits (for example, 0.0.0.255). The match prot keyword argument pair specifies the packets that match the five-tuple to allow filtering of those packets to be captured. You can use this keyword up to three times on one line. The operator argument matches the port numbers used by the source or destination. The permitted operators are as follows:

  • lt—less than
  • gt—greater than
  • eq—equal to

The packet-length bytes keyword argument pair sets the maximum number of bytes of each packet to store in the capture buffer. If you set the protocol to tcp or udp, the port keyword specifies the integer or name of a TCP or UDP port. The raw-data keyword captures inbound and outbound packets on one or more interfaces. This setting is the default. The real-time keyword displays the captured packets continuously in real-time. To terminate real-time packet capture, enter Ctrl + c. To permanently remove the capture, use the no form of this command. This option applies only to raw-data and asp-drop captures. This option is not supported when you use the cluster exec capture command. The reinject-hide keyword specifies that no reinjected packets will be captured and applies only in a clustering environment. The tls-proxy keyword captures decrypted inbound and outbound data from TLS proxy on one or more interfaces. The trace trace_count keyword argument pair captures packet trace information, and the number of packets to capture. This option is used with an access list to insert trace packets into the data path to determine whether or not the packet has been processed as expected. The type keyword specifies the type of data captured. The url url keyword argument pair specifies a URL prefix to match for data capture. Use the URL format http:// server / path to capture HTTP traffic to the server. Use https:// server / path to capture HTTPS traffic to the server. The user webvpn-user keyword argument pair specifies a username for a WebVPN capture. The webvpn keyword captures WebVPN data for a specific WebVPN connection.

Note If ACL optimization is configured, you cannot use the access-list command in capture. You can only use the access-group command. An error appears if you try to use the access-list command in this case.

Capturing Packets in a Clustering Environment

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, users can see the interface, so they 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.

Guidelines and Limitations

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.

  • You can only capture IP traffic; you cannot capture non-IP packets such as ARPs.
  • For cluster control link capture in multiple context mode, only the packet that is associated with the context sent in the cluster control link is captured.
  • In multicontext mode, the copy capture command is available only in the system space. The syntax is as follows:

copy / pcap capture : Context-name / in-cap tftp :

Where in-cap is the capture configured in the context context-name

  • The cluster exec capture realtime command is not supported. The following error message appears:
Error: Real-time capture can not be run in cluster exec mode.
 
  • For a shared VLAN, the following guidelines apply:

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

  • For egress traffic, only the traffic of the context with the active capture is captured. The only exception is when you do not enable the ICMP inspection (therefore the ICMP traffic does not have a session in the accelerated path). In this case, both ingress and egress ICMP traffic for all contexts on the shared VLAN is captured.
  • Configuring a capture typically involves configuring an access list that matches the traffic that needs to be captured. After an access list that matches the traffic pattern is configured, then you need to define a capture and associate this access list to the capture, along with the interface on which the capture needs to be configured.

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:

hostname (cfg-cluster)# cluster exec copy /pcap capture: cap_name tftp://location/path/filename.pcap
 

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.

Examples

The following example shows how to create a cluster-wide LACP capture:

hostname (config)# cluster exec capture lacp type lacp interface gigabitEthernet0/0
 

The following example shows how to create a capture for control path packets in the clustering link:

hostname (config)# capture cp interface cluster match udp any eq 49495 any
hostname (config)# capture cp interface cluster match udp any any eq 49495
 

The following example shows how to create a capture for data path packets in the clustering link:

hostname (config)# access-list cc1 extended permit udp any any eq 4193
hostname (config)# access-list cc1 extended permit udp any eq 4193 any
hostname (config)# capture dp interface cluster access-list ccl
 

The following example shows how to capture data path traffic through the cluster:

hostname (config)# capture abc interface inside match tcp host 1.1.1.1 host 2.2.2.2 eq www
hostname (config)# capture abc interface inside match udp host 1.1.1.1 any
hostname (config)# capture abc interface inside access-list xxx
 

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:

hostname (config)# access-list dp permit ip real_src real_dst
 

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 access list for the message type:

hostname (config)# capture capture_name interface cluster access-list match icmp any any
 

The following example shows how to create a capture by using access list 103 on a cluster control link:

hostname (config)# access-list 103 permit ip A B
hostname (config)# capture example1 interface cluster access-list 103
 

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:

  • Forwarded packets are captured as usual, provided the source and destination IP addresses are matched with the access list.
  • The data path logic update message is captured provided it is for the flow between A and B or for an access list (for example, access-list 103). The capture matches the five-tuple of the embedded flow.
  • Although the source and destination addresses in the UDP packet are CCL addresses, if this packet is to update a flow that is associated with addresses A and B, then it is also captured. That is, as long as addresses A and B that are embedded in the packet are matched, it is also captured.

For more information about clustering, see Chapter1, “Configuring a Cluster of ASAs”

Viewing the Crash Dump

If the ASA 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.

Viewing the Coredump

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 users enable the coredump feature to troubleshoot application or system crashes on the ASA. See the coredump command in the command reference.

Was this Document Helpful?

FeedbackFeedback

Contact Cisco

Related Cisco Community Discussions

About Us
Contact Us
Work with Us