Network Address Translation by Jennifer Carroll, Jeff Doyle


Case Study: ISP Multihoming with NAT



Download 0.92 Mb.
Page12/13
Date28.05.2018
Size0.92 Mb.
#51995
1   ...   5   6   7   8   9   10   11   12   13

Case Study: ISP Multihoming with NAT


The section "NAT and Multihomed Autonomous Systems" earlier in this chapter demonstrated ways you can employ NAT to overcome the problem of multihoming to different ISPs with different CIDR blocks. The subscriber in Figure 4-7 is multihomed, and each ISP sees packets with source addresses belonging to its own address space. Neither ISP receives packets from the subscriber with source addresses belonging to the other ISP's block of addresses.

Based on the NAT case studies you have already seen, you can easily write configurations for the two NAT routers shown in Figure 4-7. But what about a situation in which a single router is multihomed to both ISPs, as shown in Figure 4-23? Montego is receiving full BGP routes from both ISPs, so it can choose the best provider to any destination. When a packet is forwarded to ISP1, the packet must have a source address from the 205.113.50.0/23 block assigned by ISP1; when a packet is forwarded to ISP2, it must have a source address from the 207.36.76.0/23 block assigned by ISP2.



F
igure 4-23
ISP1 and ISP2 Have Each Assigned a CIDR Block to JamaicaNet; When Packets Are Forwarded to an ISP, They Must Have the Correct Source Address for That ISP

Example 4-21 shows Montego's configuration for using different address pools on different interfaces.


Example 4-21 Montego's Configuration in Figure 4-23


interface Ethernet0

ip address 10.1.1.1 255.255.255.0

ip nat inside

!

interface Ethernet1



ip address 10.5.1.1 255.255.255.0

ip nat inside

!

interface Serial1



no ip address

encapsulation frame-relay

interface Serial1.708 point-to-point

description PVC to ISP1

ip address 205.113.49.253 255.255.255.252

ip nat outside

frame-relay interface-dlci 708

!

interface Serial1.709 point-to-point



description PVC to ISP2

ip address 207.36.65.253 255.255.255.252

ip nat outside

frame-relay interface-dlci 709

!

router ospf 10



network 10.0.0.0 0.255.255.255 area 10

default-information originate always

!

router bgp 451



neighbor 205.113.49.254 remote-as 1135

neighbor 207.36.65.254 remote-as 216

!

ip nat pool ISP1 205.113.50.1 205.113.51.254 prefix-length 23



ip nat pool ISP2 207.36.76.1 207.36.77.254 prefix-length 23

ip nat inside source route-map ISP1_MAP pool ISP1

ip nat inside source route-map ISP2_MAP pool ISP2

!

access-list 1 permit 10.0.0.0 0.255.255.255



access-list 2 permit 207.36.65.254

!

route-map ISP1_MAP permit 10



match ip address 1

match interface Serial1.708

!

route-map ISP2_MAP permit 10



match ip address 1

match ip next-hop 2

!

The address blocks assigned by the ISPs are specified in the pools ISP1 and ISP2. The significant feature of this NAT configuration is that the ip nat inside source statements make calls to route maps rather than access lists. By using route maps, you can specify not only the IL address, but also the interface or the next-hop address to which the packet is to be forwarded. ISP1_MAP specifies packets that have a source address belonging to the 10.0.0.0 network (as identified by access list 1) and which are to be forwarded out interface s1.708 to ISP1. ISP2_MAP also specifies packets from 10.0.0.0 that are to be forwarded to the next-hop address 207.36.65.254 to ISP2.



NOTE

Normally, either the match interface or the match ip next-hop command is used in both route maps for consistency. Both commands are used here for demonstration purposes.

For example, an inside device with an address of 10.1.2.2 sends a packet with a destination address of 137.19.1.1. The packet is forwarded to Montego, because that router is advertising a default route into JamaicaNet via OSPF. Montego does a route lookup and determines that the best route to the destination is via ISP2, out S1.709 and with a next-hop address of 207.36.65.254. The first ip nat inside source statement checks this information against route map ISP1_MAP. Although the source address matches, the egress interface does not. The second ip nat inside source statement checks the information against route map ISP2_MAP. Here both the source address and the next-hop address match, so the source address is translated to an address out of the ISP2 pool.

Example 4-22 shows Montego's NAT table after some traffic has passed to the ISPs. Because an IL address can be mapped to an address from more than one pool, the address mappings are extended mappings, showing the protocol type and the port number. Extended mapping is discussed in more detail in the case study "Port Address Translation."


Example 4-22 Montego's NAT Table Shows That the IG Address Chosen for Translation Depends on the ISP to Which the Packet Is to Be Forwarded


Montego#show ip nat translations

Pro Inside global Inside local Outside local Outside global

