Home > Articles > Cisco Certification > CCIE > Network Address Translation

Network Address Translation

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Feb 8, 2002.

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.

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

Example 4-4 Implementing Static NAT at Router Mazatlan in Figure 4-15

interface Ethernet0
 ip address 10.1.1.1 255.255.255.0
 ip nat inside
!
interface Serial1
 no ip address
 encapsulation frame-relay
!
interface Serial1.705 point-to-point
 ip address 199.100.35.254 255.255.255.252
 ip nat outside
 frame-relay interface-dlci 705
!
router ospf 100
 network 10.1.1.1 0.0.0.0 area 0
 default-information originate
!
ip nat inside source static 10.1.2.2 204.15.87.2
ip nat inside source static 10.1.1.3 204.15.87.1
!
ip route 0.0.0.0 0.0.0.0 199.100.35.253
!

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

Mazatlan#show ip nat translations 
Pro Inside global   Inside local    Outside local   Outside global
--- 204.15.87.2    10.1.2.2      ---        ---
--- 204.15.87.1    10.1.1.3      ---        ---
Mazatlan#

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

Acapulco#debug ip icmp 
ICMP packet debugging is on
Acapulco#
1d00h: ICMP: dst (10.1.1.4) host unreachable sent to 201.114.37.5
1d00h: ICMP: dst (10.1.1.4) host unreachable sent to 201.114.37.5
1d00h: ICMP: dst (10.1.1.4) host unreachable sent to 201.114.37.5
1d00h: ICMP: dst (10.1.1.4) host unreachable sent to 201.114.37.5
1d00h: ICMP: dst (10.1.1.4) host unreachable sent to 201.114.37.5

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.

Example 4-7 Configuring Mazatlan to Statically Translate Outside Global Addresses to Outside Local Addresses

ip nat inside source static 10.1.1.3 204.15.87.1
ip nat inside source static 10.1.2.2 204.15.87.2
ip nat outside source static 201.114.37.5 10.1.3.1

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

Mazatlan#show ip nat translations 
Pro Inside global   Inside local    Outside local   Outside global
--- 204.15.87.2    10.1.2.2      ---        ---
--- 204.15.87.1    10.1.1.3      ---        ---
--- ---        ---        10.1.3.1      201.114.37.5
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

Mazatlan#show ip nat translations 
Pro Inside global   Inside local    Outside local   Outside global
--- 204.15.87.2    10.1.2.2      ---        ---
--- 204.15.87.1    10.1.1.3      ---        ---
--- ---        ---        10.1.3.1      201.114.37.5
--- 204.15.87.1    10.1.1.3      10.1.3.1      201.114.37.5
--- 204.15.87.2    10.1.2.2      10.1.3.1      201.114.37.5
Mazatlan#

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

HostC#debug ip icmp
ICMP packet debugging is on
HostC#ping 201.114.37.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 201.114.37.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/20 ms
HostC#
ICMP: echo reply rcvd, src 10.1.3.1, dst 10.1.2.2
ICMP: echo reply rcvd, src 10.1.3.1, dst 10.1.2.2
ICMP: echo reply rcvd, src 10.1.3.1, dst 10.1.2.2
ICMP: echo reply rcvd, src 10.1.3.1, dst 10.1.2.2
ICMP: echo reply rcvd, src 10.1.3.1, dst 10.1.2.2
HostC#

TIP

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

interface Ethernet0
 ip address 10.1.1.1 255.255.255.0
 ip access-group 101 in
 ip nat inside
!
interface Serial1
 no ip address
 encapsulation frame-relay
!
interface Serial1.705 point-to-point
 ip address 199.100.35.254 255.255.255.252
 ip nat outside
 frame-relay interface-dlci 705
!
router ospf 100
 network 10.1.1.1 0.0.0.0 area 0
 default-information originate
!
ip nat inside source static 10.1.1.3 204.15.87.1
ip nat inside source static 10.1.2.2 204.15.87.2
ip nat outside source static 201.114.37.5 10.1.3.1
!
ip route 0.0.0.0 0.0.0.0 199.100.35.253
!
access-list 101 permit ip any host 10.1.3.1
!

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

Example 4-12 Mazatlan's NAT Configuration, Supporting DNS1 and DNS2 in Figure 4-18

ip nat inside source static 10.1.1.3 204.15.87.1
ip nat inside source static 10.1.2.2 204.15.87.2
ip nat inside source static 10.1.1.4 204.15.87.3
ip nat inside source static 10.1.1.254 204.15.87.254
ip nat outside source static 201.114.37.5 10.1.3.1
ip nat outside source static 201.50.34.1 10.1.3.2

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.

Example 4-13 Mazatlan Is Configured to Dynamically Assign IG Addresses from an Address Pool

interface Ethernet0
 ip address 10.1.1.1 255.255.255.0
 ip nat inside
!
interface Serial1
 no ip address
 encapsulation frame-relay
!
interface Serial1.705 point-to-point
 ip address 199.100.35.254 255.255.255.252
 ip nat outside
 frame-relay interface-dlci 705
