Books
Advanced IP Routing in Cisco Networks
Chapter 7 - Network Address Translation
Network Address Translation (NAT) is an IP feature added in Cisco IOS 11.2 that provides for translating IP addresses. To make sure that this feature is available on your model 25xx router and above make sure that your IOS code has the s designator in the IOS code.
There are several different reasons for using the Network Address Translation feature; private network addressing on your internal network, connecting to your Internet Service Provider with an unassigned but valid IP class address, integrating two companies that use the same private address space, and TCP load sharing among multiple hosts. Network Address Translation is defined in RFC-1631, The IP Network Address Translator (NAT).
What NAT Provides
Network Address Translation provides a method for disguising the internal nature of your private network by using an external address to represent your network addressing to the outside world.
What NAT Does Not Provide
Network Address Translation does not provide any firewall services. While the addition of access lists to a router can improve security and bandwidth utilization, it should not be considered a firewall solution.
Terms
Before we can configure NAT there are some terms we need to define in order to understand the process being executed. Please refer to Figure 7-1 for the following term definitions
**B013.cdr Figure 7-1 Nat Terminology**
Inside Local Addresses
Inside addresses are addresses used within an autonomous system. An example of an inside address would be class A address 10.0.0.0 used within your private network, or a globally routable class address not a legitimate IP address assigned by the Network Information Center (NIC) or a service provider. In Figure 7-1 Host A has been assigned an inside local address of 10.0.1.1.
Inside Global Addresses
An inside global address is a legitimate IP address (assigned by the NIC or service provider) that represents one or more inside local IP addresses to the outside world. In Figure 7-1, 192.1.1.254, is the IP address used by Host A to communicate with the outside.
Outside Local Addresses
An outside local address is the IP address of an outside host as it appears to the inside network. Not necessarily a legitimate address, it was allocated from address space routable on the inside. In Figure 7-1, 10.0.1.254 is the address that Host B uses for all communications on the inside of our private network.
Outside Global Addresses
The IP address assigned to a host on the outside network by the host's owner. The address was allocated from globally routable address or network space. In Figure 7-1, 192.1.1.1 represents Host B to the outside address space.
Simple Translation
Provides a one to one address mapping, where one inside local address requires one inside global address in order to work properly. An example would be a private Inside Local Address using class C network 192.168.1.0 with valid class C address 200.20.45.0 as an Inside Global Address for up to 254 simultaneous connections.
Address Overloading
Provides the ability to use one outside address to replace multiple inside addresses by mapping conversations by port numbers as well as addresses. An example would be a private Inside Local Address using class A network 10.0.0.0 with valid class C address 200.20.45.0 as a Inside Global Address for more than 254 simultaneous connections. Each connection uses random inside global addresses with the original port address used by the inside local address. If we track two separate conversations from 10.1.0.1 port 1028 and 10.1.0.2 port 1042, then the inside global addresses could be 200.20.45.17 port 1028 and 200.20.45.17 port 1042. The router keeps track of these conversations. Example #2 will use this address overload feature to communicate with the outside.
Scenarios
Private Addresses
When the Internet became the "in" technology, the rush for acquiring valid IP Class addresses threatened to exhaust the networks available for distribution. Proposals for address extensions like IPng were consolidated into a new standard for IP addressing, Ipv6. All standards take time to be accepted and implemented, and in the interim RFC-1918 defines the use of class A 10.0.0.0, class B addresses 172.16.0.0 through 172.31.255.255, and class C addresses 192.168.0.0 through 192.168.255.255 as internal or private network addresses for companies and organizations. To connect to the Internet a registered class address must be used for connectivity, and Network Address Translation is used to map inside private or local addresses to outside global addresses. See Example #1 for the configuration commands used to implement this feature.
If two companies use the same private addresses and they merge, this same feature can be used to connect the two organizations together. See Example #3 for the configuration commands used to implement this feature.
Switching ISPs
With the rapid expansion in the service provider business, if one service provider is not fulfilling your needs, then you may decide to switch. Many class addresses are being distributed through service providers and your global IP address may have to be returned to the provider. This requires that your internal addressing be completely changed to a new address space. While this address change is being planned, using Network Address Translation can give you breathing room by translating your old global addresses into the new address. See Example #2 for the configuration commands used to implement this feature.
TCP Load Sharing
Providing services to users may require multiple servers. To make multiple servers appear as one server to your users, Network Address Translation can be used to map multiple individual host addresses to a single virtual address used by the rest of the network. See Example # 4 for the configuration commands used to implement this feature.
Configuring Address Translation
The following commands are used to implement the Network Address Translation feature, the G/I column indicates whether the command is global or applied to the interface. Information supplied by the user is italicized.
| Command | G/I | Parameter | Description |
| ip nat pool | G | name | Name of the pool of addresses to be used during translation. |
| start-ip | First address in range. | ||
| end-ip | Last address in range. | ||
| netmask netmask or prefix-length prefix-length | Netmask in dotted decimal or prefix length in bits to be applied to the addresses. | ||
| type rotary | Optional parameter to identify real inside hosts used for TCP load distribution. | ||
| ip nat inside source | G | list name or list number | The named or numbered Standard access-list that identifies the source addresses that are dynamically translated using addresses from the named NAT pool. |
| pool name | Name of the pool from which global addresses are assigned dynamically. | ||
| overload | Optional parameter that allows NAT to map a combination of port and a single global IP address to multiple inside addresses. | ||
| ip nat inside source | G | static local-ip | Inside local address that maps to a specific outside global address. Only one address per command. |
| global-ip | The global address statically mapped to an inside address | ||
| ip nat outside source | G | list name or list number | The named or numbered Standard access-list that identifies the source addresses that are dynamically translated using addresses from the named pool. |
| Pool name | Name of the pool from which global addresses are assigned dynamically. | ||
| ip nat outside source | G | static global-ip | Outside global address that maps to a specific inside local address. Only one address per command. |
| local-ip | The local address statically mapped to a global address. | ||
| ip nat inside destination | G | list name or list number | The named or numbered Standard access-list that identify the destination addresses that are dynamically translated using addresses from the named pool. |
| pool name | Name of the pool from which global addresses are assigned dynamically. | ||
| ip nat | I | inside | Indicates translation takes place between the inside addresses on this interface, and outside addresses on designated outside interfaces. |
| I | outside | Indicates translation takes place between the outside addresses on this interface, and inside addresses on designated inside interfaces. | |
| ip nat translation | G | timeout seconds or udp-timeout seconds or dns-timeout seconds or tcp-timeout seconds or finrst-timeout seconds |
Dynamic = 86400 (24 hours) UDp port = 300 DNS connections = 60 TCp port = 86400 (24 hours) Finish and Reset TCp packets = 60 |
Configuration Examples
Example #1- Access the Internet Using a Private Internal IP Network Number
This example provides the network administrator with an easy to use technique that translates internal private network numbers into valid Internet addresses. Figure 7-2 is the network layout for this example. In this example 200.200.200.0 is the valid class C address used to represent our private address to the outside world.
**B014.cdr Figure 7-2 Private Addresses With Simple NAT Translation**
Tokyo is a router in the outside domain that uses a valid IP network of 131.108.0.0 and the RIP routing protocol. See lines 13 and 14 in Figure 7-3.
**natex1tok-cfg Figure 7-3 Tokyo Configuration**
Just to verify our RIP operation does not see any of the private network 10.0.0.0 addressing we execute a debug ip rip command. The only networks known by the router are valid outside network addresses, see lines 5 and 6 in Figure 7-4.
**natex1tok-deb Figure 7-4 Tokyo Debug IP RIP Output**
The show ip protocol output for Tokyo in Figure 7-5 shows network 131.108.0.0 as the only network being processed, see line 13.
**natex1tok-sprot Figure 7-5 Tokyo Show IP Protocol Output**
The show ip route output for Tokyo in Figure 7-6, shows subnetwork 200.200.200.0/24 as a RIP derived route.
**natex1tok-srout Figure 7-6 Tokyo Show Ip Route Output**
The configuration for NewYork in Figure 7-7, is where Network Address Translation takes place.
Line 4 defines a pool of valid outside addresses, and line 5 assigns this pool of addresses for translating the inside source addresses that pass access-list 1 on line 26.
Line 13 defines traffic coming from the inside private network 10.0.0.0 as the source addresses to be translated into the 131.108.0.0 network as network 200.200.200.0.
Line 18 defines the interface where the translated addresses are sent out to the outside network.
Lines 22 through 27 provide our RIP routing function. Networks 10.0.0.0, 200.200.200.0 and 131.108.0.0 participate in the RIP routing process.
On line 26 the distribute-list out 2 command is used so that network 131.108.0.0 will show up in our private network. Addresses that pass access-list 2 on line 31 will be forwarded to our private network. See Figure 7-15 for the sample show ip route for London later in this example.
On line 27 the distribute-list out 3 command is used to prevent network 10.0.0.0 from showing up in the global network routing updates. Addresses that pass access-list 3 on lines 32 and 33 will be forwarded to the global network. See Figure 7-4 for the debug ip rip output to verify this operation.
Line 25 is used to propagate network 200.200.200.0/24 in the RIP updates headed to the global 131.108.0.0 domain. NAT converts these addresses to our private addresses as they enter the router on Serial 1.
**natex1new-cfg Figure 7-7 NewYork Configuration**
Sample output from the debug ip nat command is in Figure 7-8. Line 4 shows our initial translation from 10.0.2.2 to 200.200.200.2 on the first outgoing ping request. Lines 5 through 14 show the rest of the successful ping translation sequence. The * after NAT indicates that the translation took place along the fast switching path. Lines 14 through 23 show a second ping sequence using a different address where the translated address is the next address ion the pool, 200.200.200.3.
**natex1new-deb Figure 7-8 NewYork Debug Output**
Figure 7-9 contains the show ip nat translation on lines 1 through 5.
Lines 6 through 17 contain the show ip nat statistics output.
Line 7 shows two dynamic translations, and line 17 shows two of the 253 addresses available.
**natex1new-show Figure 7-9 NewYork Show Command Output**
The clear options for NAT show up in Figure 7-10.
Lines 1 through 3 identify clearing options for statistics and translations.
Lines 5 through 10 identify the options for clearing the translation table.
Lines 12 and 13 show the results of the clear ip nat translation *.
Lines 14 through 25 show us the current show ip nat statistics output where the dynamic translations active in Figure 7-9 have been cleared.
**natex1new-clear Figure 7-10 NewYork Clear Command Output**
Figure 7-11 is the show ip protocol output for NewYork. Lines 16 through 18 identify networks 131.108.0.0, 200.200.200.0 and 10.0.0.0 and the associated interfaces as participants in the RIP protocol.
Line 6 identifies RIP routing updates exiting interface Serial0 as being filtered by access-list 2, which permits only network 131.108.0.0, all other networks will be blocked as the are sent into our private network.
Line 7 identifies RIP routing updates exiting interface Serial1 as being filtered by access-list 3, which permits networks 131.108.0.0 and 200.200.200.0, while private network 10.0.0.0 is blocked for updates sent to our global network.
**natex1new-sprot Figure 7-11 NewYork Show IP Protocol Output**
Figure 7-12 is the show ip route output that indicates that networks 10.0.0.0, 200.200.200.0, and network 131.108.0.0 are reachable from NewYork.
**natex1new-srout Figure 7-12 NewYork Show IP Route Output**
Figure 7-13 is the London configuration, no surprises, basic IP RIP networking.
**natex1lon-cfg Figure 7-13 London Configuration**
Figure 7-14 is a sample extended ping output, available in the privileged mode.
Lines 1 through 11 show a successful attempt to ping 131.108.2.1 using the standard source address 10.0.2.2, the exit interface IP address from London
Lines 13 to 30 show a successful ping, when source address 10.0.1.1 is used, as it belongs to the translated subnet.
**natex1lon-ping Figure 7-14 London Ping Test Output**
Figure 7-15 is the show ip protocol output that shows basic IP RIP for network 10.0.0.0.
**natex1lon-sprot Figure 7-15 London Show IP Protocol Output**
Figure 7-16 is the show ip route output that shows directly connected 10.0.0.0 interfaces, and network 131.108.0.0 addresses are being learned via the RIP protocol, line 14, from NewYork.
**natex1lon-sroutFigure 7-16 London Show IP Route Output**
Example #2- Access the Internet Using an Illegal Internal IP Network Number
This example provides the network administrator with an easy to use technique that translates internal illegal network numbers into valid Internet addresses. Figure 7-17 is the network layout for this example. In this example 200.200.200.0 is the valid class C address used to represent our illegal address to the outside world. The main problem with illegal addresses, is that we cannot access an outside address in the global address space that matches up to our internal illegal address. In order for this process to work, we must define static mapping of our outside global addresses to outside local addresses visible to our inside network.
If we are using Domain Name Services(DNS) from the outside, NAT will intercept the DNS responses and change the outside global address in the DNS packet payload to the translated outside local address.
**B016.cdr Figure 7-17 Illegal Addresses With Simple NAT Translation**
Tokyo is a router in the outside domain that uses a valid IP network of 131.108.0.0 and the RIP routing protocol. See lines 13 and 14 in Figure 7-18.
Line 17 is a static route that identifies the default route for all unknown networks to be out Serial 0. Network 144.251.0.0 is an intermediate network used to simulate an external connection to the internet.
**natex2tok-cfg Figure 7-18 Tokyo Configuration**
The show ip protocol output for Tokyo in Figure 7-19 shows network 131.108.0.0 as the only network being processed, see line 12.
**natex2tok-sprot Figure 7-19 Tokyo Show IP Protocol Output**
The show ip route output for Tokyo in Figure 7-20, shows subnetwork 0.0.0.0 as a static default route.
**natex2tok-srout Figure 7-20 Tokyo Show Ip Route Output**
The configuration for NewYork in Figure 7-21, is where Network Address Translation takes place.
Line 4 defines a pool of valid outside addresses, and line 5 assigns this pool of addresses for translating the inside source addresses that pass access-list 1 on line 26.
Line 6 provides a static map to force a specific inside global address, 131.108.2.1 to be mapped to 200.200.200.1for all communications with the outside domain. Any outside device that wishes to reach our internal address of 131.108.2.1 must use the specific address of 200.200.200.1.
Line 7 provides a static map to force the outside global address 131.108.2.1 to be mapped to 200.200.200.254 for all communications with the inside domain.
Lines 6 and 7 allow the two hosts with the IP address 131.108.2.1 to communicate using this static translation.
Line 12 defines traffic coming from the inside illegal network 131.108.0.0 as the source addresses to be translated into the outside global domain as network 200.200.200.0.
Line 17 defines the interface where the translated addresses are sent out to the outside network.
**natex2new-cfg Figure 7-21 NewYork Configuration**
Figure 7-22 shows the initial show ip nat statistics output in line1 through 12, and the show ip nat translation on lines 13 through 16.
**natex2new-show-base Figure 7-22 Show Initial Show Command Output**
Sample output from the debug ip nat command is in Figure 7-23. Lines 1 and 2 shows translation from 131.108.3.2 to 200.200.200.5 on the first ping request to address 144.251.1.1. Lines 2 through 10 show the rest of the successful ping translation sequence. There is a single translation from the inside to a normal outside address.
Lines 11 through 14 show the first message in our second ping sequence using our inside address of 131.108.2.1 as it attempts to contact the outside host with the same 131.108.2.1 address. With our static mapping in place we go through a two step translation process in both directions. Line 11 translates our source address of 131.108.2.1 to 200.200.200.1. Line 12 translates the destination address of 200.200.200.254 to the valid outside address of 131.108.2.1. Lines 13 and 14 demonstrate the reverse translation from the outside domain into our illegal address space.
**natex2new-deb Figure 7-23 NewYork Debug Output**
Figure 7-24 shows the show ip nat statistics command output on lines 1 through 12, and the show ip nat translation command output on lines 14 through 19.
Line 2 shows us that there are two static and two dynamic translations currently operating. Line 12 shows us that only one of the dynamic addresses is being used, what is the other dynamic map? Read on.
Line 16 is the static map from the inside local address of 131.108.2.1 to inside global address of 200.200.200.1.
Line 17 is the dynamic map we used to contact outside local network 144.251.1.1, where our inside local address of 131.108.3.2 was mapped to our outside global address of 200.200.200.5, the first address in our pool.
Line 18 is the static map from the outside local address of 200.200.200.254 to the outside global address of 131.108.2.1.
Line 19 is the dynamic map built when the two address 131.108.2.1 hosts communicate with each other.
**natex2new-show Figure 7-24 NewYork Show Command Output**
Figure 7-25 is the show ip protocol output for NewYork, basic RIP routing.
**natex2new-sprot Figure 7-25 NewYork Show IP Protocol Output**
Figure 7-26 is the show ip route output that shows network 131.108.2.0 RIP derived from London on line 15. There is a default static route identifying the destination as the router connected on the serial 1 interface.
**natex2new-srout Figure 7-26 NewYork Show IP Route Output**
Figure 7-27 is the London configuration, no surprises, basic IP RIP networking.
**natex2lon-cfg Figure 7-27 London Configuration**
Figure 7-28 is sample ping output to a normal global address 144.251.1.1 on lines 1 through 6, and an extended ping output on lines 7 through 24.
Lines 1 through 6 show a successful attempt to ping 144.251.1.1 using the standard source address 131.108.3.2, the exit interface IP address from London
Lines 7 to 24 show a successful ping, when source address 131.108.2.1 is used with the target address of 200.200.200.254, our outside local representation of the outside host with address 131.108.2.1.
**natex2lon-ping Figure 7-28 London Ping Test Output**
Figure 7-29 is the show ip protocol output that shows basic IP RIP for network 131.108.0.0.
**natex2lon-sprot Figure 7-29 London Show IP Protocol Output**
Figure 7-30 is the show ip route output that shows directly connected network 131.108.0.0 addresses and a default route directed out interface serial 1 headed to NewYork.
**natex2lon-srout Figure 7-30 London Show IP Route Output**
Example #3- Combine Two Address Domains, Two Contact Points
This example ties together two different Address domains that use the same private address 10.0.0.0. The network layout is shown in Figure 7-31. The EIGRP 200 network consisting of Tokyo, London, and NewYork, is the outside network. The OSPF network consisting of Moscow, Paris, and Rome, is the inside network. With two contact points it appears that we have the best of all worlds, address translation, load balancing for IP traffic, and backup if one of the connection points should fail.
Danger Will Robinson! All is not as it appears. After reviewing the following example, see if you can find the hidden bombs. The answer is at the end of the chapter.
**B017.cdr Figure 7-31 Combine Two Networks, Dual Connection Points**
Figure 7-32 is the configuration for Tokyo. This as an internal EIGRP router with the Ethernet 0 address of 10.1.1.1 statically mapped in the Moscow and Paris configurations, our two contact points.
**natex3tok-cfg Figure 7-32 Tokyo Configuration**
The translation test ping 192.168.3.1 is shown in Figure 7-33. The destination address is statically mapped to an inside global address in order to succeed.
**natex3tok-ping Figure 7-33 Tokyo Ping Output**
Figure 7-34 shows the basic EIGRP routing process for network 10.0.0.0.
**natex3tok-sprot Figure 7-34 Tokyo Show IP Protocol Output**
The show ip route output in Figure 7-35, shows us the details of our EIGRP network 10.0.0.0 with two equal default external routes to network 0.0.0.0. With two equal routes outside of our EIGRP network Cisco routers will perform automatic load sharing on a packet by packet basis to the destination. For further details on the translation process showing the load sharing see Figures 7-44 and 7-50 for debug output and Figures 7-45 and 7-51 for NAT tables.
**natex3tok-srout Figure 7-35 Tokyo Show IP Route Output**
Figure 7-36 shows the NewYork configuration. The main feature in NewYork is the contact with Moscow, where the translation between the two domains takes place.
Line 24 is our static default route defining Ethernet 0 as the destination for all unknown networks.
Line 25 defines a static route to network 192.168.3.0, which is the class address used in the translation process. If this statement is missing, then traffic sent to network 192.168.3.0 will be rejected during the ethernet encapsulation process. Normally, when an ARP request for an address not on the current LAN segment is received by a Cisco router, the router performs a proxy ARP. The router returns the router’s MAC address to be used as the MAC destination across the LAN segment, if the requested address is in the IP routing table. Moscow, on the other end of our connecting LAN segment, knows about the translation network 192.168.3.0 but because this network is not in the routing table, a proxy ARP for 192.168.3.0 does not take place.
Lines 21 and 26 are used to make sure network 192.168.3.0 does not make its way to the routing tables in the rest of the EIGRP network.
**natex3new-cfg Figure 7-36 NewYork Configuration**
The show ip protocol shown in Figure 7-37 shows our EIGRP process with static route filtering in place on line 4.
**natex3new-sprot Figure 7-37 NewYork Show IP Protocol Output**
The show ip route output in Figure 7-38, shows our EIGRP routes, our boundary network 192.168.2.0 as directly connected across Ethernet 0, and static routes to 0.0.0.0 and our translation network 192.168.3.0.
**natex3new-srout Figure 7-38 NewYork Show IP Route Output**
Figure 7-39 shows the London configuration. The main feature in London is the contact with Paris, where the second translation between the two domains takes place.
Line 27 is our static default route defining Ethernet 0 as the destination for all unknown networks.
Line 28 defines a static route to network 192.168.3.0, which is the class address used in the translation process. Note that this address is the same address used in NewYork in Figure 3-36, line 25, as the same translation network MUST be used for all contact points when translation takes place at more than one contact point. If this statement is missing, then traffic sent to network 192.168.3.0 will be rejected during the ethernet encapsulation process. Normally, when an ARP request for an address not on the current LAN segment is received by a Cisco router, the router performs a proxy ARP. The router returns the router’s MAC address to be used as the MAC destination across the LAN segment, if the requested address is in the IP routing table. Moscow, on the other end of our connecting LAN segment, knows about the translation network 192.168.3.0 but because this network is not in the routing table, a proxy ARP for 192.168.3.0 does not take place.
Lines 24 and 29 are used to make sure network 192.168.3.0 does not make its way to the routing tables in the rest of the EIGRP network.
**natex3lon-cfg Figure 7-39 London Configuration**
The show ip protocol shown in Figure 7-40 shows our EIGRP process with static route filtering in place on line 4.
**natex3lon-sprot Figure 7-40 London Show IP Protocol Output**
The show ip route output in Figure 7-41, shows our EIGRP routes, our boundary network 192.168.1.0 as directly connected across Ethernet 0, and static routes to 0.0.0.0 and our translation network 192.168.3.0.
**natex3lon-sroute Figure 7-41 London Show IP Route Output**
Figure 7-42 shows the Moscow configuration where our NAT process takes place.
Line 4 defines our pool of addresses to be used for dynamically translating our inside addresses to the range of addresses 192.168.3.50 to 192.168.3.99.
Line 5 assigns the pool in line 4 to the inside network for translation using the overload method. This allows a single IP translation address to be used as a base for multiple translations when combined with port numbers generated by the original sender. Only addresses that pass the access list on line 41 will be translated.
Lines 6 and seven define static inside and outside address mappings, one for one addressing, no overload.
Line 15 identifies Ethernet 0 as the point where outside translations take place.
Line 16 identifies Serial 0 as the point where inside translations take place.
Lines 33 through 37 details the OSPF routing process to tie together the loopback and serial interfaces to the OSPF processes. Line 37 provides the avenue through which our default route on line 40 is propagated through our OSPF network starting with a metric of 1. By making the metric a type 1 additional metrics are added to the base as this route is propagated throughout the OSPF network.
**natex3mos-cfg Figure 7-42 Moscow Configuration**
Figure 7-43 shows us the setup for our translation tests. After the NAT translation tables and NAT statistics are cleared on lines 1 and 2, the base static definitions are the only items that show up in our show ip nat translation on lines 3 through 6, and our show ip nat statistics on lines 7 through 18.
**natex3mos-show-base Figure 7-43 Moscow Initial Show Command Output**
Figure 7-44 shows us the output of the debug ip nat command for several different translations.
Lines 1 through 5 are the translations when a outside network ping is targeted for our statically defined mapping of 192.168.3.1 to 10.0.1.1. But wait, where is the rest of the five successful pings that were translated. They can be found in Figure 7-50 where Paris has completed the other three pings. Look at the sequence numbers on lines 2 through 5 of Figure 7-44 and lines 2 through 7 of Figure 7-50 and the story is complete. This theme will be repeated for all of our pings in this section. Note that there are two lines for each translation, one on the way into the inside network, and one on the way out.
Lines 7 through 18 detail the translations taking place between an inside host and the statically mapped outside host 10.1.1.1. Let’s go through each of these translations for the first ping. Line 7 shows the translation of the inside local source address 10.1.1.14 to the first dynamic inside global address in the pool, 192.168.3.50. Line 8 shows the translation of the outside local destination address of 192.168.3.254 to the statically mapped outside global address, 10.1.1.1. On the return packet, line 9 shows the translation of the outside global source address 10.1.1.1 to the statically mapped outside local address, 192.168.3.254. Line 10 shows the translation of the dynamic inside global destination address, 192.168.3.50 to the inside global address, 10.1.1.14.
Lines 20 through 24 show us the dynamic address translation cleanup for two separate ping sequences processed through Moscow.
Lines 26 through 32 show us the translation process between our two statically mapped addresses, 10.0.1.1 on the inside, and 10.1.1.1 on the outside. Refer to Figure 7-42 for the configuration commands that set this up for Moscow.
**natex3mos-deb Figure 7-44 Moscow Debug IP NAT Output**
Figure 7-45 shows us the show ip nat statistics for Moscow.
Line 2 shows us the active translations as two static and three dynamic translations.
Line 6 shows us that ten dynamic translations had not been used so after a period of time, have been aged, or dropped from the translation table.
Line 12 shows us the we have used one address used out of the pool, normal in an address overload situation where one address is paired with the inside local port number to create a unique translation.
**natex3mos-show Figure 7-45 Moscow Active NAT Show Command Output**
The show ip protocol in Figure 7-46, shows us the details of our OSPF process.
**natex3mos-sprot Figure 7-46 Moscow Show IP Protocol Output**
The show ip route in Figure 7-47, shows our OSPF derived routes, the directly connected transition network 192.168.2.0, and our static default route on line 19.
**natex3mos-srout Figure 7-47 Moscow Show IP Route Output**
Figure 7-48 shows the Paris configuration where our second NAT process takes place. This NAT process is identical to the Moscow NAT process. It is imperative that all NAT contact points match exactly or translation mismatches will occur.
Line 4 defines our pool of addresses to be used for dynamically translating our inside addresses to the range of addresses 192.168.3.50 to 192.168.3.99.
Line 5 assigns the pool in line 4 to the inside network for translation using the overload method. This allows a single IP translation address to be used as a base for multiple translations when combined with port numbers generated by the original sender. Only addresses that pass the access list on line 41 will be translated.
Lines 6 and seven define static inside and outside address mappings, one for one addressing, no overload.
Line 15 identifies Ethernet 0 as the point where outside translations take place.
Line 28 identifies Serial 1 as the point where inside translations take place.
Lines 33 through 37 details the OSPF routing process to tie together the loopback and serial interfaces to the OSPF processes. Line 37 provides the avenue through which our default route on line 40 is propagated through our OSPF network starting with a metric of 1. By making the metric a type 1 additional metrics are added to the base as this route is propagated throughout the OSPF network.
**natex3par-cfg Figure 7-48 Paris Configuration**
Figure 7-43 shows us the setup for our translation tests. Lines 1 through 3 indicate that basic NAT debugging is activated. After the NAT translation tables and NAT statistics are cleared on lines 11 and 12, the base static definitions are the only items that show up in our show ip nat translation on lines 13 through 16, and our show ip nat statistics on lines 17 through 28.
**natex3par-show-base Figure 7-49 Paris Initial Show Command Output**
Figure 7-44 shows us the output of the debug ip nat command for several different translations.
Lines 1 through 7 are the translations when a outside network ping is targeted for our statically defined mapping of 192.168.3.1 to 10.0.1.1. Where are the rest of the five successful pings that were translated. They can be found in Figure 7-44 where Paris has completed the other two pings. Look at the sequence numbers on lines 2 through 7 of Figure 7-50 and lines 2 through 5 of Figure 7-44 and the story is complete. This theme will be repeated for all of our pings in this section. Note that there are two lines for each translation, one on the way into the inside network, and one on the way out.
Lines 9 through 16 detail the translations taking place between an inside host and the statically mapped outside host 10.1.1.1. Let’s go through each of these translations for the first ping. Line 9 shows the translation of the inside local source address 10.1.1.14 to the first dynamic inside global address in the pool, 192.168.3.50. Line 10 shows the translation of the outside local destination address of 192.168.3.254 to the statically mapped outside global address, 10.1.1.1. On the return packet, line 11 shows the translation of the outside global source address 10.1.1.1 to the statically mapped outside local address, 192.168.3.254. Line 12 shows the translation of the dynamic inside global destination address, 192.168.3.50 to the inside global address, 10.1.1.14.
Lines 18 through 22 show us the dynamic address translation cleanup for two separate ping sequences processed through Moscow.
Lines 24 through 34 show us the translation process between our two statically mapped addresses, 10.0.1.1 on the inside, and 10.1.1.1 on the outside. Refer to Figure 7-48 for the configuration commands that set this up for Paris.
**natex3par-deb Figure 7-50 Paris Debug IP NAT Output**
The show ip nat translation in Figure 7-51, shows dynamically mapped addresses on lines 2 through 4. These NAT translations indicate the same IP addresses on both sides, but use the port number as an additional part of the mapping to create unique conversation mappings a standard feature of address overloading. If this had been one to one NAT translation, there would have been only one dynamic map between 192.168.3.50 and 192.158.3.254.
**natex3par-show-after Figure 7-51 Paris Show IP NAT Translation Output**
Figure 7-52 shows us a standard OSPF process for network 10.0.0.0 subnetworks.
**natex3par-sprot Figure 7-52 Paris Show IP Protocol Output**
The show ip route in Figure 7-53, shows our OSPF derived routes, the directly connected transition network 192.168.2.0, and our static default route on line 19.
**natex3par-srout Figure 7-53 Paris Show IP Route Output**
The configuration for Rome in Figure 7-54, shows us an OSPF border router between Area 1 and Area 0. Note the area summarization commands in lines 26 and 27.
**natex3rom-cfg Figure 7-54 Rome Configuration**
The ping output in Figure 7-55, shows two successful ping commands from the Rome to 10.1.1.1 in the outside network. The static outside global address mapped to 10.1.1.1 is 192.168.3.254.
Lines 1 through 6 show a standard ping, 100% successful, and if you look in Figures 7-44 and 7-50, the NAT debug output it will show the two different paths taken through the NAT process.
**natex3rom-ping Figure 7-55 Rome Ping Output**
The show ip protocol output in figure 7-56 details our OSPF process.
**natex3rom-sprot Figure 7-56 Rome Show IP Protocol Output**
The show ip route output in Figure 7-57, as our standard OSPF and connected networks. There are two equal type 1 OSPF external default routes on lines 19 and 20, which will provide load sharing across our two serial ports, and from there, to our two different NAT contact points in Moscow and Paris.
**natex3rom-srout Figure 7-57 Rome Show IP Route Output**
Example #4- TCP Load Sharing
As Internet access to services on your network becomes more critical to timely business operations it becomes necessary to have multiple mirrored IP servers. Think of the size of the Cisco web site and how many people access CCO for up to date information.
The target address that represents our shared TCP hosts is 172.15.3.4, and is not a specific host, but represents a group of hosts. See London for the NAT operations in Figures 7-63 through 7-68.
This example shows you how to set up NAT to provide this multi-server environment for shared TCP access. The network layout for this example is shown in Figure 7-58.
**B018.cdr Figure 7-58 NAT for TCP Load Sharing**
NewYork is set up as a basic RIP router and serves as our starting point for testing TCP load sharing. The configuration for NewYork is shown in Figure 7-59.
** natex4new-cfg Figure 7-59 NewYork Configuration**
The testing output from NewYork to Rome is shown in Figure 7-60.
Lines 1 through 6 show an unsuccessful attempt to ping 172.16.3.4. Normal, this feature does TCP load sharing, not UDP or ICMP.
Lines 7 through 10 show an unsuccessful telnet attempt to contact 172.16.3.4. Look at the debug output in Figure 7-65 for an explanation of this failure.
Lines 11 through 30 show a successful telnet to 172.16.3.4. If you look carefully at the address on the Ethernet 0 port, 172.16.3.2 is definitely not the address we used in our telnet request in line 11.
**natex4new-test Figure 7-60 NewYork Ping and Telnet Test Output**
Figure 7-61 shows us a standard RIP routing process for NewYork.
**natex4new-sprot Figure 7-61 NewYork Show IP Protocol Output**
The show ip route output in Figure 7-62, shows our connected networks and a RIP derived route for 172.16.3.0.
**natex4new-srout Figure 7-62 NewYork Show IP Route Output**
The London configuration is shown in Figure 7-63, and is where our NAT TCP load sharing is configured.
Line 4 defines a pool of two addresses 172.16.3.2 and 172.16.3.3 as a rotary pool. The number of entries in the pool should match the number of hosts to be used for TCP load sharing. For this example there is only host available, 172.16.3.2, but two addresses are used in the pool to illustrate the error that will occur if too many hosts are defined in the pool.
Line 5 defines the addresses that will trigger a translation into the addresses used in the poll defined on line 4.
Line 10 defines interface ethernet 0 as the translation point for our TCP load sharing. Seems too easy doesn’t it.
**natex4lon-cfg Figure 7-63 London Configuration**
The setup commands prior to starting NAT translations are shown in Figure 7-64.
Lines 1 through 12 show us the show ip nat statistics output, with lines 9 through 12 detailing the share-hosts pool information.
Line 13, the show ip nat translation command has no output, no translations are active.
Lines 14 through 24 are our debug setup showing all variations active.
**natex4lon-show-base Figure 7-64 London Initial Show Command Output**
Figure 7-65 shows us the output of the debug commands.
Lines 2 through 6 show us the failure of our ping 172.16.3.4 attempt, each line contains an o: that says we have incoming translation attempts from the outside, but none are successful.
Lines 8 through 16 show an unsuccessful attempt to connect to 172.16.3.4. The reason it is unsuccessful is due to the absence of host 172.16.3.3, we only have outside to inside translation attempts. Line 8 is the detailed debug output showing us that an outside address wants in, line 9 is the actual translation debug output.
Lines 18 through 28 show the start of a successful telnet attempt to connect to 172.16.3.4. Line 18 shows our first TCP packet coming in from the outside. Line 19 is the initial translation from 172.16.3.4 to 172.16.3.2. This telnet attempt is successful because 172.16.3.2 is an available host. Line 20 shows a return packet headed back to the requestor, and line 21 shows the translation taking place.
The debug ip nat detailed is great to identify when packets actually trigger the translation process and the debug ip nat actually shows the translations taking place.
**natex4lon-deb Figure 7-65 London Debug Output**
Figure 7-55 shows the output from the show ip nat statistics command on lines 1 through 12, and the output of the show ip nat translation on lines 14 through 16.
Line 19 shows the aging out of the translation identified on line 16.
**natex4lon-show-after Figure 7-66 London Active Show Command Output**
Figure 7-67 shows us a standard RIP routing process for London.
**natex4lon-sprot Figure 7-67 London Show IP Protocol Output**
Figure 7-68 shows us the show ip route output, again, plain vanilla.
**natex4lon-srout Figure 7-68 London Show IP Route Output**
Paris in this example is acting as a host for TCP sharing. The configuration is shown in Figure 7-69.
**natex4par-cfg Figure 7-69 Paris Configuration**
The show ip protocol is shown here to remind you that all hosts on the shared network should either be able to get routing updates from the translation device, or, have a default gateway defined pointing to the translation device.
**natex4par-sprot Figure 7-70 Paris Show IP Protocol**
CCIE Tips
The most important tip to remember when working with NAT is to understand the meaning of the four address types, inside local, inside global, outside global, and outside local.
Examples #1 through #3 used an intermediate network, and separate interfaces for defining where inside and outside addresses get translated.
Labs
Good practice for implementing NAT would be to try Examples #1 and #2 with both translations taking place on the same interface.
Summary
Network Address Translation is a feature that provides you with a mechanism to design your IP network using the extended address space of private network 10.0.0.0 while still being able to communicate with the outside world via the Internet using a registered address.
Example #3 Bombs
There are two major bombs waiting for you in Example #3.
First, the example used fresh router startups and make sure that the IP load balancing is synchronized so that the two equal default route paths work together. If the default route paths are not synchronized, then all dynamic translations could fail, while all static translations work. A better solution would be to set up two different metrics, for the default routes in both the EIGRP and OSPF domains, so that a primary and secondary path would provide translation without load balancing. Try it both ways for fun.
Second, both Moscow and Paris have a second serial port that does not have translation assigned. Set up this example and take down the primary translation port and see what happens.
Happy Translating!