udp 207.36.76.2:4953 10.1.2.2:4953 137.19.1.1:69 137.19.1.1:69

udp 205.113.50.2:2716 10.1.1.2:2716 171.35.100.4:514 171.35.100.4:514

tcp 205.113.50.1:11009 10.5.1.2:11009 205.113.48.1:23 205.113.48.1:23

tcp 207.36.76.1:11002 10.1.1.2:11002 198.15.61.1:23 198.15.61.1:23

tcp 205.113.50.3:11007 10.1.2.2:11007 171.35.18.1:23 171.35.18.1:23

tcp 207.36.76.2:11008 10.1.2.2:11008 207.36.64.1:23 207.36.64.1:23

Montego#

Of interest in the NAT table in Example 4-22 are the three entries for the IL address 10.1.2.2. The UDP traffic and one of the TCP sessions went to a destination via ISP2. The IG address to which the IL address is mapped is 207.36.76.2. The other TCP session was sent via ISP1 and so was mapped to 205.113.50.3. These entries demonstrate that the pool from which the IG address is chosen changes, even for the same source address, depending on where the packet is forwarded.



Figure 4-24 shows DNS servers for the three autonomous systems. The servers in ISP1 and ISP2 must access Ochee, the DNS server authoritative for JamaicaNet. This means that Ochee must have static NAT entries to addresses in both CIDR blocks. Statically mapping an IL address to more than one IG address is normally not allowed, because the mappings are ambiguous. In this case, ambiguity is not a problem because the same NAT is doing both mappings. When Montego routes Ochee's DNS queries and responses to DNS1 or DNS2, the appropriate translations are made.

To allow static NAT mappings of one IL address to multiple IG addresses, the keyword extendable is added to the end of the mapping statements. Example 4-23 shows the NAT configuration for Montego.



F
igure 4-24
The DNS Server Ochee Must Have a Static IL-to-IG Mapping So That It Can Be Queried by DNS1 and DNS2

Example 4-23 NAT Configuration for Montego to Allow Static NAT Mappings of One IL Address to Multiple IG Addresses


ip nat pool ISP1 205.113.50.2 205.113.51.254 prefix-length 23

ip nat pool ISP2 prefix-length 23

address 207.36.76.1 207.36.76.99

address 207.36.76.101 207.36.77.254

ip nat inside source route-map ISP1_MAP pool ISP1

ip nat inside source route-map ISP2_MAP pool ISP2

ip nat inside source static 10.5.1.2 207.36.76.100 extendable

ip nat inside source static 10.5.1.2 205.113.50.1 extendable

!

access-list 1 permit 10.0.0.0 0.255.255.255



access-list 2 permit 207.36.65.254

!

route-map ISP1_MAP permit 10



match ip address 1

match interface Serial1.708

!

route-map ISP2_MAP permit 10



match ip address 1

match ip next-hop 2

From the perspective of DNS1, Ochee's address is 205.113.50.1. Notice that NAT pool ISP1 is modified to exclude this address from the pool. From the perspective of DNS2, Ochee's address is 207.36.76.100. This address is taken from the middle of the 207.36.76.0/23 block rather than from one end or the other, making pool ISP2 discontiguous. The pool is modified in the configuration to specify two ranges of addresses: those before Ochee's address, and those after Ochee's address.

You configure a discontiguous range of addresses by first naming the pool and specifying the prefix length or netmask. The configuration prompt then enables you to enter a list of ranges. Example 4-24 shows the configuration steps for pool ISP2, including the prompts.


Example 4-24 Configuring a NAT Pool for a Discontiguous Range of Addresses


Montego(config)#ip nat pool ISP2 prefix-length 23

Montego(config-ipnat-pool)#address 207.36.76.1 207.36.76.99

Montego(config-ipnat-pool)#address 207.36.76.101 207.36.77.254

Port Address Translation


At the opposite extreme from the multihomed NAT router in the preceding case study is the SOHO (small office, home office) router connecting a few devices to the Internet. Instead of acquiring separate public addresses for each device, port address translation (PAT) allows all the SOHO devices to share a single IG address.

PAT allows overloading, or the mapping of more than one IL address to the same IG address. To accomplish this, the NAT entries in the routing table are extended entries—the entries track not only the relevant IP addresses, but also the protocol types and ports. By translating both the IP address and the port number of a packet, up to 65535 IL addresses could theoretically be mapped to a single IG address (based on the 16-bit port number).



NOTE

Each NAT entry uses approximately 160 bytes of memory, so 65535 entries would consume more than 10 MB of memory and large amounts of CPU power. Nowhere near this number of addresses are mapped in practical PAT configurations.



Cisco's NAT attempts to preserve BSD semantics, mapping an IL port number to the same IG port number whenever possible. A different IG port number is used only when the port number associated with the IL address is already being used in another mapping.

