IP NAT Troubleshooting. Solutions. Luke Bibby, CCIE #45527

IP NAT Troubleshooting Solutions Luke Bibby, CCIE #45527

Quick Overview of Scenario Solutions Scenario #1 R2 s E0/0 should be NAT inside not NAT outside ACL 100 is configured incorrectly NAT policy missing the inside keyword Scenario #2 RIP is not enabled on 1.0.0.0 on R1 NAT policy missing the inside keyword NAT policy has the inside local and inside global addresses around the wrong way Scenario #3 R1 s Loopback0 needs to be configured as NAT inside NAT policies are referencing non-existant ACLs; should be referencing route maps The route maps have the interfaces configured incorrectly

Scenario #1 Solutions The first thing we should test is that the connectivity between R1 and R3 is infact actually not working using ping. R1#ping 160.0.23.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 160.0.23.3, timeout is 2 seconds:... Success rate is 0 percent (0/5) Do we have NLRI for 160.0.23.3 or a default? R1#show ip route 160.0.23.3 % Network not in table R1#show ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via "static", distance 1, metric 0, candidate default path Routing Descriptor Blocks: * 10.0.12.2 Route metric is 0, traffic share count is 1 And is the next-hop reachable? R1#ping 10.0.12.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.12.2, timeout is 2 seconds:.!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms

At this point we can deduce that there is no apparent problem between R1 and R2 so let s now focus on R2. Let s make sure the inside and outside interfaces are up according to the diagram. R2#show ip interface brief exclude una down Any interface listed with OK? value "NO" does not have a valid configuration Interface IP-Address OK? Method Status Protocol Ethernet0/0 10.0.12.2 YES manual up up Ethernet0/1 160.0.23.2 YES manual up up Let s eliminate a connectivity problem between R2 and R3 using ping. R2#ping 160.0.23.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 160.0.23.3, timeout is 2 seconds:!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms And lastly let s confirm that R3 has no NLRI for the internal private network of R1-R2. R3#show ip route begin Gateway Gateway of last resort is not set 160.0.0.0/16 is variably subnetted, 2 subnets, 2 masks C L 160.0.23.0/24 is directly connected, Ethernet0/0 160.0.23.3/32 is directly connected, Ethernet0/0 Because we are trying to route traffic from a network with a private address space out towards the provider (R3 in this case) we need NAT to translate the private IP addresses into the public IP address space allocated by the provider, 160.0.23.2 in this case. Obviously from the title of this workbook the problem will be with NAT but in the real lab exam Cisco is not going to tell you what

the problem is so it is always good practice to go through the process to identify where the problem might be even if you are told what the problem actually is. The most basic component of a NAT configuration is specifying which interfaces are the inside interfaces and which ones are the outside interfaces (unless NVI is used in which case you just simply enable NAT under the interface). The following command will confirm which interfaces are enabled for NAT. R2#show ip nat statistics Total active translations: 0 (0 static, 0 dynamic; 0 extended) Peak translations: 0 Outside interfaces: Ethernet0/0, Ethernet0/1 Inside interfaces: Hits: 0 Misses: 0 CEF Translated packets: 0, CEF Punted packets: 0 Expired translations: 0 Dynamic mappings: -- Outside Destination [Id: 1] access-list 100 interface Ethernet0/1 refcount 0 Total doors: 0 Appl doors: 0 Normal doors: 0 Queued Packets: 0 Both interfaces are specified as being NAT outside interfaces? Doesn t it make sense that E0/0 should be an inside interface and E0/1 is the outside interface rather than them both being NAT outside interfaces? Let s hypothesize that this is part of the problem and test whether changing the E0/0 configuration to be a NAT inside interface fixes the problem. R2(config)#int e0/0 R2(config-if)#no ip nat outside

