Contents

Chapter Description

Network address translation (NAT) is a function by which IP addresses within a packet are replaced with different IP addresses. This function is most commonly performed by either routers or firewalls. This sample chapter from Cisco Press focuses on NAT within routers.

From the Book

Configuring NAT

The first step in configuring NAT is to designate the inside and outside
interfaces. Beyond that, the configuration depends on whether you are
configuring static NAT or dynamic NAT. For static NAT, you just create the
appropriate mapping entries in the NAT table. For dynamic NAT, you create a pool
of addresses to be used in the translation and create access lists to identify
the addresses to be translated. A single command then ties the pool and the
access leist together.

This section demonstrates the most common configuration techniques for NAT in
its most common uses.

Case Study: Static NAT

In Figure 4-15, the inside network is addressed out of the 10.0.0.0 address
space. Two of the devices, hosts A and C, must be able to communicate with the
outside world. Those two devices are translated to the public addresses
204.15.87.1/24 and 204.15.87.2/24.

Example 4-4 shows the configuration to implement NAT at Mazatlan.

Figure 4-15 The Inside Local Addresses of Devices A and C Are Statically
Translated to Inside Global Addresses by the NAT Process in Router
Mazatlan

The router's E0 interface is designated as being on the inside with the
ip nat inside command, and the Frame Relay subinterface S1.705 is
designated as being on the outside with the ip nat outside command.

Next, the inside local addresses are mapped to inside global addresses with
the ip nat inside source static commands. There are two of these
commands, one for host C and one for host A. Example 4-5 shows the resulting NAT
table.

Example 4-5 The IL Addresses of Hosts C and A Are Statically Translated into
IG Addresses

When host A or C sends a packet to the outside, Mazatlan sees the source
address in its NAT table and makes the appropriate translation. The router
Acapulco has a route (in this case, a static route) to network 204.15.87.0 and
has no knowledge of the 10.0.0.0 network. Therefore, Acapulco and host D can
respond to packets from hosts A and C. If host B or router Veracruz sends a
packet to host D, the packet is forwarded, but without any translation; when D
responds to the untranslated IL address, Acapulco has no route and drops the
packet, as demonstrated in Example 4-6.

Example 4-6 When Host D in Figure 4-15 Responds to the Untranslated IL
Address of Host B, Acapulco Has No Route to 10.0.0.0 and Drops the Packet

Outside global addresses can also be statically translated into outside local
addresses. Suppose, for example, that the administrator of the inside network in
Figure 4-15 wants host D to "appear" to be a part of the inside
networksay, with an address of 10.1.3.1. Example 4-7 shows the NAT
configuration for Mazatlan.

The router's NAT configuration remains the same, except for the addition
of the ip nat outside source static command, which in this case maps the
OG address 201.114.37.5 to the OL address 10.1.3.1. Example 4-8 shows the
resulting NAT table.

Example 4-8 An OG-to-OL Mapping Is Added to the NAT Table by the Additional
Command at Mazatlan

Although this case study has involved only static mappings, some dynamic
mapping occurs after traffic has passed between host A and host D, and between
host C and host D, as illustrated by Example 4-9. In each case, the inside
mappings are automatically mapped to the outside mappings.

Example 4-9 The Inside Addresses of Hosts A and C Have Been Automatically
Mapped to the Outside Addresses of Host D

It is important to understand that this configuration does nothing to prevent
a host on the inside from sending packets to host D's OG address rather
than the OL address. In Figure 4-16, host A can successfully ping host D at
either its OL address (10.1.3.1) or its OG address (201.114.37.5).

In fact, debugging output from host C in Example 4-10 reveals a bit more
detail about the behavior of this network. Host C pings host D on its OG
address, but the source address of the reply packets is host D's OL
address. The ICMP Echo Request packet to destination 201.114.37.5 has passed
through the NAT unchanged, but the ICMP Echo Reply packet, with a source address
of 201.114.37.5, is translated by the NAT to the OL address.

Figure 4-16 Host A Can Send Packets to Either the OL or OG Address of
Host D

Example 4-10 Although Host C Sends Pings to 201.114.37.5, NAT
Causes the Replies to Have a Source Address of 10.1.3.1

If you're recreating these examples in a lab, Example 4-10 reveals a
useful trick. Host C is actually a Cisco router with IP routing disabled (no
ip routing) and an ip default-gateway command pointing to
Veracruz's locally attached interface. As Example 4-10 demonstrates, this
setup enables you to use the IOS's extensive debugging tools to observe
network behavior from a host's perspective.

If the administrator of the inside network wants to prevent traffic from
being sent to OG addresses, he must implement a filter, as shown in Example
4-11.

