Courseiva
DebugPrivileged EXEC

debug ip nat detailed

Use this command to enable detailed debugging of NAT translations, showing packet-by-packet translation details including inside/outside addresses and port numbers, typically for troubleshooting NAT issues.

Definition: debug ip nat detailed is a Cisco IOS privileged exec command. Use this command to enable detailed debugging of NAT translations, showing packet-by-packet translation details including inside/outside addresses and port numbers, typically for troubleshooting NAT issues.

Overview

The 'debug ip nat detailed' command is a powerful diagnostic tool used in Cisco IOS to enable detailed debugging of Network Address Translation (NAT) operations. This command provides packet-by-packet translation details, including inside and outside addresses, port numbers, and the translation process. It is essential for troubleshooting complex NAT issues such as misconfigured access lists, overlapping address spaces, or port address translation (PAT) failures.

NAT is a fundamental networking concept that allows private IP addresses to be translated to public IP addresses for internet connectivity, conserving global address space. This command is typically used when standard 'show ip nat translations' or 'debug ip nat' does not provide enough granularity to pinpoint the problem. For example, if traffic intermittently fails or certain applications do not work through NAT, detailed debugging reveals exactly how each packet is being translated.

In the broader troubleshooting workflow, an engineer would first verify NAT configuration with 'show ip nat translations' and 'show ip nat statistics', then enable 'debug ip nat' for a general view, and finally escalate to 'debug ip nat detailed' for deep packet inspection. Important IOS behaviors: the output is sent to the console by default and can be overwhelming on busy networks; it is recommended to use 'logging buffered' and 'terminal monitor' to capture output. The command requires privileged EXEC mode (enable) and does not affect the running configuration.

It should be used with caution in production environments due to high CPU utilization and potential log flooding. The command is available in IOS 12.x and later, with similar functionality in IOS-XE, but not in NX-OS or IOS-XR (which use different debugging commands).

Syntax·Privileged EXEC
debug ip nat detailed

When to Use This Command

  • Troubleshooting why internal hosts cannot access the internet through NAT
  • Verifying that NAT translations are occurring correctly for specific traffic flows
  • Diagnosing asymmetric routing or NAT pool exhaustion issues
  • Investigating port address translation (PAT) behavior for multiple internal hosts

Command Examples

Basic debug ip nat detailed output

debug ip nat detailed
NAT: s=192.168.1.10->10.0.0.1, d=8.8.8.8 [12345]
NAT: s=8.8.8.8, d=10.0.0.1->192.168.1.10 [54321]
NAT: s=192.168.1.10->10.0.0.1, d=8.8.8.8 [12346]
NAT: s=8.8.8.8, d=10.0.0.1->192.168.1.10 [54322]

Each line shows a NAT translation event. 's=' is source address, 'd=' is destination address. The arrow indicates translation direction. Inside local (192.168.1.10) translates to inside global (10.0.0.1) for outbound traffic; reverse for inbound. The number in brackets is the packet ID for correlation.

Debug with ACL filter

debug ip nat detailed 100
NAT: s=192.168.1.10->10.0.0.1, d=8.8.8.8 [12345]
NAT: s=8.8.8.8, d=10.0.0.1->192.168.1.10 [54321]

Filtering by ACL 100 limits debug output to packets matching the ACL. This reduces noise when troubleshooting specific traffic.

Understanding the Output

The debug output shows each packet that undergoes NAT translation. Each line begins with 'NAT:' followed by the translation details. For outbound traffic, the source address changes from inside local to inside global (s=192.168.1.10->10.0.0.1).

For inbound replies, the destination address changes from inside global to inside local (d=10.0.0.1->192.168.1.10). The packet ID in brackets helps match request and reply. If you see 'NAT: translation failed' or no output when traffic is flowing, check NAT configuration and ACLs.

Excessive output may indicate a misconfiguration or attack.

Configuration Scenarios

Troubleshooting PAT (Port Address Translation) Overload

A small office uses a single public IP address for internet access via PAT. Users report that some websites fail to load or connections time out. The goal is to verify that PAT is correctly translating source ports and addresses.

Topology

PC1(192.168.1.10)---(Gi0/0)R1(Gi0/1)---Internet (203.0.113.1)

Steps

  1. 1.Step 1: Enter privileged EXEC mode: Router> enable
  2. 2.Step 2: Enable detailed NAT debugging: Router# debug ip nat detailed
  3. 3.Step 3: From a PC, attempt to access a website (e.g., ping 8.8.8.8 or browse).
  4. 4.Step 4: Observe the debug output on the router console or via 'terminal monitor'.
  5. 5.Step 5: Disable debugging after capturing sufficient data: Router# undebug all
Configuration
! NAT configuration on R1
interface GigabitEthernet0/0
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
!
interface GigabitEthernet0/1
 ip address 203.0.113.1 255.255.255.0
 ip nat outside
!
access-list 1 permit 192.168.1.0 0.0.0.255
ip nat inside source list 1 interface GigabitEthernet0/1 overload

Verify: Use 'show ip nat translations' to see active translations. Expected output shows inside local (192.168.1.10:xxxx) translated to inside global (203.0.113.1:yyyy) with different port numbers.

Watch out: If the debug output shows 'NAT: translation failed' or 'NAT: no translation', check that the access list matches the source traffic and that the outside interface has a valid public IP.

Troubleshooting Static NAT for a Server

A company hosts a web server (192.168.1.100) that must be accessible from the internet via a public IP (203.0.113.10). External users cannot reach the server. The goal is to verify that static NAT is translating inbound traffic correctly.

Topology

Internet---(Gi0/1)R1(Gi0/0)---Server(192.168.1.100)

