Network Address Translation by Jennifer Carroll, Jeff Doyle
Case Study: A Network Merger
Download 0.92 Mb.
|
Case Study: A Network MergerNAT is useful for preventing possible address conflicts between internetworks. The previous two case studies demonstrate the connection of internetworks using private address space to an internetwork using public addresses. The publicly addressed internetwork might be some other enterprise, or it might be the Internet. The bottom line is that the private RFC 1918 addresses must be translated because they are not unique. Across the Internet, many enterprises use the same addresses in their internetworks, and these addresses are "hidden" by NAT. You also can use the configurations of the previous case studies in situations where the inside network is addressed out of the public address space but the addresses were not assigned by an addressing authority. For example, the inside network's address space might be 171.68.0.0/16. When connected to the Internet, NAT is required, because this address space is assigned to another company. Allowing these untranslated packets onto the Internet will cause routing conflicts. Another situation in which address conflicts might arise is the merger of two previously separate internetworks. In Figure 4-20, Surf Corporation and Sand, Inc. have formed a corporate merger to form Surf n' Sand Enterprises. Part of the merger is the connection of their two internetworks. Unfortunately, when the two internetworks were first constructed, the designers both chose to use the 10.0.0.0 address space. As a result, many devices in Surf Corp.'s internetwork have the same addresses as devices in Sand, Inc.'s internetwork. F  igure 4-20 Two Internetworks with Many Duplicate Addresses Must Be Connected The best solution is to re-address the new internetwork. Address schemes are frequently designed poorly, however, making re-addressing a major project. In the Surf n' Sand internetwork, for instance, all the devices have manually configured IP addresses rather than addresses assigned by DHCP. NAT can serve as an interim solution to connect the internetworks until the re-addressing project can be completed. NOTE Note that in this application, NAT should always be considered an interim solution. It is bad practice to allow address conflicts to exist within an internetwork indefinitely. The Surf n' Sand administrator first applies to his ISP or an addressing authority to acquire a public address space and is assigned the CIDR block 206.100.160.0/19. This block is then split in half. 206.100.160.0/20 is assigned to the former Sand internetwork, and 206.100.176.0/20 is assigned to the former Surf internetwork. An assumption is made here that although the 10.0.0.0 network is capable of supporting more than 16 million host addresses, in reality there are not more hosts in either network than can be serviced out of the /20 address space. The routers Cozumel and Guaymas in Figure 4-21 connect the two internetworks with the configurations in Example 4-20. F  igure 4-21 NAT Is Used at the Boundaries of the Two Internetworks to Correct the Address Conflicts Example 4-20 NAT Configurations for Routers Cozumel and Guaymas in Figure 4-21Cozumel interface Ethernet0 ip address 10.100.85.1 255.255.255.0 ip nat inside ! interface Ethernet1 ip address 10.255.13.254 255.255.255.248 ip nat outside ! router ospf 1 redistribute static network 10.100.85.1 0.0.0.0 area 18 ! ip nat pool Surf 206.100.176.2 206.100.191.254 prefix-length 20 ip nat inside source list 1 pool Surf ip nat inside source static 10.100.50.1 206.100.176.1 ! ip route 206.100.160.0 255.255.240.0 10.255.13.253 ! access-list 1 deny 10.255.13.254 access-list 1 permit any Guaymas
interface Ethernet0 ip address 10.16.95.1 255.255.255.0 ip nat inside ! interface Ethernet1 ip address 10.255.13.253 255.255.255.248 ip nat outside ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.508 point-to-point ip address 10.18.3.253 255.255.255.0 ip nat inside frame-relay interface-dlci 508 ! router eigrp 100 redistribute static metric 1000 100 255 1 1500 passive-interface Ethernet1 network 10.0.0.0 no auto-summary ! ip nat pool Sand 206.100.160.2 206.100.175.254 prefix-length 20 ip nat inside source list 1 pool Sand ip nat inside source static 10.16.95.200 206.100.160.1 ! ip route 206.100.176.0 255.255.240.0 10.255.13.254 ! access-list 1 deny 10.255.13.253 access-list 1 permit 10.0.0.0 !
Host Beachball queries DNS2 for the address of Snorkel.surf.com. DNS2 queries DNS1, which is authoritative for the surf.com domain. The query has a source address of 10.16.95.200 and a destination address of 206.100.176.1. The query is forwarded to Guaymas, which is advertising a route into EIGRP for 206.100.176.0/20. Guaymas translates the source address from 10.16.95.200 to 206.100.160.1, based on the static NAT entry, and forwards the packet to Cozumel. Cozumel translates the destination address from 206.100.176.1 to 10.100.50.1, based on the static NAT entry, and forwards the query to DNS1. DNS1 responds to the query, indicating that Snorkel.surf.com has an IP address of 10.1.2.2. The response message has a source address of 10.100.50.1 and a destination address of 206.100.160.1. The response is forwarded to Cozumel, which is advertising a route into OSPF for 206.100.160.0/20. Cozumel translates the source address of the DNS response to 206.100.176.1. NAT also finds the address 10.1.2.2 in the Answer field of the message; the address matches access list 1 and is translated to an address from the pool named Surf. For this example, the address is 206.100.176.3. The mapping is entered into the NAT table, and the response is forwarded to Guaymas. Guaymas translates the destination of the DNS response to 10.16.95.200 and forwards the message to DNS1. DNS1 informs Beachball that the IP address of Snorkel.surf.com is 206.100.176.3. Beachball sends a packet to Snorkel with a source address of 10.1.2.2 and a destination address of 206.100.176.3. Again, the packet is forwarded to Guaymas. At Guaymas, the source address matches access list 1, and an address is selected from the pool named Sand. For this example, the address is 206.100.160.2. The source address is translated, the mapping is entered into the NAT table, and the packet is forwarded to Cozumel. Cozumel finds that the destination address of 206.100.176.3 is mapped in its NAT table to 10.1.2.2 and makes the translation to that IL address. The packet is forwarded to Snorkel. Snorkel sends a packet in response. The source address is 10.1.2.2, and the destination address is 206.100.160.2. The packet is forwarded to Cozumel. Cozumel translates the packet's source address to 206.100.176.3 and forwards the packet to Guaymas. Guaymas translates the packet's destination address to 10.1.2.2 and forwards the packet to Beachball. By following this example, you can see that although two devices have the same IP address, neither is aware of the other's true address. The key to making all this work is the routing configurations of Cozumel and Guaymas. Neither router leaks information about the 10.0.0.0 network to the other. Nothing in either configuration allows a packet with a destination address within the 10.0.0.0 network to be forwarded to the other router, with the exception of packets destined for the directly connected 10.255.13.248/29 subnet. Access list 1 is configured so that packets sourced from either router's E1 interface are not translated. NOTE Troubleshooting Exercise 3 asks you to consider this access list configuration further. Another detail of interest in Example 4-20 is that there is more than one inside interface at Guaymas. Multiple inside interfaces are quite acceptable. One topic of importance that is not readily evident in the configuration concerns the coordination of the NAT translation timeout period and the DNS cache Time-To-Live (TTL) period. When a DNS server receives a resource record from another DNS server, it caches the record so that it can respond directly to subsequent queries for the same record. In the example in this case study, DNS2 will cache the A RR that maps Snorkel.surf.com to IP address 206.100.176.3. DNS2 can then respond to subsequent requests for Snorkel's IP address without again querying DNS1. This cached RR has a TTL period associated with it and is flushed when the TTL expires. The DNS TTL period must be shorter than the NAT translation timeout period. F  igure 4-22 The Internet Access Router Does Not Have to Support NAT; All Translations for Internet Traffic Are Performed by Cozumel and Guaymas Suppose, for example, that the NAT translation timeout expires on the 10.1.2.2-to-206.100.176.3 mapping, and the IG address is returned to the pool. 206.100.176.3 is then mapped to a different IL address within the Surf internetwork, but DNS2 still has an RR mapping Snorkel.surf.com to 206.100.176.3. If a device in the Sand internetwork queries DNS2 for Snorkel's address, DNS2 responds with obsolete information, and packets are sent to the wrong host. A final note on this design concerns Internet access. You can easily accomplish Internet access by adding an access router to the subnet between Cozumel and Guaymas (see Figure 4-22). The source addresses of packets from both the Surf and Sand internetworks already are translated to valid public addresses; all that is needed is for default routes to be added to Cozumel and Guaymas, pointing to the Internet access router.
Download 0.92 Mb. Share with your friends:
|