What is the full form of NAT

introduction

When problems with IP connectivity occur in a NAT environment, it is often difficult to determine the source of the problem. Often, NAT is falsely accused when there is actually an underlying problem. This document shows how to verify NAT operation using the tools available on Cisco routers. This document also explains how to perform basic NAT troubleshooting and how to avoid common NAT troubleshooting mistakes.

requirements

conditions

There are no special requirements for this document.

Components used

This document is not limited to specific software and hardware versions.

The information in this document was produced by the devices in a specific laboratory environment. All devices used in this document started with an empty (standard) configuration. With your network up and running, make sure you understand the potential implications of a command.

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Exclude NAT

Trying to determine the source of an IP connection problem will help rule out NAT. To make sure NAT works as expected, do the following:

  1. Use the configuration to clearly define what NAT should achieve. At this point you can determine that there is a configuration problem. For help configuring NAT, see Configuring Network Address Translation: Getting Started.

  2. Check that the correct translation is available in the translation table.

  3. Check using the commands show and debugwhether the translation will take place.

  4. Check in detail what is happening to the packet and make sure the routers have the correct routing information to forward the packet.

Below are some sample problems where we'll use the steps above to help determine the source of the problem.

Example problem: One router can be pinged, but no other.

In this network diagram, router 4 can ping router 5 (172.16.6.5) but not router 7 (172.16.11.7):

No routing protocols are running on either router, and router 4 has router 6 as its default gateway. This is how Router 6 is configured with NAT:

Router 6
interface Ethernet0 ip address 172.16.6.6 255.255.255.0 ip directed-broadcast ip nat outside media-type 10BaseT! interface Ethernet1 ip address 10.10.10.6 255.255.255.0 ip nat inside media-type 10BaseT! interface Serial2.7 point-to-point ip address 172.16.11.6 255.255.255.0 ip nat outside frame-relay interface-dlci 101! ip nat pool test 172.16.11.70 172.16.11.71 prefix-length 24 ip nat inside source list 7 pool test ip nat inside source static 10.10.10.4 172.16.6.14! access-list 7 permit 10.10.50.4 access-list 7 permit 10.10.60.4 access-list 7 permit 10.10.70.4

First, make sure that NAT is working properly. You know from the configuration that the IP address of router 4 (10.10.10.4) should be statically translated to 172.16.6.14. You can use the command show ip nat translation on router 6 to check if the translation is present in the translation table:

router-6 # show ip nat translation Pro Inside global Inside local Outside local Outside global --- 172.16.6.14 10.10.10.4 --- ---

Now make sure this translation takes place when Router 4 generates IP traffic. This can be done in two ways through Router 6: by using NAT-Debug run or NAT statistics with the command show ip nat statistics monitor. There DebugCommands should always be used as a last resort, start with the command show.

Here the hit counter is to be monitored to determine whether it increases when router 4 sends data traffic. The hit counter increases every time a translation in the translation table is used to translate an address. First clear the statistics, then view the statistics, try to ping router 7 from router 4, and then view the statistics again.

router-6 # clear ip nat statistics router-6 # router-6 # show ip nat statistics Total active translations: 1 (1 static, 0 dynamic; 0 extended) Outside interfaces: Ethernet0, Serial2.7 Inside interfaces: Ethernet1 Hits: 0 Misses: 0 Expired translations: 0 Dynamic mappings: - Inside Source access-list 7 pool test refcount 0 pool test: netmask 255.255.255.0 start 172.16.11.70 end 172.16.11.71 type generic, total addresses 2, allocated 0 (0%), misses 0 router-6 #

After using the command ping 172.16.11.7 on router 4, the following NAT statistics are displayed on router 6:

router-6 # show ip nat statistics Total active translations: 1 (1 static, 0 dynamic; 0 extended) Outside interfaces: Ethernet0, Serial2.7 Inside interfaces: Ethernet1 Hits: 5 Misses: 0 Expired translations: 0 Dynamic mappings: - Inside Source access-list 7 pool test refcount 0 pool test: netmask 255.255.255.0 start 172.16.11.70 end 172.16.11.71 type generic, total addresses 2, allocated 0 (0%), misses 0

You can from the commands show see that the number of hits has increased by five. With a successful Ping a Cisco router should increase the number of hits by ten. The five Internet Control Message Protocol (ICMP) echoes sent by the source router (Router 4) should be translated. The five echo reply packets from the destination router (router 7) should also be translated in order to achieve a total of ten hits. The five missing hits are most likely due to the echo responses not being translated or not being sent by Router 7.