R2(config-if)#ip nat inside Then verify our configuration. R2#show ip nat statistics Total active translations: 0 (0 static, 0 dynamic; 0 extended) Peak translations: 0 Outside interfaces: Ethernet0/1 Inside interfaces: Ethernet0/0 Hits: 0 Misses: 0 CEF Translated packets: 0, CEF Punted packets: 0 Expired translations: 0 Dynamic mappings: -- Outside Destination [Id: 1] access-list 100 interface Ethernet0/1 refcount 0 Total doors: 0 Appl doors: 0 Normal doors: 0 Queued Packets: 0 This looks better, let s test out hypothesis from R1. You may be tempted to look for more problems for each ticket on the real lab but in my opinion you should try to do the minimum amount of changes to get solve the problem. Don t go looking for faults that aren t there. R1#ping 160.0.23.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 160.0.23.3, timeout is 2 seconds:... Success rate is 0 percent (0/5)

Still nothing. Let s run a debug on R2 for NAT (note that this command wasn t supported for me on CSR1KV but it works on IOU). R2#debug ip nat IP NAT debugging is on Then try to ping from R1 again. R1#ping 160.0.23.3 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 160.0.23.3, timeout is 2 seconds:. Success rate is 0 percent (0/1) However no debug output showed up on R2 meaning that R2 could not identify a translation policy that matched R1 s traffic to R3. Let s look at the policy on R2. R2#show ip nat statistics Total active translations: 0 (0 static, 0 dynamic; 0 extended) Peak translations: 0 Outside interfaces: Ethernet0/1 Inside interfaces: Ethernet0/0 Hits: 0 Misses: 0 CEF Translated packets: 0, CEF Punted packets: 0 Expired translations: 0 Dynamic mappings: -- Outside Destination [Id: 1] access-list 100 interface Ethernet0/1 refcount 0

Total doors: 0 Appl doors: 0 Normal doors: 0 Queued Packets: 0 If you don t look at this output very often you may miss it but the problem has become apparently when we looked at what the configured NAT translation policy is doing. The configured one is for Outside Destination whereas we want to translate the source IP address from inside local to inside global. If you need a refresher on these terms you can look at the following document. http://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/4606-8.html Before we create a new NAT policy (or change the existing policy), let s confirm that the ACL 100 is matching the traffic that we want. R2#show access-list 100 Extended IP access list 100 10 permit ip 10.0.23.0 0.0.0.255 any Isn t the R1-R2 network 10.0.12.0/24 though? This ACL will never match that traffic. Let s create a new ACL that matches the traffic we actually want, which is IP traffic going from 10.0.12.0/24 to any destination. We could parse the config for any more references to this ACL (class maps, packet filtering, etc) to confirm that this ACL is not used by any other IOS functions, or we could simply just create a new ACL. Before creating it, let s confirm that we are not adding to an existing ACL as follows. R2#show access-list 101 Then create the new ACL. R2(config)#access-list 101 permit ip 10.0.12.0 0.0.0.255 any

Seeing as we now believe the problem to be with the NAT policy configuration, we can use a show run to grab the existing the NAT policy, copy it to notepad (incase it is not actually the fix and you need to reapply the configuration), remove it, and add our new configuration. R2#show run s ip nat ip nat inside ip nat outside ip nat source list 100 interface Ethernet0/1 overload Then remove the configuration. R2(config)#no ip nat source list 100 interface Ethernet0/1 overload Then think about what we want to do: we want to translate the source IP address of inside traffic, which is 10.0.12.0/24, going to any destination out of the outside interface, which is E0/1 (we could also use a pool but its extra configuration that is unnecessary to fix this problem. Using these key pieces of information, we can configure the following (given that we have already configured a new ACL). R2(config)#ip nat inside source list 101 interface Ethernet0/1 overload Let s run the debug on R2 again. R2#debug ip nat IP NAT debugging is on Then try to ping from R1 to R3. R1#ping 160.0.23.3 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 160.0.23.3, timeout is 2 seconds:

