Beruflich Dokumente
Kultur Dokumente
Introduction
This small workbook is meant to provide additional practice with troubleshooting Network Address
Translation (NAT) configurations and is meant as a study tool for the Cisco Certified Ineternetwork
Expert (CCIE) Routing & Switching curriculum.
All labs were created using IOS on Unix (IOU) but can easily be recreated in GNS3 or real equipment.
The interface names may change but the core troubleshooting problems should be unaffected.
The initial configurations are provided in a zip file which will be made available at the same time as
this document. If using IOU, simply create a netmap to look like the diagrams and copy the initial
configurations into each router.
If there are any issues with the workbook please contact me at luke.bibby@gmail.com.
Revision History
Scenario #1
A new site (R1-R2) has been deployed and connected to a local service provider, and been allocated
the public IP address 160.0.23.2.
R2 has been configured to translate the 10.0.12.0/24 address space to the public IP address
configured on R2s E0/1 interface. The configuration however is not working and no users behind R2
have access to R3. Do not configure any additional routes to fix the problem.
You should try to refrain from using show run and show run with filters to isolate the problem.
At the end of the scenario, R3 should see the following when R1 pings R3s E0/0 interface.
R3#debug ip icmp
ICMP packet debugging is on
R3#
*Dec 21 02:12:31.753: ICMP: echo reply sent, src 160.0.23.3, dst 160.0.23.2,
topology BASE, dscp 0 topoid 0
Scenario #2
The administrator of site the R1-R2 site has started the IOS HTTP service on R1 for testing.
R2 has been configured to translate 1.1.1.1/32 to and from the public IP address configured on R2s
E0/1 interface and translate the port address as well. The configuration however is not working and
R3 is unable to access the web service running on R1. Do not configure any static routes to achieve
connectivity.
At the end of the scenario, the following operation should succeed on R3.
R3#telnet 160.0.23.2 80
Trying 160.0.23.2, 80 ... Open
get /
HTTP/1.1 400 Bad Request
Date: Wed, 07 Jan 2015 10:36:01 GMT
Server: cisco-IOS
Connection: close
Accept-Ranges: none
Scenario #3
The administrator of R1 has connected the router to two different providers: ISP-R2 and ISP-R3.
NAT has been configured with the intention that when traffic leaves the private network
(10.0.1.0/24) destined to the loopback at ISP-R2 (2.2.2.2) the source IP address is translated to the
160.0.12.1 address, and when traffic leaves the private network destined to the loopback at ISP-R3
(3.3.3.3) the source IP address is translated to 160.0.13.3. The configuration is not working and it
appears that no translation is occurring at all. The administrator has provided you the following
failed ping to show this.
R1#debug ip nat
IP NAT debugging is on
R1#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
Do not configure any additional static routes or configure dynamic routing to achieve connectivity
(that is, R2 and R3 must not see the internal addressing behind R1). Do not configure any new ACLs.
And the NAT translations table should look similar to the following.
R1#show ip nat translations
Pro Inside global
Inside local
Outside local
Outside global
icmp 160.0.12.1:5
10.0.1.1:5
2.2.2.2:5
2.2.2.2:5
icmp 160.0.13.1:6
10.0.1.1:6
3.3.3.3:6
3.3.3.3:6