F
igure 4-25
shows three devices connected to an ISP.

Figure 4-25 Barbados Uses PAT to Map the Addresses of the Three Inside Hosts to the Single Serial Interface Address

The access router has a single public IP address assigned by the ISP on its serial interface, as demonstrated in the configuration in Example 4-25.


Example 4-25 Enabling PAT on Router Barbados in Figure 4-25


interface Ethernet0

ip address 192.168.1.1 255.255.255.0

ip nat inside

!

interface Serial0



ip address 207.35.14.82 255.255.255.252

ip nat outside

!

ip nat inside source list 1 interface Serial0 overload



!

ip route 0.0.0.0 0.0.0.0 Serial0

!

access-list 1 permit 192.168.1.0 0.0.0.255



!

PAT is enabled with the overload keyword. Although the ip nat inside source command could reference an address pool, in this case it just references the interface on which the IG address is configured. As usual, the access list identifies the IL addresses.

Example 4-26 shows the NAT table in the access router after a few packets have passed through it. Most of the IG ports match the IL ports, but notice that there are two instances in which an IL socket has a port number that has already been used (192.168.1.2:11000 and 192.168.1.2:11001). As a result, the NAT has chosen an unused port for these sockets that does not match the IL port.

Example 4-26 Different IL Addresses Have Been Mapped to Different Ports of the Same IG Address


Barbados#show ip nat translations

Pro Inside global Inside local Outside local Outside global

tcp 207.35.14.82:11011 192.168.1.3:11011 191.115.37.2:23 191.115.37.2:23

tcp 207.35.14.82:5000 192.168.1.2:11000 191.115.37.2:23 191.115.37.2:23

udp 207.35.14.82:3749 192.168.1.2:3749 135.88.131.55:514 135.88.131.55:514

tcp 207.35.14.82:11000 192.168.1.4:11000 191.115.37.2:23 191.115.37.2:23

tcp 207.35.14.82:11002 192.168.1.2:11002 118.50.47.210:23 118.50.47.210:23

udp 207.35.14.82:9371 192.168.1.2:9371 135.88.131.55:514 135.88.131.55:514

icmp 207.35.14.82:7428 192.168.1.3:7428 135.88.131.55:7428 135.88.131.55:7428

tcp 207.35.14.82:5001 192.168.1.2:11001 135.88.131.55:23 135.88.131.55:23

tcp 207.35.14.82:11001 192.168.1.4:11001 135.88.131.55:23 135.88.131.55:23

Barbados#


Case Study: TCP Load Balancing


Figure 4-26 shows a topology similar to the one in the PAT case study. Here the three inside devices are not hosts, however, but are identical servers with mirrored content. The intent is to create a "virtual server" with an address of 199.198.5.1; that is, from the outside there appears to be a single server at that IG address. In reality, the router Barbados is configured to perform round-robin translations to the three IL addresses.

Example 4-27 shows the configuration for Barbados.

Example 4-27 Barbados' NAT Configuration Evenly Distributes the TCP Load to the Three Identical Servers; Outside Devices See Only a Single Inside Global Address

interface Ethernet0

ip address 192.168.1.1 255.255.255.0

ip nat inside

!

interface Serial0



ip address 207.35.14.82 255.255.255.252

ip nat outside

!

ip nat pool V-Server 192.168.1.2 192.168.1.4 prefix-length 24 type rotary



ip nat inside destination list 1 pool V-Server

!

ip route 0.0.0.0 0.0.0.0 Serial0



!

access-list 1 permit 199.198.5.1

!

Instead of translating an IL address as most of the previous case studies have demonstrated, this configuration translates the IG address. The address pool V-Server contains a list of the available IL addresses, and the keywords type rotary cause a round-robin assignment of the pool addresses. The access list, as usual, identifies the address to be translated—in this case, the single destination address 199.198.5.1.



Example 4-28 shows the resulting NAT table after four outside devices have sent TCP traffic to the virtual server. You can observe that the first three connections (reading from the bottom up) were allocated sequentially from the lowest IL address in the pool to the highest. Only three addresses are available in the pool, so the fourth connection is again mapped to the lowest IL address.

Example 4-28 The TCP Connections to the Virtual Server Address 199.198.5.1 Are Balanced Across the Three Real Server Addresses


Barbados#show ip nat translations

Pro Inside global Inside local Outside local Outside global

tcp 199.198.5.1:23 192.168.1.2:23 203.1.2.3:11003 203.1.2.3:11003

tcp 199.198.5.1:23 192.168.1.4:23 135.88.131.55:11002 135.88.131.55:11002

tcp 199.198.5.1:23 192.168.1.3:23 118.50.47.210:11001 118.50.47.210:11001