! Success rate is 100 percent (1/1), round-trip min/avg/max = 5/5/5 ms And on R2 we notice the following debug output. *Jan 17 02:08:36.626: NAT*: s=10.0.12.1->160.0.23.2, d=160.0.23.3 [17] *Jan 17 02:08:36.628: NAT*: s=160.0.23.3, d=160.0.23.2->10.0.12.1 [17] This is a good because it is showing us that R2 is translating 10.0.12.1 (inside local) to 160.0.23.2 (inside global), and then back again on the return packet. At this point we can consider this ticket solved!

Scenario #2 Solutions The acceptance criteria of this ticket from the perspective of R3 is that it can connect to 160.0.23.2 on TCP port 80 and have the web server present some HTTP response (in this case, we can simply just use GET for the document root). Let s try to test this acceptance criteria as follows. R3#telnet 160.0.23.2 80 Trying 160.0.23.2, 80... % Connection refused by remote host The remote end (R2 in this case) sent back a RST so we can already confirm that connectivity is working to R2, so we can assume basic things like routing, ARP, etc, is working okay. Let s now confirm on R1 that the HTTP service is running and it has NLRI to the outside network. R1#show ip route Codes: L - local, C - connected, S - static, 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 i - IS-IS, su - IS-IS summary, 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, H - NHRP, l - LISP + - replicated route, % - next hop override Gateway of last resort is 10.0.12.2 to network 0.0.0.0 R* 0.0.0.0/0 [120/1] via 10.0.12.2, 00:00:24, Ethernet0/0 1.0.0.0/32 is subnetted, 1 subnets C 1.1.1.1 is directly connected, Loopback0 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C L 10.0.12.0/24 is directly connected, Ethernet0/0 10.0.12.1/32 is directly connected, Ethernet0/0

And now check that the HTTP service is running. R1#show control-plane host open-ports Active internet connections (servers and established) Prot Local Address Foreign Address Service State tcp *:23 *:0 Telnet LISTEN tcp *:8080 *:0 HTTP CORE LISTEN The above command didn t work on CSR1KV but did on IOU, so an alternative command you can use to verify that the port is listening is as follows. R1#show ip http server status HTTP server status: Enabled HTTP server port: 8080 HTTP server active supplementary listener ports: HTTP server authentication method: enable HTTP server digest algorithm: md5 HTTP server access class: 0 HTTP server base path: HTTP server help root: Maximum number of concurrent server connections allowed: 5 Server idle time-out: 180 seconds Server life time-out: 180 seconds Maximum number of requests allowed on a connection: 1 HTTP server active session modules: ALL HTTP secure server capability: Present HTTP secure server status: Disabled HTTP secure server port: 443 HTTP secure server ciphersuite: 3des-ede-cbc-sha des-cbc-sha rc4-128-md5 rc4-128- sha HTTP secure server client authentication: Disabled HTTP secure server trustpoint:

HTTP secure server active session modules: ALL At this point we know two things: 1. R1 is listening on TCP port 8080 2. R3 is attempting to connect to the web service on TCP port 80 using the IP address 160.0.23.3. From this information we can deduce that R2 needs is configured to translate the destination IP address of 160.0.23.2 and TCP port 8080 to R1 on TCP port 80. This is referred to as port address redirection or port forwarding. As we did with the last scenario, let s confirm that there are NAT inside and outside interfaces, or that NVI is configured. R2#show ip nat statistics Total active translations: 1 (1 static, 0 dynamic; 1 extended) Peak translations: 1, occurred 00:00:06 ago Outside interfaces: Ethernet0/1 Inside interfaces: Ethernet0/0 Hits: 0 Misses: 0 CEF Translated packets: 0, CEF Punted packets: 0 Expired translations: 0 Dynamic mappings: Total doors: 0 Appl doors: 0 Normal doors: 0 Queued Packets: 0