Check if you can find a reason why router 7 is not sending echo reply packets to router 4. First, check what NAT is doing to the packet. Router 4 sends ICMP echo packets with the source address 10.10.10.4 and the destination address 172.16.11.7. According to NAT, the packet received by router 7 has the source address 172.16.6.14 and the destination address 172.16.11.7. Router 7 must respond to 172.16.6.14, and since 172.16.6.14 is not directly connected to Router 7, a route must be set up for this network in order to respond. Check Router 7's routing table to make sure the route exists.

router-7 # show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1 , N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 4 subnets C 172.16.12.0 is directly connected, Serial0.8 C 172.16.9.0 is directly connected, Serial0.5 C 172.16.11.0 is directly connected, Serial0.6 C 172.16.5.0 is directly connected, Ethernet0

You can see that the routing table for router 7 does not have a route for 172.16.6.14. If you add this route, the ping command will work fine.

Problem overview

First of all, you have determined what NAT should achieve. You then checked whether the static NAT entry was present and correct in the translation table. Using the NAT statistics, you have checked whether the translation really took place. There you found an issue that prompted you to check the routing information on Router 7. It was found that router 7 needed a route to the global internal address of router 4.

Note that in this simple lab setting, it makes sense to run NAT statistics with the show ip nat statistics to monitor. In a more complex NAT environment with multiple translations, this command is show but no longer makes sense. In this case it may be necessary Debug run on the router. The next problem scenario is using DebugCommands illustrated.

Example problem: External network devices cannot communicate with internal routers

In this scenario, router 4 can be both router 5 and router 7 ping, but devices on network 10.10.50.0 cannot communicate with Router 5 or Router 7 (in the test lab we emulate this by using Pings from the loopback interface with the IP address 10.10.50.4). Take a look at the network diagram:

Router 6
interface Ethernet0 ip address 172.16.6.6 255.255.255.0 ip directed-broadcast ip nat outside media-type 10BaseT! interface Ethernet1 ip address 10.10.10.6 255.255.255.0 ip nat inside media-type 10BaseT! interface Serial2.7 point-to-point ip address 172.16.11.6 255.255.255.0 ip nat outside frame-relay interface-dlci 101! ip nat pool test 172.16.11.70 172.16.11.71 prefix-length 24 ip nat inside source list 7 pool test ip nat inside source static 10.10.10.4 172.16.6.14! access-list 7 permit 10.10.50.4 access-list 7 permit 10.10.60.4 access-list 7 permit 10.10.70.4

First, clearly state the expected behavior of NAT. From the configuration of Router 6 you know that NAT 10.10.50.4 should translate dynamically into the first available address in the NAT pool "test". The pool consists of the addresses 172.16.11.70 and 172.16.11.71. From what you learned in the above problem, you can assume that the packets received by routers 5 and 7 have either the source address 172.16.11.70 or 172.16.11.71. These addresses are in the same subnet as Router 7. Router 7 should therefore have a directly connected route. Router 5, however, needs a route to the subnet if it does not already exist.

With the command show ip route you can check whether the routing table Router 5 contains the following list: 172.16.11.0:

router-5 # show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1 , N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 4 subnets C 172.16.9.0 is directly connected, Serial1 S 172.16.11.0 [1/0] via 172.16.6.6 C 172.16.6.0 is directly connected, Ethernet0 C 172.16.2.0 is directly connected, Serial0

With the command show ip route you can see that router 7's routing table lists 172.16.11.0 as a directly connected subnet:

router-7 # show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1 , N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 5 subnets C 172.16.12.0 is directly connected, Serial0.8 C 172.16.9.0 is directly connected, Serial0.5 C 172.16.11.0 is directly connected, Serial0.6 C 172.16.5.0 is directly connected, Ethernet0 S 172.16.6.0 [1/0] via 172.16.11.6

Now that you have clearly stated what NAT should do, you need to verify that it is working properly. First, check the NAT translation table and verify that it has the translation you expected. Since the translation you are interested in is created dynamically, you must first send the IP traffic to the appropriate address. After a sent Pingwhich is from 10.10.50.4 and destined for 172.16.11.7, the translation table in router 6 shows the following:

router-6 # show ip nat translation Pro Inside global Inside local Outside local Outside global --- 172.16.6.14 10.10.10.4 --- --- --- 172.16.11.70 10.10.50.4 --- ---

