This is a live example with a very little excitement.

Task 1

R2 is the NAT router, R2’s S1/1 interface should be configured as the Inside and R2’s S1/3 interface should be configured as Outside domain.
Configure R2 such that R3 can ping 12.1.1.1. You should configure Static NAT on R2 to accomplish this task. DO NOT configure any static, dynamic routing, PBR, or
PAT on R2.

Before we configure the static NAT let’s define the NAT domains:

On R2:

R2(config)#int s1/2
R2(config-subif)#ip nat inside

R2(config)#int s1/3
R2(config-if)#ip nat outside

Since R3 is on the Outside NAT domain, the following Static NAT is configured to translate the source IP address of 23.1.1.3 for ingress traffic
to 12.1.1.3 :

R2(config)# ip nat outside source static 23.1.1.3 12.1.1.3

To verify the configuration:

On R2:

R2#show ip nat translations

Pro Inside global Inside local Outside local Outside global

--- --- --- 12.1.1.3 23.1.1.3

To test the configuration:

On R3:

R3#ping 12.1.1.1 rep 1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 12.1.1.2, timeout is 2 seconds:
.
Success rate is 0 percent (0/1)

What happened? Let’s check the translation table of R2:

On R2:

R2#show ip nat translations

Pro Inside global Inside local Outside local Outside global

--- --- --- 12.1.1.3 23.1.1.3
icmp 12.1.1.1:8 12.1.1.1:8 12.1.1.3:8 23.1.1.3:8

The NAT translation table reveals that when the NAT router (R2) received a packet on its Outside interface (S1/3) with an IP address of
23.1.1.3, it translated the source IP address of 23.1.1.3 to 12.1.1.3, then, R2 consulted its routing table and sent the packet to R1.

R2#show ip route 12.1.1.1

Routing entry for 12.1.1.0/24

Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Serial1/1
Route metric is 0, traffic share count is 1
 Let’s verify that the traffic actually made it to R1. To reveal this fact, let’s enable “debug ip packet det” on

R1, and ping 12.1.1.1 from R3 and examine the output of the debug on R1:

On R1:

R1(config)#no service time debug

R1#debug ip packet detail

IP packet debugging is on (detailed)

On R3:

R3#ping 12.1.1.1 rep 1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 12.1.1.2, timeout is 2 seconds:
.
Success rate is 0 percent (0/1)

Let’s check R1’s console for the debug output:

On R1:

IP: s=12.1.1.3 (Serial1/2), d=12.1.1.1, len 100, input feature, MCI Check(80), rtype 0, forus FALSE,
sendself FALSE, mtu 0, fwdchk FALSE
IP: tableid=0, s=12.1.1.3 (Serial1/2), d=12.1.1.1 (Serial1/2), routed via RIB
IP: s=12.1.1.3 (Serial1/2), d=12.1.1.1 (Serial1/2), len 100, rcvd 3
IP: s=12.1.1.3 (Serial1/2), d=12.1.1.1, len 100, stop process pak for forus packet

IP: s=12.1.1.1 (local), d=12.1.1.3 (Serial1/2), len 100, sending

IP: s=12.1.1.1 (local), d=12.1.1.3 (Serial1/2), len 100, sending full packet

We can see that R1 received the ICMP packet generated by R3; R2 received the packet with a source IP address of 12.1.1.3 (The translated
source IP address of R3), and it replied back with a source IP address of 12.1.1.1 destined to 12.1.1.3. So the problem must be on R2.

So why didn’t R2 send the packet back to R3?

Remember the following important facts:

 When traffic is received on the Outside interface, NAT occurs before routing.
 When traffic is received on the Inside interface, routing occurs before NAT.

When R2 received the traffic from R1 on its Inside interface it looked for a route for 12.1.1.3 destination,

and since it did not see a route for that destination, the packet was dropped, let’s add a static route for 12.1.1.3 destination and verify the
result:

On R2:

R2(config)#ip route 12.1.1.3 255.255.255.255 23.1.1.3

To test the configuration:

On R3:

R3#ping 12.1.1.1 rep 1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 12.1.1.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 60/60/60 ms

Let’s check the NAT translation table:

On R2:

R2#show ip nat translations

Pro Inside global Inside local Outside local Outside global
--- --- --- 12.1.1.3 23.1.1.3
icmp 12.1.1.1:12 12.1.1.1:12 12.1.1.3:12 23.1.1.3:12

But the task stated that static, Dynamic routing or PBR is prohibited, so how are we going to accomplish this task?

This task can be resolved by adding the “Add-route” keyword at the end of the “IP NAT Outside static” statement.

Let’s configure the keyword, remove the static route, and test and verify:

On R2:

R2(config)#ip nat outside source static 13.1.1.3 12.1.1.3 add-route

R2(config)#no ip route 12.1.1.3 255.255.255.255 23.1.1.3

To verify the configuration:

On R2:

R2#show ip route | b Gate

Gateway of last resort is not set

12.0.0.0/8 is variably subnetted, 3 subnets, 2 masks

C 12.1.1.0/24 is directly connected, Serial1/1
L 12.1.1.2/32 is directly connected, Serial1/1
S 12.1.1.3/32 [1/0] via 23.1.1.3
23.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 23.1.1.0/24 is directly connected, Serial1/3
L 23.1.1.2/32 is directly connected, Serial1/3

We can see that the “add-route” keyword added the static route for us, this is highlighted in yellow.

To test the configuration:

On R3:

R3#ping 12.1.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 12.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 80/81/84 ms

On R2:

R2#show ip nat translations

Pro Inside global Inside local Outside local Outside global

--- --- --- 12.1.1.3 23.1.1.3
icmp 12.1.1.1:18 12.1.1.1:18 12.1.1.3:18 23.1.1.3:18

Narbik Kocharians
CCSI#30832, CCIE# 12410 (R&S, SP, Security)
www.MicronicsTraining.com
Sr. Technical Instructor, and a Cisco Press Author
A Cisco Learning Partner