According to the diagram and the original HTTP connectivity test we did at the start, this looks okay. We also notice that a static NAT policy exists so let s see what that looks like as follows. R2#show ip nat translations Pro Inside global Inside local Outside local Outside global tcp --- --- 1.1.1.1:8080 160.0.23.2:80 This is saying that R2 is configured to translate between the outside local address of 1.1.1.1 and TCP port 8080 to the outside global address of 160.0.23.3 and TCP port 80. Referring to the documentation and remembering our NAT terms for inside, outside, local, and global, does this configuration make sense? Aren t the addresses 1.1.1.1 (R1 s loopback) and 160.0.23.3 (R2 s interface connected to the R2-R3 network) both considered inside from the perspective of NAT? At this point we can deduce that there is a mistake in the configuration and I am going to purposely use show run here to show why this is often a bad idea to troubleshoot using that command. R2#show run s ip nat ip nat inside ip nat outside ip nat outside source static tcp 160.0.23.2 80 1.1.1.1 8080 extendable Your instincts might be to assume that the sole problem of this configuration is the outside keyword in the NAT policy and that the fix is to replace that keyword with inside. This is because you what you are translating from is usually listed first in the configuration and what you are translating to is listed second. R2(config)#no ip nat outside source static tcp 160.0.23.2 80 1.1.1.1 8080 extendable R2(config)#ip nat inside source static tcp 160.0.23.2 80 1.1.1.1 8080 extendable Now we verify our configuration. R2#show ip nat translations Pro Inside global Inside local Outside local Outside global tcp 1.1.1.1:8080 160.0.23.2:80 --- ---

But this doesn t make sense because 1.1.1.1 is not an address assigned by a provider that represents one or more private hosts to the outside world 160.0.23.2 is. More specifically, 1.1.1.1 is not an inside global address and 160.0.23.2 is not an inside local address; 1.1.1.1 is the inside local address and 160.0.23.2 is the inside global address. Once again, if you used the configuration solely to isolate this problem then you may miss this. The correct configuration is actually as follows. R2(config)#no ip nat inside source static tcp 160.0.23.2 80 1.1.1.1 8080 extendable R2(config)#ip nat inside source static tcp? A.B.C.D Inside local IP address R2(config)#ip nat inside source static tcp 1.1.1.1 8080? A.B.C.D Inside global IP address interface Specify interface for global address R2(config)#ip nat inside source static tcp 1.1.1.1 8080 160.0.23.2 80 extendable Now verify the configuration. R2#show ip nat translations Pro Inside global Inside local Outside local Outside global tcp 160.0.23.2:80 1.1.1.1:8080 --- --- This is looking much better. Let s run the following debug on R2 before testing it out from R3. R2#debug ip nat IP NAT debugging is on Then test from R3.

R3#telnet 160.0.23.2 80 Trying 160.0.23.2, 80... % Connection timed out; remote host not responding This is different to what we saw earlier; we are timing out the connection request rather being refused. Let s see what the debugs on R2 look like. R2# *Jan 17 03:03:07.213: NAT*: TCP s=48361, d=80->8080 *Jan 17 03:03:07.213: NAT*: s=160.0.23.3, d=160.0.23.2->1.1.1.1 [42624] R2# *Jan 17 03:03:09.213: NAT*: TCP s=48361, d=80->8080 *Jan 17 03:03:09.213: NAT*: s=160.0.23.3, d=160.0.23.2->1.1.1.1 [42624] R2# *Jan 17 03:03:13.213: NAT*: TCP s=48361, d=80->8080 *Jan 17 03:03:13.213: NAT*: s=160.0.23.3, d=160.0.23.2->1.1.1.1 [42624] R2# *Jan 17 03:03:21.213: NAT*: TCP s=48361, d=80->8080 *Jan 17 03:03:21.213: NAT*: s=160.0.23.3, d=160.0.23.2->1.1.1.1 [42624] We already confirmed earlier that R1 should has a default route so reachability back to 160.0.23.3 shouldn t be a problem. Can we reach R1 s loopback from R2? R2#show ip route 1.1.1.1 % Network not in table R2#show ip route 0.0.0.0 % Network not in table We could add a static route to R1 s loopback but the scenario already told us that we couldn t do that. We also noticed earlier that R1 was receiving a default route via RIP from R2 so let s see what R1 itself is advertising via RIP.