Since the expected translation is in the translation table, you know the ICMP echo packets are translated correctly, but what about the echo reply packets? As mentioned above, you can monitor NAT statistics, but this is not very useful in a complex environment. Another option is to do NAT debugging on the NAT router (router 6). In that case, you should debug ip nat on router 6 while using a Ping send that is from 10/10/50.4 to 172.16.11.7. The Debug results are listed below.

Note: If you have a DebugUsing the command on a router can overload the router, rendering it inoperable. Always proceed with extreme caution and do not perform any operations without the supervision of a Cisco Technical Support engineer Troubleshooting on a critical production router.

router-6 # show log Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns) Console logging: level debugging, 39 messages logged Monitor logging: level debugging, 0 messages logged Buffer logging: level debugging, 39 messages logged Trap logging: level informational, 33 message lines logged log buffer (4096 bytes): 05:32:23: NAT: s = 10.10.50.4-> 172.16.11.70, d = 172.16.11.7 [70] 05:32:23: NAT *: s = 172.16.11.7 , d = 172.16.11.70-> 10.10.50.4 [70] 05:32:25: NAT *: s = 10.10.50.4-> 172.16.11.70, d = 172.16.11.7 [71] 05:32:25: NAT * : s = 172.16.11.7, d = 172.16.11.70-> 10.10.50.4 [71] 05:32:27: NAT *: s = 10.10.50.4-> 172.16.11.70, d = 172.16.11.7 [72] 05: 32:27: NAT *: s = 172.16.11.7, d = 172.16.11.70-> 10.10.50.4 [72] 05:32:29: NAT *: s = 10.10.50.4-> 172.16.11.70, d = 172.16. 11.7 [73] 05:32:29: NAT *: s = 172.16.11.7, d = 172.16.11.70-> 10.10.50.4 [73] 05:32:31: NAT *: s = 10.10.50.4-> 172.16. 11.70, d = 172.16.11.7 [74] 05:32:31: NAT *: s = 172.16.11.7, d = 172.16.11.70-> 10.10.50.4 [74]

As you did in the above Debug output can see, the first line shows the source address of 10.10.50.4 which translates to 172.16.11.70. The second line shows the destination address 172.16.11.70, which is translated back to 10.10.50.4. This pattern is repeated throughout the rest Debugging. This indicates that Router 6 is translating the packets in both directions.

Now take a closer look at what exactly should happen. Router 4 sends a packet that is from 10.10.50.4 and is intended for 172.16.11.7. Router 6 performs NAT on the packet and forwards a packet with source 172.16.11.70 and destination 172.16.11.7. Router 7 sends a response with the source 172.16.11.7 and the destination 172.16.11.70. Router 6 performs NAT on the packet, resulting in a packet with source address 172.16.11.7 and destination address 10.10.50.4. At this point, Router 6 should use the information in the routing table to forward the packet on 10.10.50.4. You need the command show ip route to verify that Router 6 has the required route in the routing table.

router-6 # show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1 , N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 5 subnets C 172.16.8.0 is directly connected, Serial1 C 172.16.10.0 is directly connected, Serial2.8 C 172.16.11.0 is directly connected, Serial2.7 C 172.16.6.0 is directly connected, Ethernet0 C 172.16.7.0 is directly connected, Serial0 10.0.0.0/24 is subnetted, 1 subnets C 10.10.10.0 is directly connected, Ethernet1

Problem overview

First of all, you clearly defined what NAT should achieve. Second, you checked that the necessary translations were in the translation table. Third, by using the Debug or Show-Commands checks whether the translation has actually taken place. Finally, you took a deeper look at what happened to the packet and what the routers need to forward or respond to the packet.

Troubleshooting checklists

Now that you have a basic procedure for determining the source of connectivity problems, here are some checklists to help you troubleshoot common problems.

Translation not installed in the translation table

If you find that the corresponding translation is not installed in the translation table, check the following:

  • The configuration is correct. It can be difficult at times to get NAT to achieve what you want. For more information on configuration, see Configuring Network Address Translation: Getting Started.

  • There are no access lists for incoming calls that refuse to enter the packets on the NAT router.

  • The NAT router shows the corresponding route in the routing table when the packet is transmitted from the inside to the outside. For more information, see the NAT order of operations.

  • The access list referenced by the NAT command allows all required networks.

  • The NAT pool has enough addresses. This should only be a problem if NAT is not configured for overload.

  • The router interfaces are defined accordingly as NAT inside or NAT outside.

  • When translating the payload of DNS packets, you need to ensure that the translation is done to the address in the IP header of the packet. If not, NAT does not check the packet's payload.

