Cisco · Cisco IOS XE

Cisco IOS XE NAT Commands: Translations, Statistics and Troubleshooting

Quick answer #

Use show ip nat translations to inspect current mappings and show ip nat statistics for the configured translation context and counters. Match the actual protocol and ports for one reported connection. A translation entry proves that a mapping exists; it does not prove that the remote service replied successfully.

Scope: Traditional IPv4 NAT on supported IOS XE routing platforms, using IOS XE 17.x router documentation. Do not assume every Catalyst supports these NAT features. ASA, FTD and SD-WAN service-chain behavior are outside this reference.

Read-only commands #

Read-only commands
Cisco IOS XE · Authorized EXEC mode; context specified below

Read-only
show ip nat translations
Read-only
show ip nat translations verbose
Read-only
show ip nat statistics
Read-only
show running-config | include ip nat
Output may contain sensitive operational data.
Read-only

Replace these example values: GigabitEthernet0/0/0.

show running-config interface GigabitEthernet0/0/0
Output may contain sensitive operational data.
Read-only

Replace these example values: GigabitEthernet0/0/1.

show running-config interface GigabitEthernet0/0/1
Output may contain sensitive operational data.
Read-only

Replace these example values: 203.0.113.25.

show ip route 203.0.113.25

Run the ordinary translation view first. Verbose output can be large. On a device with many sessions, use the platform's supported filtering rather than repeatedly printing the complete table. The filtered running configuration is an index of NAT lines, not a complete view of any referenced ACL or route-map.

Read the address columns #

Inside local is the inside host's address as represented on the inside network. Inside global is its translated representation toward the outside. Outside local and outside global describe the outside host from the corresponding address realms; in a simple inside-source PAT deployment they are often the same. Compare protocol and port values as well as addresses.

Workflow #

  1. Record the affected client, destination, application protocol and expected egress. Keep the exact observation time so a short-lived entry is not confused with a different connection.
  2. Check the translation table while the application attempts the connection. For port translation, inspect the relevant source and destination ports instead of searching only for the client address.
  3. Inspect NAT statistics and the interface configuration. Confirm which interfaces and policy references apply to this path, rather than assuming an existing NAT rule covers every routed flow.
  4. If no relevant mapping appears, inspect classification, routing and whether the traffic reaches this device. An empty result after the session ended is weaker evidence than an empty result during the attempt.
  5. If a mapping exists, continue with access controls, outside reachability and the return path. A packet can be translated successfully and still fail later.

Interpretation pitfalls #

Do not read every statistic as a complete hardware packet counter. The meaning of software and accelerated forwarding counters is platform-dependent. Likewise, a configured static mapping is not evidence of a currently active user session.

An ACL referenced by a NAT rule selects translation candidates; that alone does not make it the interface's security policy. Inspect each role separately. Preserve translations during diagnosis: clearing the table can interrupt unrelated sessions and remove the exact evidence you are trying to understand.

Useful tools and references #

  • What is my IP: Open this tool from the affected client to observe that browser connection's public source. A proxy, VPN or different policy route can make another application use a different egress.
  • Common TCP and UDP ports: Identify customary service ports, then compare them with the actual translated tuple.

Sources

Documentation reviewed: 8 October 2026