R1#show ip protocols *** IP Routing is NSF aware *** Routing Protocol is "rip" Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Sending updates every 30 seconds, next due in 6 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Redistributing: rip Default version control: send version 2, receive version 2 Interface Send Recv Triggered RIP Key-chain Ethernet0/0 2 2 Automatic network summarization is not in effect Maximum path: 4 Routing for Networks: 10.0.0.0 Routing Information Sources: Gateway Distance Last Update 10.0.12.2 120 00:00:03 Distance: (default is 120) As it turns out, RIP is the only IGP we are running and it is not advertising the 1.1.1.1/32 network, therefore R2 has no knowledge of how to get to 1.1.1.1 after it translates the destination IP address from 160.0.23.2 to 1.1.1.1. Therefore, it is important to understand here that the NAT operation works but the routing does not. Let s enable RIP on all subnets in 1.0.0.0/8. R1(config)#router rip R1(config-router)#network 1.0.0.0 Wait for the flash update to occur on R1 and for R2 to process and act on the update and once this occurs we can confirm that R2 has NLRI to 1.1.1.1/32

R2#show ip route 1.1.1.1 Routing entry for 1.1.1.1/32 Known via "rip", distance 120, metric 1 Redistributing via rip Last update from 10.0.12.1 on Ethernet0/0, 00:00:19 ago Routing Descriptor Blocks: * 10.0.12.1, from 10.0.12.1, 00:00:19 ago, via Ethernet0/0 Route metric is 1, traffic share count is 1 Now we can retry the test on R3. R3#telnet 160.0.23.2 80 Trying 160.0.23.2, 80... Open GET / HTTP/1.1 400 Bad Request Date: Sat, 17 Jan 2015 03:16:20 GMT Server: cisco-ios Connection: close Accept-Ranges: none 400 Bad Request [Connection to 160.0.23.2 closed by foreign host] At this point we can consider this ticket solved too!

Scenario #3 Solutions The troubleshooting ticket has already indicated that basic connectivity between R1 to R2, and from R1 to R3 is working correctly. The problem occurs when R1 sources a ping from its loopback to either of these routers and we are not allowed to simply advertise the 10.0.1.0/24 through a routing protocol or use static routing to fix the problem. More specifically, the problem occurs when we are trying to source the ping from a private network to a public address space. We can confirm this as follows. R1#ping 2.2.2.2 source loopback0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: Packet sent with a source address of 10.0.1.1... Success rate is 0 percent (0/5) R1#ping 3.3.3.3 source loopback0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds: Packet sent with a source address of 10.0.1.1... Success rate is 0 percent (0/5) Just like in the other scenarios, we first verify which interfaces are configured as NAT inside and outside, or whether NVI has been configured. R1#show ip nat statistics Total active translations: 0 (0 static, 0 dynamic; 0 extended) Peak translations: 0 Outside interfaces: Ethernet0/0, Ethernet0/1 Inside interfaces: Hits: 0 Misses: 0

CEF Translated packets: 0, CEF Punted packets: 0 Expired translations: 0 Dynamic mappings: -- Inside Source [Id: 1] access-list ISPR2 pool ISPR2_POOL refcount 0 pool ISPR2_POOL: netmask 255.255.255.0 start 160.0.12.1 end 160.0.12.1 type generic, total addresses 1, allocated 0 (0%), misses 0 [Id: 2] access-list ISPR3 pool ISPR3_POOL refcount 0 pool ISPR3_POOL: netmask 255.255.255.0 start 160.0.13.1 end 160.0.13.1 type generic, total addresses 1, allocated 0 (0%), misses 0 Total doors: 0 Appl doors: 0 Normal doors: 0 Queued Packets: 0 Immediately we see a problem: there are no inside interfaces. We need to first enable R1 s loobpack0 interface as a NAT inside interface. R1(config)#interface loop0 R1(config-if)#ip nat inside Then verify the result of our configuration. R1#show ip nat statistics Total active translations: 0 (0 static, 0 dynamic; 0 extended) Peak translations: 0 Outside interfaces: Ethernet0/0, Ethernet0/1