Steps

  1. 1.Step 1: Enter privileged EXEC mode: Router> enable
  2. 2.Step 2: Enable detailed NAT debugging: Router# debug ip nat detailed
  3. 3.Step 3: From an external host, attempt to access the server (e.g., telnet 203.0.113.10 80).
  4. 4.Step 4: Observe the debug output for inbound and outbound translations.
  5. 5.Step 5: Disable debugging: Router# undebug all
Configuration
! Static NAT configuration
interface GigabitEthernet0/0
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
!
interface GigabitEthernet0/1
 ip address 203.0.113.1 255.255.255.0
 ip nat outside
!
ip nat inside source static 192.168.1.100 203.0.113.10

Verify: Use 'show ip nat translations' to see the static entry. Expected output: inside local 192.168.1.100, inside global 203.0.113.10. Debug output should show 'NAT: s=203.0.113.10->192.168.1.100' for inbound traffic.

Watch out: Ensure that the server's default gateway points to the router's inside interface (192.168.1.1). Also verify that the outside interface is not blocking inbound traffic with an access list.

Troubleshooting with This Command

When using 'debug ip nat detailed' for troubleshooting, it is crucial to understand what healthy output looks like versus problem indicators. Healthy output shows clear translation entries with source and destination addresses being translated correctly. For example, a typical healthy line might be: 'NAT: s=192.168.1.10->203.0.113.1, d=8.8.8.8 [0]' indicating the source is being translated from inside local to inside global.

Problem indicators include messages like 'NAT: translation failed (A)' where the letter in parentheses indicates the reason: 'A' means no access list match, 'B' means no route, 'C' means address conflict, 'D' means pool exhausted, 'E' means overloaded port exhausted. Focus on the source and destination IP addresses and port numbers; if you see 'NAT: no translation' or 'NAT: translation failed', check the access list configuration, route availability, and NAT pool. Common symptoms this command helps diagnose include: inability to reach the internet from inside hosts (check for missing inside/outside interface statements), asymmetric routing causing translation issues (look for packets arriving on the wrong interface), and PAT port exhaustion (indicated by 'NAT: translation failed (E)').

A step-by-step diagnostic flow: 1) Verify NAT configuration with 'show ip nat translations' and 'show ip nat statistics'. 2) Enable 'debug ip nat detailed' and reproduce the problem. 3) Look for translation failures and note the reason code. 4) Check access lists with 'show access-lists' to ensure traffic is permitted. 5) Verify routing with 'show ip route' to ensure the translated address is reachable. 6) If using PAT, check the number of translations with 'show ip nat statistics' to see if the port limit is reached. Correlate this command's output with 'show ip nat translations' to see the current state, and with 'debug ip packet' (with caution) to see if packets are arriving at the router. Remember to disable debugging immediately after capturing the needed data to avoid performance impact.

CCNA Exam Tips

1.

CCNA exam may ask which command to use to see real-time NAT translations; 'debug ip nat detailed' is the answer.

2.

Remember that debug commands are CPU-intensive; always use with caution and turn off with 'undebug all'.

3.

The exam might test that 'debug ip nat detailed' shows inside local to inside global mapping.

4.

Be aware that ACL filtering can be applied to debug to limit output to specific traffic.

Common Mistakes

Leaving debug enabled after troubleshooting, causing high CPU usage and potential router crash.

Confusing 'debug ip nat' (summary) with 'debug ip nat detailed' (packet-level).

Forgetting to use 'access-list' to filter debug output, resulting in overwhelming console messages.

debug ip nat detailed vs debug ip nat

The commands `debug ip nat` and `debug ip nat detailed` are both used for real-time monitoring of NAT translations on Cisco routers, often leading to confusion due to their similar names. The key difference lies in the level of detail: `debug ip nat` shows basic translation events, while `debug ip nat detailed` provides per-packet information including addresses and ports, which can significantly impact router performance.

Aspectdebug ip nat detaileddebug ip nat
VerbosityHigh: per-packet details (inside/outside IPs, ports)Low: shows translation events (creation, timeout, failure)
CPU ImpactHeavy: high overhead on production routersModerate: still impacts CPU but less than detailed
Output DetailIncludes packet payload summaries and ICMP/error messagesLimited to NAT translation lifecycle messages
Typical Use CasePinpointing specific translation failures or asymmetriesMonitoring general NAT behaviour or verifying configurations
Risk of System ImpactCan cause router to become unresponsive under loadSafer for brief troubleshooting sessions

Use debug ip nat detailed when you need to examine individual packet translations, such as diagnosing asymmetric routing or PAT port allocation issues, but only during low-traffic periods or on a test router.

Use debug ip nat when you want to observe NAT translation events (e.g., dynamic mappings timing out) with lower risk of overwhelming the router.

Platform Notes

In IOS-XE, the 'debug ip nat detailed' command is available with the same syntax and output format. However, IOS-XE may include additional fields such as VRF information if NAT is configured per VRF. For NX-OS, the equivalent command is 'debug ip nat translations' with optional 'detail' keyword, but the syntax differs: 'debug ip nat translations detail'.

NX-OS also supports 'debug ip nat packet' for packet-level debugging. For ASA firewalls, the equivalent is 'debug nat' or 'debug nat detail', but ASA uses a different NAT configuration model (object NAT vs. twice NAT). In IOS-XR, NAT debugging is done via 'debug nat translations' and 'debug nat packet', but the command structure is different and requires the 'crypto' or 'nat' context.

Between IOS versions, the output format has remained largely consistent from 12.x to 15.x and 16.x, but newer versions may include additional details like TCP flags or sequence numbers. Always check the specific IOS documentation for your version. The command is not available in IOS-XR by default; it requires the NAT feature package.

Related Commands

Practice for the CCNA 200-301

Test your knowledge with practice questions covering all CCNA 200-301 exam domains.

Practice CCNA 200-301 Questions