Solution to Configuration Exercise 1-2: NAT Using Access Lists and Route Maps
This section provides the answers to the questions in the Configuration Exercise.
NOTE
Some answers provided cover multiple steps; the answers are given after the last step for which that answer applies.
Solution to Task 1: Connecting the Internal Router to the Edge Router
|
Step 1 |
The internal routers (PxR3 and PxR4) should not have a configuration. If a configuration is present, use the erase start and reload commands to clear the configuration and reload the router. |
|
Step 2 |
Connect to your internal routers. Supply an IP address to the Ethernet interface, and enable the interface. The Ethernet address of PxR3 should be 10.x.1.3/24, and the Ethernet address of PxR4 should be 10.x.2.4/24. |
Solution:
The following example shows the configuration of P1R3:
The following example shows the configuration of P1R4:
|
Step 3 |
PxR1 has an Ethernet address of 10.x.1.1, and PxR2 has an Ethernet address of 10.x.2.2. Verify connectivity to the Ethernet-attached edge router from each internal router. |
Solution:
To verify connectivity, the edge routers are pinged from the appropriate internal router.
The following output is from the P1R3 router. The ping was successful.
The following output is from the P1R4 router. The ping was successful.
Solution to Task 2: Setting Up ACL-Based NAT
NOTE
BBR1 has static routes for 192.168.x.0/24 and 192.168.xx.0/24. It does not have any remote routes for the pod 10.x.0.0 addresses, only its local TFTP server network 10.254.0.0.
|
Step 1 |
On the PxR1 and PxR2 routers, configure the sources to be translated using extended access list 100. Access list 100 should match traffic sourced from the network on your edge router's Ethernet interface, destined for the network that the TFTP server is located on. For example, PxR1 should match traffic sourced from 10.x.1.0/24, and PxR2 should match traffic sourced from 10.x.2.0/24. The access list must match only packets with a destination of 10.254.0.0/24. |
|
Step 2 |
On the PxR1 and PxR2 routers, create a pool of addresses called BBR for use by NAT, using the ip nat pool command. PxR1 should use the address range of 192.168.x.0/24, and PxR2 should use 192.168.xx.0/24. For example, P2R1 would use 192.168.2.1 through 192.168.2.254, and P2R2 would use 192.168.22.1 through 192.168.22.254. |
|
Step 3 |
On the PxR1 and PxR2 routers, use the ip nat inside source list command to specify that packets that match access list 100 should have their source addresses translated into the BBR pool. |
|
Step 4 |
On the PxR1 and PxR2 routers, define which interfaces are inside or outside for NAT translation purposes. |
Solution:
Because the traffic to be translated will come from the Ethernet interface, that will be the inside NAT interface. Translated traffic will leave via the Serial0 interface, so S0 will be the outside interface for NAT purposes. The following example shows the configuration on the P1R1 router:
|
Step 5 |
On the PxR3 and PxR4 routers, configure a default route pointing to the attached edge router e0 interface. This configuration allows the internal router to reach the core network. |
Solution:
The following example shows the configuration on the P1R3 router:
|
Step 6 |
From the PxR3 and PxR4 routers, verify connectivity to the TFTP server (10.254.0.254) using the ping command. |
Solution:
The following output shows the result of the ping command on the P1R3 router; the ping is successful.
CAUTION
You will not be able to reach the TFTP server if the NAT translation is not done correctly.
|
Step 7 |
View the NAT translation table on the edge router (PxR1 and PxR2). |
Solution:
The following output shows the NAT translation table on the P1R1 router. From this output, you can see that one address has been translated.
Solution to Task 3: Translating to the Other Edge Router
|
Step 1 |
On the PxR1 and PxR2 routers, configure the source addresses to be translated using extended access list 101. Access list 101 should match traffic sourced from the network on your edge router's Ethernet interface, bound for any destination. For instance, PxR1 should match traffic from 10.x.1.0/24, and PxR2 should match traffic from 10.x.2.0/24. The access list must match packets with a destination to any network. |
|
Step 2 |
On the PxR1 and PxR2 routers, create a pool of addresses named POD for use by NAT. PxR1 should use the address range 10.x.0.64 to 10.x.0.95, and PxR2 should use the address range 10.x.0.96 to 10.x.0.127. |
|
Step 3 |
On the PxR1 and PxR2 routers, specify that packets that match access list 101 should have their source addresses translated into the POD pool. |
|
Step 4 |
At the PxR1 and PxR2 routers, define the S1 interface of each router as the NAT outside interface by using the ip nat outside command so that traffic from the respective internal routers is translated. |
Solution:
The following example shows the configuration of the P1R1 and P1R2 routers:
|
Step 5 |
From one internal router, ping the Serial 1 interface of the nonconnected edge router. (For example, from PxR3, ping the Serial 1 address of PxR2.) Is the ping successful? |
Solution:
The following example is a ping from the P1R3 router to the P1R2 router's Serial 1 address:
The ping is unsuccessful.
|
Step 6 |
Look at the IP translation table on the edge routers to help explain the result of the previous ping. |
Solution:
The following output is from the P1R1 router:
As you can see in the translation table, the P1R1 router has already translated the 10.1.1.3 source address, in Task 2, to 192.168.1.1. The router doesn't recognize that ping is a separate conversation, to a different destination, so it doesn't translate the traffic again for the new destination. You need a way to distinguish between different conversations.
|
Step 7 |
From the nonconnected edge router, use the debug ip icmp and debug ip packet commands while the pings are still active. Observe the output to help explain the results of the previous ping. Turn off all debugging when you are |
finished.
Solution:
The following output is from the P1R2 router while the pings from P1R3 to the P1R2 Serial 1 address are ongoing:
P1R2 receives a packet with source address 192.168.1.1 and tries to reply to this packet. However, P1R2 reports that 192.168.1.1 is unroutable.
|
Step 8 |
Look at the routing table on the nonconnected edge router. Is there a route back to the destination address of the ping echo reply message? |
Solution:
The following output is from the P1R2 router:
There is no route in P1R2's routing table to 192.168.1.1; this is why P1R2 cannot reply to the ping.
|
Step 9 |
What does a router do when it does not find an appropriate address? |
Solution:
The router drops the packet.
Solution to Task 4: Using a Route Map with NAT to Translate Internal Addresses
|
Step 1 |
Create a route map that will be used to conditionally translate traffic based on the packet's destination. |
Solution:
The following example shows the configuration on P1R1:
|
Step 2 |
Replace the translation commands from Task 3 with route map-based commands to perform the required translation. |
|
|
If the router reports "%Dynamic mapping in use, cannot remove," simply go to privileged mode and enter the clear ip nat translation * command to remove all mappings. You then can configure the router. |
Solution:
The following configuration is from the P1R1 router:
|
Step 3 |
Ping from one internal router to the opposite edge router and to the TFTP server to verify that the previous step was successful. Turn on debug ip nat detailed debugging on the edge routers to see the translation. |
Solution:
The following ping output is from the P1R3 internal router to the TFTP server. (The P1R4 internal router produced the same result.)
The following debug output is from the P1R1 router while the preceding ping from P1R3 to the TFTP server was ongoing. This output shows the translation using the BBR pool:
The following ping output is from the P1R3 internal router to the P1R2 router's Serial 1 interface. (The same results were obtained when P1R4 pinged the P1R1 router Serial 1 interface.)
The following debug output is from the P1R1 router while the preceding ping from P1R3 to P1R2 was ongoing. This output shows the translation using the POD pool:
|
Step 4 |
Use the show ip nat translations command on each edge router to see the resulting NAT translation table. |
Solution:
The following output is from the P1R1 and P1R2 routers:
Notice that the NAT translation table is completely developed. The inside and outside local and global addresses are included in the table, along with the TCP and UDP port numbers. Much more troubleshooting information is available within this table than with the table shown in Task 3.
Solution to Task 5: Downloading a Configuration File
On the internal routers, use TFTP to download the configuration file called PxRy.txt from the TFTP server to the running-config.
Solution:
The following configuration and output are from the P1R3 router. Notice that the router's name, P1R3, is configured after the configuration is downloaded:
The following configuration and output are from the P1R4 router. Again, notice that the router's name changes after the configuration is loaded:
NOTE
The configurations for PxR3 and PxR4 include the command no ip classless in preparation for the Configuration Exercise in the next chapter. If you try to communicate with the TFTP server now, it will not work. The reasoning behind this behavior is examined in the next Configuration Exercise.
Exercise Verification
You have successfully completed this exercise when you achieve the following results:
Your internal router can ping the TFTP server using a translation to 192.168.x.0/24.
Your internal router can ping the opposite edge router using a translation to 10.x.0.0/24.
You have demonstrated the limitations of access list-based NAT and have overcome those limitations by configuring NAT using a route map.
You have connected to the TFTP server through NAT and have downloaded a configuration file for your internal routers.