Inside interfaces: Loopback0 Hits: 0 Misses: 0 CEF Translated packets: 0, CEF Punted packets: 0 Expired translations: 0 Dynamic mappings: -- Inside Source [Id: 1] access-list ISPR2 pool ISPR2_POOL refcount 0 pool ISPR2_POOL: netmask 255.255.255.0 start 160.0.12.1 end 160.0.12.1 type generic, total addresses 1, allocated 0 (0%), misses 0 [Id: 2] access-list ISPR3 pool ISPR3_POOL refcount 0 pool ISPR3_POOL: netmask 255.255.255.0 start 160.0.13.1 end 160.0.13.1 type generic, total addresses 1, allocated 0 (0%), misses 0 Total doors: 0 Appl doors: 0 Normal doors: 0 Queued Packets: 0 Let s see if this has fixed the problem using a general NAT debug and ping. R1#debug ip nat IP NAT debugging is on R1#ping 2.2.2.2 source loopback0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: Packet sent with a source address of 10.0.1.1... Success rate is 0 percent (0/5)

However we saw nothing in the debug output so this is leaning us towards a problem with the NAT policy configuration. You are probably getting sick of this command already but it is useful for troubleshooting NAT! R1#show ip nat statistics Total active translations: 0 (0 static, 0 dynamic; 0 extended) Peak translations: 0 Outside interfaces: Ethernet0/0, Ethernet0/1 Inside interfaces: Loopback0 Hits: 0 Misses: 0 CEF Translated packets: 0, CEF Punted packets: 0 Expired translations: 0 Dynamic mappings: -- Inside Source [Id: 1] access-list ISPR2 pool ISPR2_POOL refcount 0 pool ISPR2_POOL: netmask 255.255.255.0 start 160.0.12.1 end 160.0.12.1 type generic, total addresses 1, allocated 0 (0%), misses 0 [Id: 2] access-list ISPR3 pool ISPR3_POOL refcount 0 pool ISPR3_POOL: netmask 255.255.255.0 start 160.0.13.1 end 160.0.13.1 type generic, total addresses 1, allocated 0 (0%), misses 0 Total doors: 0 Appl doors: 0 Normal doors: 0 Queued Packets: 0

If we consider the first one isolation (ID of 1), it is referencing an ACL called ISPR2 for matching traffic and is translating it to an IP address in the pool called ISPR2_POOL. We can already see from above that the ISPR2_POOL has the range of 160.0.12.1 to 160.0.12.1, which is the IP address configured on R1 s E0/0 interface. Let s confirm the ACL now. R1#show access-list ISPR2 Noting shows up. Do we have any access-lists at all (i.e. maybe they are configured but are referenced incorrectly)? R1#show access-lists So we have multiple NAT pools but do not have any criteria to select which one to use. The answer to this fix is route maps. The NAT policy configuration should be referencing route maps here, selecting on the ACLs or the outgoing interface. Because we cannot configure any new ACLs, we must use route maps where we can match on the outgoing interface or next-hop of the traffic to select which NAT pool to use. Let s confirm whether any route maps have been configured. R1#show route-map route-map ISPR2, permit, sequence 10 Match clauses: interface Ethernet0/1 Set clauses: Policy routing matches: 0 packets, 0 bytes route-map ISPR3, permit, sequence 10 Match clauses: interface Ethernet0/0 Set clauses: Policy routing matches: 0 packets, 0 bytes