tcp 199.198.5.1:23 192.168.1.2:23 191.115.37.2:11000 191.115.37.2:11000



Barbados#

F
igure 4-26
The Three Inside Devices Are Identical Servers with Mirrored Content, Which from the Outside Appear to Be a Single Server

Case Study: Service Distribution


You also can use NAT to create a virtual server in which connections are distributed by TCP or UDP services rather than by TCP connection. The internetwork in Figure 4-27 is very similar to that in Figure 4-26, except that the servers are not identical. Rather, different servers offer different services. From the outside, all three servers appear to be a single server with the address 199.198.5.1.

Example 4-29 shows the NAT configuration in Barbados.


Example 4-29 The NAT Configuration in Barbados Translates the Virtual IG Address According to the TCP or UDP Port Associated with the Address


interface Ethernet0

ip address 192.168.1.1 255.255.255.0

ip nat inside

!

interface Serial0



ip address 207.35.14.82 255.255.255.252

ip nat outside

!

ip nat inside source static tcp 192.168.1.4 25 199.198.5.1 25 extendable



ip nat inside source static udp 192.168.1.3 514 199.198.5.1 514 extendable

ip nat inside source static udp 192.168.1.3 69 199.198.5.1 69 extendable

ip nat inside source static tcp 192.168.1.3 21 199.198.5.1 21 extendable

ip nat inside source static tcp 192.168.1.3 20 199.198.5.1 20 extendable

ip nat inside source static tcp 192.168.1.2 80 199.198.5.1 80 extendable

!

ip route 0.0.0.0 0.0.0.0 Serial0



!

F
igure 4-27
Three Inside Devices That Offer Different Services Appear to Be a Single Server from the Outside

No address pools or access lists are here; instead, the configuration is a series of simple IL-to-IG mappings. The difference between these statements and the static statements you saw earlier is that TCP or UDP is specified, as are the source and destination ports. The extendable keyword is used, because the same address—this time, the IG address—appears in more than one statement. You do not have to type the keyword: Cisco IOS Software adds it automatically. In order, the statements map SMTP (TCP port 25), syslog (UDP port 514), TFTP (UDP port 69), FTP (TCP ports 20 and 21), and HTTP (TCP port 80).

Example 4-30 shows the NAT table just after Barbados is configured; the only entries are the static entries.

Example 4-30 Before Any Dynamic Translations Occur, Barbados' NAT Table Contains Only the Static Mappings of IL Sockets to IG Sockets


Barbados#show ip nat translations

Pro Inside global Inside local Outside local Outside global

udp 199.198.5.1:514 192.168.1.3:514 --- ---

udp 199.198.5.1:69 192.168.1.3:69 --- ---

tcp 199.198.5.1:80 192.168.1.2:80 --- ---

tcp 199.198.5.1:21 192.168.1.3:21 --- ---

tcp 199.198.5.1:20 192.168.1.3:20 --- ---

tcp 199.198.5.1:25 192.168.1.4:25 --- ---

Barbados#

Example 4-31 shows the NAT table after some traffic has passed through Barbados. Notice that among all the dynamic mappings, only two OG addresses appear. Yet the sessions have been mapped to different IL addresses, depending on the port associated with the IG address.


Example 4-31 UDP and TCP Packets Are Mapped to Different IL Addresses, Depending on Their Associated Port Numbers


Barbados#show ip nat translations

Pro Inside global Inside local Outside local Outside global

udp 199.198.5.1:514 192.168.1.3:514 --- ---

tcp 199.198.5.1:25 192.168.1.4:25 207.35.14.81:11003 207.35.14.81:11003

udp 199.198.5.1:69 192.168.1.3:69 --- ---

tcp 199.198.5.1:80 192.168.1.2:80 --- ---

tcp 199.198.5.1:21 192.168.1.3:21 --- ---

tcp 199.198.5.1:20 192.168.1.3:20 --- ---

tcp 199.198.5.1:25 192.168.1.4:25 --- ---

tcp 199.198.5.1:20 192.168.1.3:20 191.115.37.2:1027 191.115.37.2:1027

tcp 199.198.5.1:21 192.168.1.3:21 191.115.37.2:1026 191.115.37.2:1026

tcp 199.198.5.1:80 192.168.1.2:80 191.115.37.2:1030 191.115.37.2:1030

udp 199.198.5.1:69 192.168.1.3:69 191.115.37.2:1028 191.115.37.2:1028

udp 199.198.5.1:514 192.168.1.3:514 207.35.14.81:1029 207.35.14.81:1029

Barbados#


Download 0.92 Mb.

Share with your friends:
1   ...   5   6   7   8   9   10   11   12   13




The database is protected by copyright ©ininet.org 2024
send message

    Main page