NAT mechanics are complex, but NAT configuration is pretty simple. However, if something does not work as expected, there are a bunch of things you can do. The show ip nat translations and show ip nat statistics commands covered in previous sections usually provide enough information to be able to identify problems with NAT. However there is another useful tool you should probably have in your toolbox and that is the debug ip nat command:
IP NAT debugging is on
R1#
*Mar 1 00:20:24.007: NAT*: s=192.168.1.2->67.210.91.2, d=173.194.67.102 [30]
*Mar 1 00:20:24.035: NAT*: s=173.194.67.102, d=67.210.91.2->192.168.1.2 [30]
R1#
*Mar 1 00:20:29.355: NAT*: s=192.168.1.3->67.210.91.3, d=173.194.67.102 [31]
*Mar 1 00:20:29.395: NAT*: s=173.194.67.102, d=67.210.91.3->192.168.1.3 [31]
R1#
*Mar 1 00:20:33.583: NAT*: s=192.168.1.4->67.210.91.4, d=173.194.67.102 [32]
*Mar 1 00:20:33.599: NAT*: s=173.194.67.102, d=67.210.91.4->192.168.1.4 [32]
R1#
The above output is from router R1 configured with Static NAT as presented earlier in the chapter. Nothing is broken here and the configuration is good. We generate a single ping from each of the inside hosts 192.168.1.2, 192.168.1.3, 192.168.1.4 to the server 173.194.67.102. You can see six debug entries in the above output for outgoing as well as return packets. In the outgoing packets, the source IP address is translated. While in the return packets, the destination IP address is translated.
The debug ip nat command can be used to verify the operation of NAT displaying information about each packet the router translates. This command also displays information about certain errors, such as the failure to allocate a global address.
As a general rule, you should always use show commands first for verification and troubleshooting. All debug commands should be used only when you have exhausted your options with show commands. These debug commands consume resources namely CPU cycles and memory, and should be used with caution on production networks especially if you love your current job.