We can see what the network administrator has done here. They have referenced ISPR2 and ISPR3 as an ACL when they should have been referenced as a route map. Let s grab the configuration and change the reference to an ACL to reference a route map. R1#show run s ip nat ip nat inside ip nat outside ip nat outside ip nat pool ISPR2_POOL 160.0.12.1 160.0.12.1 netmask 255.255.255.0 ip nat pool ISPR3_POOL 160.0.13.1 160.0.13.1 netmask 255.255.255.0 ip nat inside source list ISPR2 pool ISPR2_POOL ip nat inside source list ISPR3 pool ISPR3_POOL Then remove the existing policies. R1(config)#no ip nat inside source list ISPR2 pool ISPR2_POOL R1(config)#no ip nat inside source list ISPR3 pool ISPR3_POOL Then we simply use the same commands as above except that we change the list keyword to route-map. R1(config)#ip nat inside source route-map ISPR2 pool ISPR2_POOL R1(config)#ip nat inside source route-map ISPR3 pool ISPR3_POOL Now we run a generalised NAT debug and try to test the original pings again. R1#debug ip nat IP NAT debugging is on R1#ping 2.2.2.2 source loopback0 repeat 1 Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: Packet sent with a source address of 10.0.1.1. Success rate is 0 percent (0/1) *Jan 17 03:58:04.926: NAT: s=10.0.1.1->160.0.13.1, d=2.2.2.2 [20] Hmm, that didn t work. Let s see what happens when we try to ping R3. R1#ping 3.3.3.3 source loopback0 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds: Packet sent with a source address of 10.0.1.1. Success rate is 0 percent (0/1) *Jan 17 03:59:34.822: NAT: s=10.0.1.1->160.0.12.1, d=3.3.3.3 [21] Can you see what the problem is? If you aren t used to the above debug output maybe the following will make it clearer on R2. R2#debug ip icmp ICMP packet debugging is on Then run the test again on R1 to R2. R1#ping 2.2.2.2 source loopback0 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: Packet sent with a source address of 10.0.1.1. Success rate is 0 percent (0/1)

And observe the debug output on R2. R2# *Jan 17 04:01:48.323: ICMP: echo reply sent, src 2.2.2.2, dst 160.0.13.1, topology BASE, dscp 0 topoid 0 The source IP address on R1 is being translated from 1.1.1.1 to 160.0.13.1, which is the IP address on the R1-R3 segment, and a similar thing is happening when R1 pings R3 because the source IP address is being translated from 1.1.1.1 to 160.0.12.1 which is the IP address configured on R1 s E0/0 interface on the R1-R2 segment. That is, the route map is configured incorrectly. R1#show route-map route-map ISPR2, permit, sequence 10 Match clauses: interface Ethernet0/1 Set clauses: Policy routing matches: 0 packets, 0 bytes route-map ISPR3, permit, sequence 10 Match clauses: interface Ethernet0/0 Set clauses: Policy routing matches: 0 packets, 0 bytes If we compare this to the IP addresses configured on the interfaces, which are as follows. R1#show ip interface brief exc una down Interface IP-Address OK? Method Status Protocol Ethernet0/0 160.0.12.1 YES manual up up Ethernet0/1 160.0.13.1 YES manual up up Loopback0 10.0.1.1 YES manual up up NVI0 10.0.1.1 YES unset up up

We can see that the route maps have the wrong outgoing interfaces. The ISPR2 route map should be referencing E0/0 and the ISPR3 route map should be referencing E0/1. Let s fix this as follows. R1(config)#route-map ISPR2 permit 10 R1(config-route-map)#no match interface R1(config-route-map)#match interface E0/0 R1(config)#no route-map ISPR3 permit 10 R1(config)#route-map ISPR3 permit 10 R1(config-route-map)#match interface E0/1 Note that there are a few ways you can change the configuration. Let s now verify the configuration on R1 when it tries to ping R2 and R3 sourcing the packet from its loopback interface. R1#ping 2.2.2.2 source loopback0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: Packet sent with a source address of 10.0.1.1!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms R1#ping 3.3.3.3 source loopback0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds: Packet sent with a source address of 10.0.1.1!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms Then as a final check verify the NAT translation table as follows. R1#show ip nat translations

Pro Inside global Inside local Outside local Outside global icmp 160.0.12.1:11 10.0.1.1:11 2.2.2.2:11 2.2.2.2:11 icmp 160.0.13.1:12 10.0.1.1:12 3.3.3.3:12 3.3.3.3:12 Which looks good!