Example 4-11 Implementing a Filter to Prevent Traffic of the Inside Network
from Being Sent to OG Addresses

Notice that an incoming filter is used on interface E0. The filtering must
take place before the address translation; an outgoing filter on S1.705 would
have no way to differentiate the already translated destination address. Figure 4-17 shows the results of the filter; host A can still reach host D on its OL
address, but packets to the OG address are blocked.

Figure 4-17 After the Filter Is Implemented on Mazatlan, Inside Hosts Can
Only Reach Host D via Its OL Address

The debug output in Example 4-10 and Example 4-6 emphasizes the fact
that NAT does not, by itself, guarantee that private or illegal IP addresses do
not leak into the public Internet. Wise administrators filter for the private
Class A, B, and C addresses on interfaces connected to ISPs. Wise ISPs do the
same on interfaces connected to their subscribers.

A difficulty with the various configurations shown in this case study so far
is that very few "real-life" devices will use IP addresses to reach
other devices. Names are almost always used. Therefore, DNS servers must have
the correct IP addresses relevant to their side of the NAT. In Figure 4-18, DNS
servers are placed on the inside and outside networks. DNS1 might have the
following name-to-address mappings:

HostA.insidenet.com IN A 10.1.1.3
HostB.insidenet.com IN A 10.1.1.4
HostC.insidenet.com IN A 10.1.2.2

Here, all hosts have local addresses (local to the inside network). DNS2
might have the following name-to-address mapping:

HostD.outsidenet.com IN A 201.114.37.5

These entries all map to global addresses. DNS1 is authoritative for
inside.net, and DNS2 is authoritative for outside.net. Example 4-12 shows the
NAT configuration for Mazatlan.

Figure 4-18 DNS1 Is Authoritative for the Inside Network, and DNS2 Is
Authoritative for the Outside Network

In addition to the three inside hosts and one outside host, the configuration
in Example 4-12 has entries for the two DNS servers. If host A wants to send a
packet to host D, it sends a DNS query to DNS1 for the address of
HostD.outsidenet.com. DNS1 then queries DNS2, which returns an address of
201.114.37.5. When this DNS message passes through the NAT, the address is
translated to 10.1.3.1, and DNS1 passes this address on to host A. Host A then
sends packets to this address, and the NAT translates the source and destination
addresses of the packets.

If host D wants to speak to a host on the inside network, the opposite
happens. Host D might query DNS2 for the address of HostC.insidenet.com,
prompting DNS2 to query DNS1. DNS1 responds with an address of 10.1.2.2, which
is translated to 204.15.87.2 by the NAT and passed to host D by DNS2. Again,
when packets are exchanged between host D and host C, the NAT translates the
source and destination addresses.

Case Study: Dynamic NAT

The problem with the configurations of the preceding case study is one of
scalability. What if, instead of the four inside devices shown in Figure 4-18,
there are 60 or 6000? Maintaining static NAT mappings, like maintaining static
route entries, quickly becomes an administrative burden as the network
grows.

The inside network in Figure 4-19 uses 10.1.1.010.1.2.255 for its IL
address space and has been assigned the public address space 204.15.86.0/23 by
its ISP. This public address space is used as a pool from which IG addresses are
dynamically selected for mapping to the IL addresses. To make things more
manageable and predictable, the space 10.1.1.0/24 is mapped to 204.15.86.0/24,
and 10.1.2.0/24 is mapped to 204.15.87.0/24.

Figure 4-19 The Inside Network Has a Large Range of IL and IG
Addresses

The ip nat pool command creates a pool of addresses and gives it a
name. The pool is then designated as an IG pool and is linked to an IL address
range with the command ip nat inside source list. Example 4-13 shows the
configuration for Mazatlan.

Two pools are created, named PoolOne and PoolTwo. PoolOne is assigned an
address range of 204.15.86.1204.15.86.254. PoolTwo is assigned an address
range of 204.15.87.1204.15.87.253. Notice that the address ranges exclude
the network addresses and the broadcast addresses; the netmask portion of
the commands acts as a sanity check, ensuring that such addresses as
204.15.87.255 are not mapped. An alternative to using the netmask keyword
is the prefix-length. For example:

ip nat pool PoolTwo 204.15.87.1 204.15.87.253 prefix-length 24

has the same effect as the command with the netmask 255.255.255.0
keyword. Because of these commands, you can assign a range such as
204.15.86.0204.15.86.255, and the "0" and "255" host
addresses will not be mapped. However, it is good practice to configure only the
actual pool addresses to avoid confusion.

