debug icmp trace
Enables real-time debugging of ICMP packets traversing the Cisco ASA Firewall to troubleshoot connectivity issues.
Overview
The debug icmp trace command is a powerful diagnostic tool on Cisco ASA Firewalls that provides real-time visibility into ICMP packet processing. ICMP (Internet Control Message Protocol) is essential for network troubleshooting utilities like ping and traceroute, as well as for path MTU discovery and error reporting. When enabled, this command prints a line for each ICMP packet that the ASA processes, including both ingress and egress directions. It is particularly useful for verifying that ICMP traffic is being correctly inspected, translated by NAT, and permitted by access-lists. The command operates in privileged EXEC mode and is typically used when ping tests fail or when ICMP-related issues are suspected. On the ASA platform, ICMP traffic is subject to stateful inspection by default (ICMP inspection engine), which tracks echo requests and replies to allow return traffic. Without inspection, the ASA would treat ICMP as connectionless and may drop replies. Debug icmp trace helps confirm that inspection is working by showing matched request/reply pairs. It also reveals NAT translations, as the ASA translates ICMP identifiers (or uses PAT for ICMP) to maintain uniqueness. The command should be used with caution because it can generate a large volume of output, especially in busy networks, potentially impacting CPU performance. It is best combined with an access-list to filter specific traffic, or used during low-traffic periods. Understanding the output is key: each line shows the ICMP type, source/destination IP, ID, sequence number, and length. For NAT, the translated IP and PAT ID appear in parentheses. A successful flow shows both request and reply lines with matching IDs and sequences. Missing replies indicate a problem such as a missing route, ACL drop, or inspection failure. The command does not show dropped packets; for that, use 'show asp drop' or packet captures. In summary, debug icmp trace is an indispensable tool for ICMP troubleshooting on ASA firewalls, providing immediate insight into packet flow and translation.
debug icmp traceWhen to Use This Command
- Troubleshooting ping failures between internal hosts and external servers through the ASA.
- Verifying ICMP inspection and NAT translations for ICMP traffic.
- Diagnosing asymmetric routing issues where ICMP replies take a different path.
- Identifying ICMP packet drops due to ACLs, inspection policies, or interface errors.
Parameters
| Parameter | Syntax | Description |
|---|---|---|
| No parameters | debug icmp trace | The command has no optional parameters. It enables tracing for all ICMP packets. To limit output, use an access-list with the 'debug icmp trace' command (e.g., 'debug icmp trace 100' where access-list 100 matches specific traffic). |
Command Examples
Basic ICMP debug output
debug icmp traceICMP echo request from 192.168.1.10 to 8.8.8.8 ID=1 seq=1 len=64 ICMP echo reply from 8.8.8.8 to 192.168.1.10 ID=1 seq=1 len=64
Each line shows an ICMP packet: direction, source/destination IP, ICMP type (echo request/reply), ID, sequence number, and length. Healthy output shows both request and reply.
ICMP debug with NAT translation
debug icmp traceICMP echo request from 192.168.1.10 to 8.8.8.8 ID=1 seq=1 len=64 (PAT: 203.0.113.1:1) ICMP echo reply from 8.8.8.8 to 203.0.113.1 ID=1 seq=1 len=64 (PAT: 192.168.1.10:1)
Shows NAT translation: the source IP is translated to the outside interface IP (203.0.113.1) with a PAT ID. Reply is translated back to the original IP.
Understanding the Output
The debug icmp trace output displays each ICMP packet as it is processed by the ASA. Each line includes the ICMP type (e.g., echo request, echo reply), source and destination IP addresses, ICMP identifier (ID), sequence number, and packet length. For NAT/PAT scenarios, the translated IP and PAT ID are shown in parentheses. Healthy output shows a matching request and reply with consistent IDs and sequence numbers. Problem indicators include seeing only requests without replies (suggesting a drop or no route back), or seeing replies with mismatched IDs (indicating NAT or inspection issues). The absence of any output when expecting traffic may indicate that ICMP is being dropped before reaching the debug process, possibly due to ACLs or interface errors.
Configuration Scenarios
Troubleshooting Ping from Inside to Outside
A host on the inside network (192.168.1.10) cannot ping an external server (8.8.8.8). NAT is configured to translate inside hosts to the outside interface IP.
Topology
Host(192.168.1.10) --- [Inside] ASA [Outside] --- Internet(8.8.8.8)Steps
- 1.Enable debug icmp trace on the ASA.
- 2.From the host, initiate a ping to 8.8.8.8.
- 3.Observe the debug output for echo request and reply.
- 4.If only request is seen, check ACLs, NAT, and routing.
! Enable debug debug icmp trace ! (Optional) Limit to specific traffic access-list ICMP_DEBUG permit icmp host 192.168.1.10 host 8.8.8.8 debug icmp trace ICMP_DEBUG
Verify: Check that both request and reply appear. If reply is missing, use 'show asp drop' to see drops.
Watch out: If ICMP inspection is disabled, the ASA may drop replies. Ensure 'policy-map global_policy' includes 'inspect icmp'.
Troubleshooting with This Command
When using debug icmp trace for troubleshooting on Cisco ASA, follow a systematic approach. First, ensure you are in privileged EXEC mode. Enable the debug with 'debug icmp trace'. To avoid overwhelming output, optionally apply an access-list to filter specific source/destination IPs. Initiate the ICMP traffic (e.g., ping) from the source. Observe the output: each line shows the packet direction, IPs, ICMP type, ID, sequence, and length. For NAT environments, the translated IP and PAT ID appear. A successful flow shows both request and reply with matching IDs and sequences. If only requests appear, the reply is being dropped. Common causes: ACL blocking return traffic, missing route back to source, or ICMP inspection not enabled. Check ACLs with 'show access-list', routing with 'show route', and inspection with 'show conn' or 'show service-policy inspect icmp'. If replies appear but with different IDs, NAT may be misconfigured. Use 'show xlate' to verify translations. If no output at all, the traffic may be dropped before the debug process; use 'capture' to confirm. Remember to disable debug with 'undebug all' or 'no debug icmp trace' after troubleshooting to avoid performance impact. The debug output can also help identify asymmetric routing if requests and replies traverse different interfaces. In summary, debug icmp trace is a real-time tool that, when used carefully, provides immediate insight into ICMP flow and translation issues.
CCNA Exam Tips
Remember that debug icmp trace can generate high CPU load; use it only during maintenance windows or with specific access-lists to limit scope.
On the CCNP Security exam, know that ICMP inspection is required for stateful handling of ICMP; without it, the ASA may not allow return traffic.
Be aware that debug icmp trace does not show dropped packets; use 'show asp drop' or 'capture' for drops.
Common Mistakes
Leaving debug icmp trace enabled in production, causing performance degradation or log flooding.
Forgetting to disable debug after troubleshooting, leading to continuous output.
Misinterpreting the PAT ID as the actual ICMP identifier; the PAT ID is a local translation index.
Platform Notes
On Cisco ASA, debug icmp trace behaves similarly to Cisco IOS but with ASA-specific nuances. Unlike IOS, the ASA applies stateful inspection to ICMP by default (via the ICMP inspection engine), which tracks echo requests and replies. The debug output includes NAT translation details, showing the translated IP and a PAT ID (not the actual ICMP identifier). On IOS, NAT for ICMP is handled differently (using ICMP ID translation). The command syntax is identical across ASA versions (8.x, 9.x). On other platforms like Cisco Firepower Threat Defense (FTD), the equivalent command is 'system support trace' or 'debug icmp' within the FTD CLI. On Palo Alto firewalls, similar functionality is achieved with 'debug dataplane packet-diag'. On ASA, the debug output can be directed to a syslog server or buffer; use 'logging buffer' to capture output. Version differences: ASA 9.0+ introduced more detailed output for ICMP errors (e.g., destination unreachable). Always check the specific ASA version documentation for any changes.
Related Commands
Practice for the CCNA 200-301
Test your knowledge with hundreds of CCNA practice questions covering all exam domains.
Practice CCNA Questions