Wrong translation entry

If the correct translation entry is installed in the translation table but not used, check the following:

  • Make sure that there are no incoming access lists that deny the entry of the packets into the NAT router.

  • For packets going inside-out, check that there is a route to the destination as it will be checked before translation. For more information, see the NAT order of operations.

NAT works correctly, but there are still connection problems

If NAT is working properly, here's how to start troubleshooting the connection problem:

  • Checking Layer 2 Connectivity

  • Review the Layer 3 routing information.

  • Look for packet filters that could be causing the problem.

NAT translation for port 80 does not work

NAT translation for port 80 does not work, but translation for other ports works normally.

To resolve this issue, do the following:

  1. Run the commands debug ip nat translations and debug ip packet to determine whether the translations are correct and the correct translation entry is installed in the translation table.

  2. Check if the server is responding.

  3. Deactivate the HTTP server.

  4. Delete the NAT and ARP tables.

% NAT: The system is busy. Try again later

The error message is displayed when a showCommand for NAT or a show running-config or write memoryCommand is executed. This problem is due to the increase in the size of the NAT table. If the size of the NAT table increases, the router's memory will no longer be available.

To resolve this issue, reload the router. If you receive the error message when HSRP SNAT is configured, configure these commands to resolve the problem:

Router (config) #standby delay minimum 20 reload 20 Router (config) #standby 2 preempt delay minimum 20 reload 20 sync 10

Large translation table increases the CPU

A host can send hundreds of translations, which in turn results in high CPU usage. In other words, the table can grow so large that the CPU runs at 100 percent. The command ip nat translation max entries 300 specifies the 300 per host limit or an aggregate limit for the number of translations on the router. The solution is to give the command ip nat translation max entries all hosts 300 to use.

% already assigned public IP address (internal IP address -> public IP address)

This message appears when you try to configure two internal IP addresses for a public IP address that is listening on the same ports.

% X.X.X.X already mapped (172.30.62.101 -> X.X.X.X)

Use two public IP addresses in DNS to insert the public IP address into two internal IP addresses.

No entries in the ARP table

This is the result of the No aliasOption that is used for the NAT entries. The no-alias option means that the router will not respond to the addresses and will not install an ARP entry. If another router uses a NAT pool as its global internal pool, which consists of addresses in an attached subnet, an alias is generated for that address so that the router can answer Address Resolution Protocol (ARP) requests for those addresses. This results in the router having ARP entries for the spoofed addresses.

conclusion

The above issues have shown that NAT is not always the cause of IP connectivity issues. In many cases, the cause is other than NAT and requires further investigation. This document explains the basic steps to troubleshoot and verify NAT operations. These steps include:

  • Clearly define what NAT should achieve.

  • Check that the correct translation is available in the translation table.

  • Use the commands show and debugto check that the translation is in progress.

  • Check in detail what is happening to the packet and make sure the routers have the correct routing information to forward the packet.

Bad token 0, wanted TOK_NUMBER | TOK_PUNCT

This error message is informational only and has no effect on the normal behavior of the device.

Bad token 0, wanted TOK_NUMBER | TOK_PUNCT

The error means that the NAT is trying to do a Layer 4 repair on the address in an open FTP server and cannot find the IP addresses it needs to translate in the packet.

The reason the message contains tokens is because IP addresses in the packet can be found by looking for a token or a series of symbols in the IP packet to find the details needed for translation.

When an FTP session is initiated, two channels, a command channel and a data channel, are negotiated. These are both IP addresses with different port numbers. The FTP client and the server negotiate a second data channel to transfer files. The packet exchanged via the control channel has the format "PORT, i, i, i, i, p, p", where i, i, i, i are the four bytes of an IP address and p, p are the port. NAT tries to match this pattern and translates the address / port if necessary. NAT has to translate the addressing schemes of both channels. NAT searches the command stream for numbers until it thinks it has found a port command that needs to be translated. It tries to analyze the translation that it calculates using the previously described pattern.

If the packet is damaged or the FTP server or client has incorrect commands, NAT cannot calculate the translation correctly and generates this error. It is recommended that you set the FTP client to "passive" so that both channels are initiated become. This sometimes supports FTP over NAT.

Related information