! 
router ospf 100
 network 10.1.1.1 0.0.0.0 area 0
 default-information originate
!
ip nat pool PoolOne 204.15.86.1 204.15.86.254 netmask 255.255.255.0
ip nat pool PoolTwo 204.15.87.1 204.15.87.253 netmask 255.255.255.0
ip nat inside source list 1 pool PoolOne
ip nat inside source list 2 pool PoolTwo
ip nat inside source static 10.1.1.254 204.15.87.254
!
ip route 0.0.0.0 0.0.0.0 199.100.35.253
!
access-list 1 permit 10.1.1.0 0.0.0.255
access-list 2 permit 10.1.2.0 0.0.0.255
!

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

Mazatlan#show ip nat translations 
Pro Inside global   Inside local    Outside local   Outside global
--- 204.15.87.254   10.1.1.254     ---        ---
Mazatlan#

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

Mazatlan#show ip nat translations 
Pro Inside global   Inside local    Outside local   Outside global
--- 204.15.86.4    10.1.1.3      ---        ---
--- 204.15.86.3    10.1.1.83     ---        ---
--- 204.15.86.2    10.1.1.239     ---        ---
--- 204.15.86.1    10.1.1.4      ---        ---
--- 204.15.87.3    10.1.2.164     ---        ---
--- 204.15.87.2    10.1.2.57     ---        ---
--- 204.15.87.1    10.1.2.2      ---        ---
--- 204.15.87.254   10.1.1.254     ---        ---
Mazatlan#

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

ip nat pool PoolOne 204.15.86.1 204.15.86.254 netmask 255.255.255.0 type match-host
ip nat pool PoolTwo 204.15.87.1 204.15.87.253 netmask 255.255.255.0 type match-host
ip nat inside source list 1 pool PoolOne
ip nat inside source list 2 pool PoolTwo
ip nat inside source static 10.1.1.254 204.15.87.254
!
ip route 0.0.0.0 0.0.0.0 199.100.35.253
!
access-list 1 permit 10.1.1.0 0.0.0.255
access-list 2 permit 10.1.2.0 0.0.0.255

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

Mazatlan#show ip nat translations
Pro Inside global   Inside local    Outside local   Outside global
--- 204.15.86.4    10.1.1.4      ---        ---
--- 204.15.86.3    10.1.1.3      ---        ---
--- 204.15.86.83    10.1.1.83     ---        ---
--- 204.15.86.239   10.1.1.239     ---        ---
--- 204.15.87.2    10.1.2.2      ---        ---
--- 204.15.87.57    10.1.2.57     ---        ---
--- 204.15.87.164   10.1.2.164     ---        ---
--- 204.15.87.254   10.1.1.254     ---        ---
Mazatlan#

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

Mazatlan#show ip nat translations verbose
Pro Inside global   Inside local    Outside local   Outside global
--- 204.15.86.4    10.1.1.3      ---        ---
  create 00:31:55, use 00:31:55, left 23:28:04, flags: none
--- 204.15.86.3    10.1.1.83     ---        ---
  create 00:32:19, use 00:32:19, left 23:27:40, flags: none
--- 204.15.86.2    10.1.1.239     ---        ---
  create 00:33:38, use 00:33:38, left 23:26:21, flags: none
--- 204.15.86.1    10.1.1.4      ---        ---
  create 00:34:25, use 00:00:05, left 23:59:54, flags: none
--- 204.15.87.3    10.1.2.164     ---        ---
  create 00:31:02, use 00:31:02, left 23:28:57, flags: none
--- 204.15.87.2    10.1.2.57     ---        ---
  create 00:34:10, use 00:34:10, left 23:25:49, flags: none
--- 204.15.87.1    10.1.2.2      ---        ---
  create 00:35:04, use 00:35:04, left 23:24:55, flags: none
--- 204.15.87.254   10.1.1.254     ---        ---
  create 03:59:32, use 03:59:32, flags: static
Mazatlan#

The translation timeout period is important when the range of IL addresses is larger than the pool of IG addresses. Consider the configuration in Example 4-19.

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

ip nat pool GlobalPool 204.15.86.1 204.15.86.254 prefix-length 24 
ip nat inside source list 1 pool GlobalPool
!
access-list 1 permit 10.1.0.0 0.0.3.255

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

Example 4-20 NAT Configurations for Routers Cozumel and Guaymas in Figure 4-21

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

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:

  1. Host Beachball queries DNS2 for the address of Snorkel.surf.com.

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

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

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

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

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

  7. Guaymas translates the destination of the DNS response to 10.16.95.200 and forwards the message to DNS1.

  8. DNS1 informs Beachball that the IP address of Snorkel.surf.com is 206.100.176.3.

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

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

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

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

  13. Cozumel translates the packet's source address to 206.100.176.3 and forwards the packet to Guaymas.

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

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.

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.

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.

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.

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

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

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#

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

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
!

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#
4. Troubleshooting NAT | Next Section Previous Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.

Overview

Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security

Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children

This site is not directed to children under the age of 13.

Marketing

Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out

Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links

This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020