Notice also that PoolTwo does not include the address 204.15.87.254. This
address is statically assigned to DNS1 and so is left out of the pool. Any time
an outside device must be able to initiate a session to an inside device, as in
the case of DNS1, there must be a statically assigned address. If its IG address
were dynamic, outside devices would have no way of knowing to which address to
send packets.

Next, access lists are used to identify the addresses to be translated. In
Mazatlan's configuration, access list 1 identifies the IL range
10.1.1.010.1.1.255, and access list 2 identifies the IL range
10.1.2.010.1.2.255.

Last, the IL addresses are linked to the correct pool. For example, the
statement ip nat inside source list 1 pool PoolOne says that an IP
address sourced from the inside (that is, IL addresses) and matching the range
specified in access list 1 is to be translated to an IG address taken from
PoolOne.

Example 4-14 shows Mazatlan's NAT table just after the dynamic NAT
configuration is added. You can see that the only mapping in the table is the
static entry for DNS1.

Example 4-14 When Mazatlan's Dynamic NAT Is First Configured, No
Entries Reside in the NAT Table Except for the Single Static Entry

Example 4-15 shows the NAT table after several inside devices have originated
traffic to the outside. The IG addresses are allocated from each pool
numerically, beginning with the lowest available number.

Example 4-15 Dynamic IL-to-IG Mappings Are Entered into the NAT Table as
Inside Devices Send Packets to the Outside

Occasionally, a network administrator might want the host portion of the IG
address to match the host portion of the IL address to which it is mapped. To
accomplish this, the keywords type match-host are added to the end of the
statement defining the pool, as demonstrated in Example 4-16.

Example 4-16 Configuring the Host Portion of the IG Address to Match the
Host Portion of the IL Address to Which It Is Mapped

Example 4-17 shows the resulting NAT table. Comparing it with the table in
Example 4-15, you can see that all the same IL addresses have been translated.
Instead of selecting IG addresses from their respective pools sequentially,
however, IG addresses are selected with matching host portions.

Example 4-17 The Host Portions of the IG Addresses Match the Host Portions
of the IL Addresses to Which They Are Mapped

By default, the dynamic entries are held in the NAT table for 86,400 seconds
(24 hours). You can change this time with the command ip nat translation
timeout to any time between 0 and 2,147,483,647 seconds (approximately 68
years). The timeout period begins when a translation is first made and is reset
each time a packet is translated by the mapping. While a pool address is mapped
to an address in the NAT table, it cannot be mapped to any other address. If the
timeout period elapses with no new "hits" to the mapping, the entry is
removed from the table, and the pool address is returned to the pool and becomes
available. If you use 0 seconds or the keyword never with the ip nat
translation timeout command, the mapping is never removed from the NAT
table.

The translation timeout for each entry appears with the show ip nat
translations verbose command, as demonstrated in Example 4-18. The ip nat
translations verbose command shows how long ago the mapping was entered into
the NAT table, how long ago the mapping was last used to translate an address,
and the time remaining before the end of the timeout period. You can use the
Flags field to indicate translation types other than dynamic. In Example 4-18,
for instance, the last entry is shown to be a static translation.

Example 4-18 The show ip nat translations verbose Command Reveals Details
About the Translation Timeout Periods for Each Mapping

Example 4-19 1022 IL Addresses Share a Pool of 254 IG Addresses

Here, 1022 possible IL addresses10.1.0.1 through 10.1.3.254are
translated using a pool of 254 available IG addresses. That means that when the
NAT table contains 254 mapping entries, no more available IG addresses exist.
Any packets with IL addresses that have not already been mapped are dropped. The
designer of such an addressing scheme is gambling that only a fraction of the
total users in the network will need outside access. With each mapping remaining
in the NAT table for 24 hours, however, the chances of using up all available IG
addresses increase substantially. By reducing the translation timeout, the
designer can reduce this likelihood.

Case Study: A Network Merger

NAT 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.

Figure 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.

Figure 4-21 NAT Is Used at the Boundaries of the Two Internetworks to
Correct the Address Conflicts

The DNS servers are crucial to this design. In the NAT configurations, each
server has a static IL-to-IG mapping. Suppose a device in the Sand internetwork,
Beachball.sand.com, wants to send a packet to Snorkel.surf.com in the Surf
internetwork. Suppose further that both devices have an IP address of 10.1.2.2.
The following sequence of events occurs:

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.

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.

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.

Figure 4-22 The Internet Access Router Does Not Have to Support NAT; All
Translations for Internet Traffic Are Performed by Cozumel and Guaymas

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.

Figure 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.

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

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.

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

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.

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

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.

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

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.

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

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

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

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.

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

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

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-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