Chapter 15. IP Services

This chapter covers the following subjects:

Time Synchronization: This section describes the need for synchronizing time in an environment and covers Network Time Protocol and its operations to keep time consistent across devices.

First-Hop Redundancy Protocol: This section gives details on how multiple routers can provide resilient gateway functionality to hosts at the Layer 2/Layer 3 boundaries.

Network Address Translation (NAT): This section explains how a router can translate IP addresses from one network realm to another.

In addition to routing and switching network packets, a router can perform additional functions to enhance a network. This chapter covers time synchronization, virtual gateway technologies, and Network Address Translation.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read the entire chapter. If you miss no more than one of these self-assessment questions, you might want to move ahead to the “Exam Preparation Tasks” section. Table 15-1 lists the major headings in this chapter and the “Do I Know This Already?” quiz questions covering the material in those headings so you can assess your knowledge of these specific areas. The answers to the “Do I Know This Already?” quiz appear in Appendix A, “Answers to the ‘Do I Know This Already?’ Quiz Questions.”

Table 15-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

Foundation Topics Section

Questions

Time Synchronization

1–2

First-Hop Redundancy Protocol

3–6

Network Address Translation (NAT)

7–9

1. NTP uses the concept of ________ to calculate the accuracy of the time source.

  1. administrative distance

  2. stratum

  3. atomic half-life

  4. deviation time

2. True or false: An NTP client can be configured with multiple NTP servers and cansynchronize its local clock with all the servers.

  1. True

  2. False

3. In a resilient network topology, first-hop redundancy protocols (FHRP) overcome the limitations of which of the following? (Choose two.)

  1. Static default routes

  2. Link-state routing protocols

  3. Vector-based routing protocols

  4. A computer with only one default gateway

4. Which of the following FHRPs are considered Cisco proprietary? (Choose two.)

  1. VRRP

  2. HSRP

  3. GLBP

  4. ODR

5. Which of the following commands defines the HSRP instance 1 VIP gateway instance 10.1.1.1?

  1. standby 1 ip 10.1.1.1

  2. hsrp 1 ip 10.1.1.1

  3. hsrp 1 vip 10.1.1.1

  4. hsrp 1 10.1.1.1

6. Which of the following FHRPs supports load balancing?

  1. ODR

  2. VRRP

  3. HSRP

  4. GLBP

7. Which command displays the translation table on a router?

  1. show ip translations

  2. show ip xlate

  3. show xlate

  4. show ip nat translations

8. A router connects multiple private networks in the 10.0.0.0/8 network range to the Internet. A user’s IP address of 10.1.1.1 is considered the __________ IP address.

  1. inside local

  2. inside global

  3. outside local

  4. outside global

9. The IP translation table times out and clears dynamic TCP connection entries from the translation table after how long?

  1. 1 hour

  2. 4 hours

  3. 12 hours

  4. 24 hours

Answers to the “Do I Know This Already?” quiz:

1 B

2 B

3 A, D

4 B, C

5 A

6 D

7 D

8 A

9 D

Foundation Topics

Time Synchronization

A device’s system time is used to measure periods of idle state or computation. Ensuring that the time is consistent on a system is important because applications often use the system time to tune internal processes. From the perspective of managing a network, it is important that the time be synchronized between network devices for several reasons:

  • Managing passwords that change at specific time intervals

  • Encryption key exchanges

  • Checking validity of certificates based on expiration date and time

  • Correlation of security-based events across multiple devices (routers, switches, firewalls, network access control systems, and so on)

  • Troubleshooting network devices and correlating events to identify the root cause of an event

The rate at which a device maintains time can deviate from device to device. Even if the time was accurately set on all the devices, the time intervals could be faster on one device than on another device. Eventually the times would start to drift away from each other. Some devices use only a software clock, which is reset when the power is reset. Other devices use a hardware clock, which can maintain time when the power is reset.

Network Time Protocol

RFC 958 introduced Network Time Protocol (NTP), which is used to synchronize a set of network clocks in a distributed client/server architecture. NTP is a UDP-based protocol that connects with servers on port 123. The client source port is dynamic.

NTP is based on a hierarchical concept of communication. At the top of the hierarchy are authoritative devices that operate as an NTP server with an atomic clock. The NTP client then queries the NTP server for its time and updates its time based on the response. Because NTP is considered an application, the query can occur over multiple hops, requiring NTP clients to identify the time accuracy based on messages with other routers.

The NTP synchronization process is not fast. In general, an NTP client can synchronize a large time discrepancy to within a couple seconds of accuracy with a few cycles of polling an NTP server. However, gaining accuracy of tens of milliseconds requires hours or days of comparisons. In some ways, the time of the NTP clients drifts toward the time of the NTP server.

NTP uses the concept of stratums to identify the accuracy of the time clock source. NTP servers that are directly attached to an authoritative time source are stratum 1 servers. An NTP client that queries a stratum 1 server is considered a stratum 2 client. The higher the stratum, the greater the chance of deviation in time from the authoritative time source due to the number of time drifts between the NTP stratums.

Figure 15-1 demonstrates the concept of stratums, with R1 attached to an atomic clock and considered a stratum 1 server. R2 is configured to query R1, so it is considered a stratum 2client. R3 is configured to query R2, so it is considered a stratum 3 client. This could continue until stratum 15. Notice that R4 is configured to query R1 over multiple hops, and it is therefore considered a stratum 2 client.

The concept of NTP stratums is illustrated.

Figure 15-1 NTP Stratums

NTP Configuration

The configuration of an NTP client is pretty straightforward. The client configuration uses the global configuration command ntp server ip-address [prefer] [source interface-id]. The source interface, which is optional, is used to stipulate the source IP address for queries for that server. Multiple NTP servers can be configured for redundancy, and adding the optional prefer keyword indicates which NTP server time synchronization should come from.

Cisco devices can act as a server after they have been able to query an NTP server. For example, in Figure 15-1, once R2 has synchronized time with R1 (a stratum 1 time source), R2 can act as a server to R3. Configuration of external clocks is beyond the scope of this book. However, you should know that you can use the command ntp master stratum-number to statically set the stratum for a device when it acts as an NTP server.

Example 15-1 demonstrates the configuration of R1, R2, R3, and R4 from Figure 15-1.

Example 15-1 Simple Multi-Stratum NTP Configuration

R1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# ntp master 1
R2# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)# ntp server 192.168.1.1
R3# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)# ntp server 192.168.2.2 source loopback 0
R4# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)# ntp server 192.168.1.

To view the status of NTP service, use the command show ntp status, which has the following output in Example 15-2.

  1. Whether the hardware clock is synchronized to the software clock (that is, whether the clock resets during power reset), the stratum reference of the local device, and the reference clock identifier (local or IP address)

  2. The frequency and precision of the clock

  3. The NTP uptime and granularity

  4. The reference time

  5. The clock offset and delay between the client and the lower-level stratum server

  6. Root dispersion (that is, the calculated error of the actual clock attached to the atomic clock) and peer dispersion (that is, the root dispersion plus the estimated time to reach the root NTP server)

  7. NTP loopfilter (which is beyond the scope of this book)

  8. Polling interval and time since last update

Example 15-2 shows the output of the NTP status from R1, R2, and R3. Notice that thestratum has incremented, along with the reference clock.

Example 15-2 Viewing NTP Status

R1# show ntp status
Clock is synchronized, stratum 1, reference is .LOCL.
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**10
ntp uptime is 2893800 (1/100 of seconds), resolution is 4000
reference time is E0E2D211.E353FA40 (07:48:17.888 EST Wed Jul 24 2019)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 2.24 msec, peer dispersion is 1.20 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000000000 s/s
system poll interval is 16, last update was 4 sec ago.
R2# show ntp status
Clock is synchronized, stratum 2, reference is 192.168.1.1
nominal freq is 250.0000 Hz, actual freq is 249.8750 Hz, precision is 2**10
ntp uptime is 2890200 (1/100 of seconds), resolution is 4016
reference time is E0E2CD87.28B45C3E (07:28:55.159 EST Wed Jul 24 2019)
clock offset is 1192351.4980 msec, root delay is 1.00 msec
root dispersion is 1200293.33 msec, peer dispersion is 7938.47 msec
loopfilter state is 'SPIK' (Spike), drift is 0.000499999 s/s
system poll interval is 64, last update was 1 sec ago.
R3# show ntp status
Clock is synchronized, stratum 3, reference is 192.168.2.2
nominal freq is 250.0000 Hz, actual freq is 250.0030 Hz, precision is 2**10
ntp uptime is 28974300 (1/100 of seconds), resolution is 4000
reference time is E0E2CED8.E147B080 (07:34:32.880 EST Wed Jul 24 2019)
clock offset is 0.5000 msec, root delay is 2.90 msec
root dispersion is 4384.26 msec, peer dispersion is 3939.33 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000012120 s/s
system poll interval is 64, last update was 36 sec ago.

A streamlined version of the NTP server status and delay is provided with the command show ntp associations. The address 127.127.1.1 reflects to the local device when configured with the ntp master stratum-number command. Example 15-3 shows the NTP associations for R1, R2, and R3.

Example 15-3 Viewing the NTP Associations

R1# show ntp associations

  address         ref clock       st   when   poll reach  delay  offset   disp
*~127.127.1.1     .LOCL.  0      0     16   377  0.000   0.000  1.204
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
SW1# show ntp associations

  address         ref clock       st   when   poll reach  delay  offset   disp
*~192.168.1.1     127.127.1.1      1    115   1024     1  1.914   0.613 191.13
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
SW2# show ntp associations

  address         ref clock       st   when   poll reach  delay  offset   disp
*~192.168.2.2     192.168.1.1      2     24     64     1  1.000   0.500 440.16
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

Stratum Preference

An NTP client can be configured with multiple NTP servers. The device will use only the NTP server with the lowest stratum. The top portion of Figure 15-2 shows R4 with two NTP sessions: one session with R1 and another with R3.

The NTP stratum preferences is illustrated.

Figure 15-2 NTP Stratum Preferences

In the topology shown in Figure 15-2, R4 will always use R1 for synchronizing its time because it is a stratum 1 server. If R2 crashes, as shown at the bottom of Figure 15-2, preventing R4 from reaching R1, it synchronizes with R3’s time (which may or may not be different due to time drift) and turns into a stratum 4 time device. When R2 recovers, R4 synchronizes with R1 and becomes a stratum 2 device again.

NTP Peers

Within the NTP client architecture, the NTP client changes its time to the time of the NTP server. The NTP server does not change its time to reflect the clients. Most enterprise organizations (such as universities, governments, and pool.ntp.org) use an external NTP server. A common scenario is to designate two devices to query a different external NTP source and then to peer their local stratum 2 NTP devices.

NTP peers act as clients and servers to each other, in the sense that they try to blend their time to each other. The NTP peer model is intended for designs where other devices can act as backup devices for each other and use different primary reference sources.

Figure 15-3 shows a scenario where R1 is an NTP client to 100.64.1.1, and R2 is an NTP client to 100.64.2.2. R1 and R2 are NTP peers with each other, so they query each other and move their time toward each other.

A figure represents NTP stratums.

Figure 15-3 NTP Stratums

Note

An NTP peer that is configured with an authoritative time source treats its peer as an equal and shifts its clock to synchronize with the peer. The peers adjust at a maximum rate of two minutes per query, so large discrepancies take some time to correct.

NTP peers are configured with the command ntp peer ip-address. Example 15-4 shows the sample NTP peer configuration for R1 and R2 (refer to Figure 15-3) peering with their loopback interfaces.

Example 15-4 NTP Peer Configuration

R1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# ntp peer 192.168.2.2
R2# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)# ntp peer 192.168.1.

First-Hop Redundancy Protocol

Network resiliency is a key component of network design. Resiliency with Layer 2 forwarding is accomplished by adding multiple Layer 2 switches into a topology. Resiliency with Layer 3 forwarding is accomplished by adding multiple Layer 3 paths or routers.

Figure 15-4 shows the concept of adding resiliency by using multiple Layer 2 switches and routers on the left or by adding resiliency with multiple multi-layer switches on the right. In both scenarios:

  • Two devices (172.16.1.2 and 172.16.1.3) can be the PC’s gateway.

  • There are two resilient Layer 2 links that connect SW6 to a switch that can connect the PC to either gateway.

The process of adding resiliency with redundancy with layer 2 and layer 3 devices is illustrated.

Figure 15-4 Resiliency with Redundancy with Layer 2 and Layer 3 Devices

Note

STP is blocking traffic between SW6 and SW5 on the left and between SW6 and SW3 on the right in Figure 15-4.

The PC could configure its gateway as 172.16.1.2, but what happens when that device fails? The same problem occurs if the other gateway was configured. How can a host be configured with more than one gateway? Some operating systems support the configuration of multiple gateways, and others do not. Providing gateway accessibility to all devices is very important.

The deployment of first-hop redundancy protocols (FHRPs) solves the problem of hosts configuring multiple gateways. FHRPs work by creating a virtual IP (VIP) gateway instance that is shared between the Layer 3 devices. This book covers the following FHRPs:

  • Hot Standby Router Protocol (HSRP)

  • Virtual Router Redundancy Protocol (VRRP)

  • Gateway Load Balancing Protocol (GLBP)

Object Tracking

FHRPs are deployed in a network for reliability and high availability to ensure load balancing and failover capability in case of a router failover. To ensure optimal traffic flow when a WAN link goes down, it would be nice to be able to determine the availability of routes or the interface state to which FHRP route traffic is directed.

Object tracking offers a flexible and customizable mechanism for linking with FHRPs and other routing components (for example, conditional installation of a static route). With this feature, users can track specific objects in the network and take necessary action when any object’s state change affects network traffic.

Figure 15-5 shows a simple topology with three routers exchanging routes with EIGRP and advertising their loopback interfaces to EIGRP.

A figure illustrates object tracking.

Figure 15-5 Object Tracking

Tracking of routes in the routing table is accomplished with the command track object-number ip route route/prefix-length reachability. The status object tracking can be viewed with the command show track [object-number].

Example 15-5 shows R1 being configured for tracking the route to R3’s loopback interface. The route is installed in R1’s RIB, and the tracked object state is up.

Example 15-5 Tracking R3’s Loopback Interface

R1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# track 1 ip route 192.168.3.3/32 reachability
R1# show track
Track 1
  IP route 192.168.3.3 255.255.255.255 reachability
  Reachability is Up (EIGRP)
    1 change, last change 00:00:32
  First-hop interface is GigabitEthernGi0/

Tracking of an interface’s line protocol state is accomplished with the command track object-number interface interface-id line-protocol.

Example 15-6 shows R2 being configured for tracking the Gi0/1 interface toward R3. The line protocol for the interface is up.

Example 15-6 Tracking R2’s Gi0/1 Interface Line Protocol State

R2# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)# track 2 interface GigabitEthernGi0/1 line-protocol
R2# show track
Track 2
  Interface GigabitEthernGi0/1 line-protocol
  Line protocol is Up
    1 change, last change 00:00:37

Shutting down R2’s Gi0/1 interface should change the tracked object state on R1 and R2 to a down state. Example 15-7 shows the shutdown of R2’s Gi0/1 interface. Notice that the tracked state for R2 and R1 changed shortly after the interface was shut down.

Example 15-7 Demonstrating a Change of Tracked State

R2# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)# interface GigabitEthernGi0/1
R2(config-if)# shutdown
*03:04:18.975: %TRACK-6-STATE: 2 interface Gi0/1 line-protocol Up -> Down
*03:04:18.980: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.23.1.3
(GigabitEthernGi0/1) is * 03:04:20.976: %LINK-5-CHANGED: Interface
GigabitEthernGi0/1, changed state to administratively down
* 03:04:21.980: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernGi0/1, changed state to down
R1#
03:04:24.007: %TRACK-6-STATE: 1 ip route 192.168.3.3/32 reachability Up -> Dow

Example 15-8 shows the current track state for R1 and R2. R1 no longer has the 192.168.3.3/32 network in the RIB, and R2’s Gi0/1 interface is in shutdown state.

Example 15-8 Viewing the Track State After a Change

R1# show track
Track 1
  IP route 192.168.3.3 255.255.255.255 reachability
  Reachability is Down (no ip route)
    2 changes, last change 00:02:09
  First-hop interface is unknown
R2#

Track 2
  Interface GigabitEthernGi0/1 line-protocol
  Line protocol is Down ((hw admin-down))
    2 changes, last change 00:01:5

Object tracking works with protocols such as Hot Standby Router Protocol (HSRP), Virtual Router Redundancy Protocol (VRRP), and Gateway Load Balancing Protocol (GLBP) so that they take action when the state of an object changes. FHRP commonly tracks the availability of the WAN interface or the existence of a route learned via that next hop.

Hot Standby Router Protocol

Hot Standby Routing Protocol (HSRP) is a Cisco proprietary protocol that provides transparent failover of the first-hop device, which typically acts as a gateway to the hosts.

HSRP provides routing redundancy for IP hosts on an Ethernet network configured with a default gateway IP address. A minimum of two devices are required to enable HSRP: One device acts as the active device and takes care of forwarding the packets, and the other acts as a standby that is ready to take over the role of active device in the event of a failure.

On a network segment, a virtual IP address is configured on each HSRP-enabled interface that belongs to the same HSRP group. HSRP selects one of the interfaces to act as the HSRP active router. Along with the virtual IP address, a virtual MAC address is assigned for the group. The active router receives and routes the packets destined for the virtual MAC address of the group.

When the HSRP active router fails, the HSRP standby router assumes control of the virtual IP address and virtual MAC address of the group. The HSRP election selects the router with the highest priority (which defaults to 100). In the event of a tie in priority, the router with the highest IP address for the network segment is preferred.

Note

HSRP does not support preemption by default, so when a router with lower priority becomes active, it does not automatically transfer its active status to a superior router.

HSRP-enabled interfaces send and receive multicast UDP-based hello messages to detect any failure and designate active and standby routers. If a standby device does not receive a hello message or the active device fails to send a hello message, the standby device with the second highest priority becomes HSRP active. The transition of HSRP active between the devices is transparent to all hosts on the segment because the MAC address moves with the virtual IP address.

HSRP has two versions: Version 1 and Version 2. Table 15-2 shows some of the differences between HSRPv1 and HSRPv2:

Table 15-2 HSRP Versions

 

HSRPv1

HSRPv2

Timers

Does not support millisecond timer values

Supports millisecond timer values

Group range

0 to 255

0 to 4095

Multicast address

224.0.0.2

224.0.0.102

MAC address range

0000.0C07.ACxy, where xy is a hex value representing the HSRP group number

0000.0C9F.F000 to 0000.0C9F.FFFF

Figure 15-6 shows a sample topology where SW2 and SW3 are the current gateway devices for VLAN 10. VLAN 1 provides transit routing to the WAN routers.

A sample HSRP topology is shown.

Figure 15-6 Sample HSRP Topology

The following steps show how to configure an HSRP virtual IP (VIP) gateway instance:

Step 1. Define the HSRP instance by using the command standby instance-id ip vip-address.

Step 2. (Optional) Configure HSRP router preemption to allow a more preferred router to take the active router status from an inferior active HSRP router. Enable preemption with the command standby instance-id preempt.

Step 3. (Optional) Define the HSRP priority by using the command standby instance-id priority priority. The priority is a value between 0 and 255.

Step 4. Define the HSRP MAC Address (Optional).

The MAC address can be set with the command standby instance-id mac-address mac-address. Most organizations accept the automatically generated MAC address, but in some migration scenarios, the MAC address needs to be statically set to ease transitions when the hosts may have a different MAC address in their ARP table.

Step 5. (Optional) Define the HSRP timers by using the command standby instance-id timers {seconds | msec milliseconds}. HSRP can poll in intervals of 1 to 254 seconds or 15 to 999 milliseconds.

Step 6. (Optional) Establish HSRP authentication by using the command standby instance-id authentication {text-password | text text-password | md5 {key-chain key-chain | key-string key-string}}.

Note

It is possible to create multiple HSRP instances for the same interface. Some network architects configure half of the hosts for one instance and the other half of the hosts for a second instance. Setting different priorities for each instance makes it possible to load balance the traffic across multiple routers.

Example 15-9 shows a basic HSRP configuration for VLAN 10 on SW1 and SW2, using the HSRP instance 10 and the VIP gateway instance 172.16.10.1. Notice that once preemption was enabled, that SW3 became the active speaker, and SW2 became the standby speaker.

Example 15-9 Simple HSRP Configuration

SW2# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
SW2(config)# interface vlan 10
03:55:35.148: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan10, changed state to down
SW2(config-if)# ip address 172.16.10.2 255.255.255.0
SW2(config-if)# standby 10 ip 172.16.10.1
03:56:00.097: %HSRP-5-STATECHANGE: Vlan10 Grp 10 state Speak -> Standby
SW2(config-if)# standby 10 preempt
SW3(config)# interface vlan 10
03:56:04.478: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan10, changed state
to down
SW3(config-if)# ip address 172.16.10.3 255.255.255.0
SW3(config-if)# standby 10 ip 172.16.10.1
SW1(config-if)# standby 10 preempt
03:58:22.113: %HSRP-5-STATECHANGE: Vlan10 Grp 10 state Standby -> Active

The HSRP status can be viewed with the command show standby [interface-id] [brief]. Specifying an interface restricts the output to a specific interface; this can be useful when troubleshooting large amounts of information.

Example 15-10 shows the command show standby brief being run on SW2, which includes the interfaces and the associated groups that are running HSRP. The output also includes the local interface’s priority, whether preemption is enabled, the current state, the active speaker’s address, the standby speaker’s address, and the VIP gateway instance for that standby group.

Example 15-10 Viewing the Summarized HSRP State

SW2# show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp  Pri P State   Active          Standby         Virtual IP
Vl10        10   100 P Standby 172.16.10.3     local           172.16.10.1
SW3# show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp  Pri P State   Active          Standby         Virtual IP
Vl10        10   100 P Active  local           172.16.10.2     172.16.10.1

The non-brief iteration of the show standby command also includes the number of state changes for the HSRP instance, along with the time since the last state change, the timers, and a group name, as shown in Example 15-11.

Example 15-11 Viewing the HSRP State

SW2# show standby
Vlan10 - Group 10
  State is Standby
    9 state changes, last state change 00:13:12
  Virtual IP address is 172.16.10.1
  Active virtual MAC address is 0000.0c07.ac0a (MAC Not In Use)
    Local virtual MAC address is 0000.0c07.ac0a (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 0.736 secs
  Preemption enabled
  Active router is 172.16.10.3, priority 100 (expires in 10.032 sec)
  Standby router is local
  Priority 100 (default 100)
  Group name is "hsrp-Vl10-10" (default)
SW3# show standby
Vlan10 - Group 10
  State is Active
    5 state changes, last state change 00:20:01
  Virtual IP address is 172.16.10.1
  Active virtual MAC address is 0000.0c07.ac0a (MAC In Use)
    Local virtual MAC address is 0000.0c07.ac0a (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 1.024 secs
  Preemption enabled
  Active router is local
  Standby router is 172.16.10.2, priority 100 (expires in 11.296 sec)
  Priority 100 (default 100)
  Group name is "hsrp-Vl10-10" (default)ç

HSRP provides the capability to link object tracking to priority. For example, assume that traffic should flow through SW2’s WAN connection whenever feasible. Traffic can be routed by SW3 to SW2 and then on to SW2’s WAN connection; however, making SW2 the VIP gateway streamlines the process. But when SW2 loses its link to the WAN, it should move the HSRP active speaker role to SW3.

This configuration is accomplished as follows:

  • Configure a tracked object to SW2’s WAN link (in this example, VLAN 1).

  • Change SW2’s priority to a value higher than SW3 (in this case, 110).

  • Configure SW2 to lower the priority if the tracked object state changes to down. This is accomplished with the command standby instance-id track object-id decrement decrement-value. The decrement value should be high enough so that when it is removed from the priority, the value is lower than that of the other HSRP router.

Example 15-12 shows the configuration of SW2 where a tracked object is created against VLAN 1’s interface line protocol, increasing the HSRP priority to 110, and linking HSRP to the tracked object so that the priority decrements by 20 if interface VLAN 1 goes down.

Example 15-12 Correlating HSRP to Tracked Objects

SW2(config)# track 1 interface vlan 1 line-protocol
SW2(config-track)# interface vlan 10
SW2(config-if)# standby 10 priority 110
04:44:16.973: %HSRP-5-STATECHANGE: Vlan10 Grp 10 state Standby -> Active
SW2(config-if)# standby 10 track 1 decrement 20

Example 15-13 shows that the HSRP group on VLAN 10 on SW2 correlates the status of the tracked object for the VLAN 1 interface.

Example 15-13 Verifying the Linkage of HSRP to Tracked Objects

SW2# show standby
! Output omitted for brevity                                                         
Vlan10 - Group 10
  State is Active
    10 state changes, last state change 00:06:12
  Virtual IP address is 172.16.10.1
..                                                                                   
  Preemption enabled
  Active router is local
  Standby router is 172.16.10.3, priority 100 (expires in 9.856 sec)
  Priority 110 (configured 110)                                                      
    Track object 1 state Up decrement 20                                             

Example 15-14 verifies the anticipated behavior by shutting down the VLAN 1 interface on SW2. The syslog messages indicate that the object track state changed immediately after the interface was shut down, and shortly thereafter, the HSRP role changed to a standby state. The priority was modified to 90 because of the failure in object tracking, making SW2’s interface less preferred to SW3’s interface of 100.

Example 15-14 Verifying the Change of HSRP State with Object Tracking

SW2# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
SW2(config)# interface vlan 1
SW2(config-if)# shut
 04:53:16.490: %TRACK-6-STATE: 1 interface Vl1 line-protocol Up -> Down
 04:53:17.077: %HSRP-5-STATECHANGE: Vlan10 Grp 10 state Active -> Speak
 04:53:18.486: %LINK-5-CHANGED: Interface Vlan1, changed state to administratively down
 04:53:19.488: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down
 04:53:28.267: %HSRP-5-STATECHANGE: Vlan10 Grp 10 state Speak -> Standby
SW2# show standby
! Output omitted for brevity                                                         
Vlan10 - Group 10
  State is Standby
    12 state changes, last state change 00:00:39
..
  Active router is 172.16.10.3, priority 100 (expires in 9.488 sec)
  Standby router is local
  Priority 90 (configured 110)                                                       
    Track object 1 state Down decrement 20                                           
  Group name is "hsrp-Vl10-10" (default)

Virtual Router Redundancy Protocol

Virtual Router Redundancy Protocol (VRRP) is an industry standard and operates similarly to HSRP. The behavior of VRRP is so close to that of HSRP that the following differences should be noted:

  • The preferred active router controlling the VIP gateway is called the master router. All other VRRP routers are known as backup routers.

  • VRRP enables preemption by default.

  • The MAC address of the VIP gateway uses the structure 0000.5e00.01xx, where xx reflects the group ID in hex.

  • VRRP uses the multicast address 224.0.0.18 for communication.

There are currently two versions of VRRP:

  • VRRPv2: Supports IPv4

  • VRRPv3: Supports IPv4 and IPv6

The following sections review these versions.

Legacy VRRP Configuration

Early VRRP configuration supported only VRRPv2 and was non-hierarchical in its configuration. The following steps are used for configuring older software versions with VRRP:

Step 1. Define the VRRP instance by using the command vrrp instance-id ip vip-address.

w

Step 2. (Optional) Define the VRRP priority by using the command vrrp instance-id priority priority. The priority is a value between 0 and 255.

Step 3. (Optional) Enable object tracking so that the priority is decremented when the object is false. Do so by using the command vrrp instance-id track object-id decrement decrement-value. The decrement value should be high enough so that when it is removed from the priority, the value is lower than that of the other VRRP router.

Step 4. (Optional) Establish VRRP authentication by using the command vrrp instance-id authentication {text-password | text text-password | md5 {key-chain key-chain | key-string key-string}}.

R2 and R3 are two routes that share a connection to a Layer 2 switch with their Gi0/0 interfaces, which both are on the 172.16.20.0/24 network. R2 and R3 use VRRP to create the VIP gateway 172.16.20.1.

Example 15-15 shows the configuration. Notice that after the VIP is assigned to R3, R3 preempts R2 and becomes the master.

Example 15-15 Legacy VRRP Configuration

R2# configure term
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)# interface GigabitEthernet 0/0
R2(config-if)# ip address 172.16.20.2 255.255.2
R2(config-if)# vrrp 20 ip 172.16.20.1
 04:32:14.109: %VRRP-6-STATECHANGE: Gi0/0 Grp 20 state Init -> Backup
 04:32:14.113: %VRRP-6-STATECHANGE: Gi0/0 Grp 20 state Init -> Backup
 04:32:17.728: %VRRP-6-STATECHANGE: Gi0/0 Grp 20 state Backup -> Master
 04:32:47.170: %VRRP-6-STATECHANGE: Gi0/0 Grp 20 state Master -> Backup
R3# configure term
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)# interface GigabitEthernGi0/0
R3(config-if)# ip add 172.16.20.3 255.255.255.0
 04:32:43.550: %VRRP-6-STATECHANGE: Gi0/0 Grp 20 state Init -> Backup
 04:32:43.554: %VRRP-6-STATECHANGE: Gi0/0 Grp 20 state Init -> Backup
 04:32:47.170: %VRRP-6-STATECHANGE: Gi0/0 Grp 20 state Backup -> Master

The command show vrrp [brief] provides an update on the VRRP group, along with other relevant information for troubleshooting. Example 15-16 demonstrates the brief iteration of the command. All the output is very similar to output with HSRP.

Example 15-16 Viewing the Summarized VRRP State

R2# show vrrp brief
Interface          Grp Pri Time  Own Pre State   Master addr     Group addr
Gi0/0              20  100 3609       Y  Backup  172.16.20.3     172.16.20.1
R3# show vrrp brief
Interface          Grp Pri Time  Own Pre State   Master addr     Group addr
Gi0/0              20  100 3609       Y  Master  172.16.20.3     172.16.20.1

Example 15-17 examines the detailed state of VRRP running on R2.

Example 15-17 Viewing the Detailed VRRP State

R2# show vrrp
EthernGi0/0 - Group 20
  State is Backup
  Virtual IP address is 172.16.20.1
  Virtual MAC address is 0000.5e00.0114
  Advertisement interval is 1.000 sec
  Preemption enabled
  Priority is 100
  Master Router is 172.16.20.3, priority is 100
  Master Advertisement interval is 1.000 sec
  Master Down interval is 3.609 sec (expires in 2.904 sec)
Hierarchical VRRP Configuration

The newer version of IOS XE software provides configuration of VRRP in a multi-address format that is hierarchical. The steps for configuring hierarchical VRRP are as follows:

Step 1. Enable VRRPv3 on the router by using the command fhrp version vrrp v3.

Step 2. Define the VRRP instance by using the command vrrp instance-id address-family {ipv4 | ipv6}. This places the configuration prompt into the VRRP group for additional configuration.

Step 3. (Optional) Change VRRP to Version 2 by using the command vrrpv2. VRRPv2 and VRRPv3 are not compatible.

Step 4. Define the gateway VIP by using the command address ip-address.

Step 5. (Optional) Define the VRRP priority by using the command priority priority. The priority is a value between 0 and 255.

Step 6. (Optional) Enable object tracking so that the priority is decremented when the object is false. Do so by using the command track object-id decrement decrement-value. The decrement value should be high enough so that when it is removed from the priority, the value is lower than that of the other VRRP router.

Example 15-18 shows the VRRP configuration on a pair of switches running IOS XE 16.9.2 for VLAN 22 (172.16.22.0/24). The configuration looks similar to the previous VRRP configuration except that it is hierarchical. Associating parameters like priority and tracking are nested under the VRRP instance.

Example 15-18 Configuring Hierarchical VRRP Configuration

SW2# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
SW2(config)# fhrp version vrrp v3
SW2(config)# interface vlan 22
 19:45:37.385: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan22, changed
 state to up
SW2(config-if)# ip address 172.16.22.2 255.255.255.0
SW2(config-if)# vrrp 22 address-family ipv4
SW2(config-if-vrrp)# address 172.16.22.1
SW2(config-if-vrrp)# track 1 decrement 20
SW2(config-if-vrrp)# priority 110
SW2(config-if-vrrp)# track 1 decrement 20
 19:48:00.338: %VRRP-6-STATE: Vlan22 IPv4 group 22 state INIT -> BACKUP
 19:48:03.948: %VRRP-6-STATE: Vlan22 IPv4 group 22 state BACKUP -> MASTER
SW3# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
SW3(config)# fhrp version vrrp v3
SW3(config)# interface vlan 22
 19:46:13.798: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan22, changed state to up
SW3(config-if)# ip address 172.16.22.3 255.255.255.0
SW3(config-if)# vrrp 22 address-family ipv4
SW3(config-if-vrrp)# address 172.16.22.1
 19:48:08.415: %VRRP-6-STATE: Vlan22 IPv4 group 22 state INIT -> BACKUP

The status of the VRRP routers can be viewed with the command show vrrp [brief]. The output is identical to that of the legacy VRRP configuration, as shown in Example 15-19.

Example 15-19 Viewing Hierarchical VRRP State

SW2# show vrrp brief
  Interface          Grp  A-F Pri  Time Own Pre State   Master addr/Group addr
  Vl22                22 IPv4 110     0  N   Y  MASTER  172.16.22.2(local) 172.16.22.1
SW2# show vrrp

Vlan22 - Group 22 - Address-Family IPv4
  State is MASTER
  State duration 51.640 secs
  Virtual IP address is 172.16.22.1
  Virtual MAC address is 0000.5E00.0116
  Advertisement interval is 1000 msec
  Preemption enabled
  Priority is 110
    Track object 1 state UP decrement 20
  Master Router is 172.16.22.2 (local), priority is 110
  Master Advertisement interval is 1000 msec (expires in 564 msec)
  Master Down interval is unknown
  FLAGS: 1/1

Global Load Balancing Protocol

As the name suggests, Gateway Load Balancing Protocol (GLBP) provides gateway redundancy and load-balancing capability to a network segment. It provides redundancy with an active/standby gateway, and it provides load-balancing capability by ensuring that each member of the GLBP group takes care of forwarding the traffic to the appropriate gateway.

The GLBP contains two roles:

  • Active virtual gateway (AVG): The participating routers elect one AVG per GLBP group to respond to initial ARP requests for the VIP. For example, when a local PC sends an ARP request for the VIP, the AVG is responsible for replying to the ARP request with the virtual MAC address of the AVF.

  • Active virtual forwarder (AVF): The AVF routes traffic received from assigned hosts. A unique virtual MAC address is created and assigned by the AVG to the AVFs. The AVF is assigned to a host when the AVG replies to the ARP request with the assigned AVF’s virtual MAC address. ARP replies are unicast and are not heard by other hosts on that broadcast segment. When a host sends traffic to the virtual AVF MAC, the current router is responsible for routing it to the appropriate network. The AVFs are also recognized as Fwd instances on the routers.

GLBP supports four active AVFs and one AVG per GLBP group. A router can be an AVG and an AVF at the same time. In the event of a failure of the AVG, there is not a disruption of traffic due to the AVG role transferring to a standby AVG device. In the event of a failure of an AVF, another router takes over the forwarding responsibilities for that AVF, which includes the virtual MAC address for that instance.

The following steps detail how to configure a GLBP:

Step 1. Define the GLBP instance by using the command glbp instance-id ip vip-address.

Step 2. (Optional) Configure GLBP preemption to allow for a more preferred router to take the active virtual gateway status from an inferior active GLBP router. Preemption is enabled with the command glbp instance-id preempt.

Step 3. (Optional) Define the GLBP priority by using the command glbp instance-id priority priority. The priority is a value between 0 and 255.

Step 4. (Optional) Define the GLBP timers by using the command glbp instance-id timers {hello-seconds | msec hello-milliseconds} {hold-seconds | msec hold-milliseconds}.

Step 5. (Optional) Establish GLBP authentication by using the command glbp instance-id authentication {text text-password | md5 {key-chain key-chain | key-string key-string}}.

SW2 and SW3 configure GLBP for VLAN 30 (172.16.30.0/24), with 172.16.30.1 as the VIP gateway. Example 15-20 demonstrates the configuration of both switches. Notice that the first syslog message on SW2 is for the AVG, and the second syslog message is for the first AVF (Fwd 1) for the GLBP pair. The first syslog message on SW3 is the second AVF (Fwd 2) for the GLBP pair.

Example 15-20 Basic GLBP Configuration

SW2# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
SW2(config)# interface vlan 30
SW2(config-if)# ip address 172.16.30.2 255.255.255.0
SW2(config-if)# glbp 30 ip 172.16.30.1
  05:41:15.802: %GLBP-6-STATECHANGE: Vlan30 Grp 30 state Speak -> Active
SW2(config-if)#
  05:41:25.938: %GLBP-6-FWDSTATECHANGE: Vlan30 Grp 30 Fwd 1 state Listen -> Active
SW2(config-if)# glbp 30 preempt
SW3# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
SW3(config)# interface vlan 30
SW3(config-if)# ip address 172.16.30.3 255.255.255.0
SW3(config-if)# glbp 30 ip 172.16.30.1
 05:41:32.239: %GLBP-6-FWDSTATECHANGE: Vlan30 Grp 30 Fwd 2 state Listen -> Active
SW3(config-if)# glbp 30 preempt

The command show glbp brief shows high-level details of the GLBP group, including the interface, group, active AVG, standby AVG, and statuses of the AVFs.

Example 15-21 demonstrates the commands run on SW2 and SW3. The first entry contains a - for the Fwd state, which means that it is the entry for the AVG. The following two entries are for the AVF instances; they identify which device is active for each AVF.

Example 15-21 Viewing the Brief GLBP Status

SW2# show glbp brief
Interface   Grp  Fwd Pri State    Address         Active router   Standby router
Vl30        30   -   100 Active   172.16.30.1     local           172.16.30.3
Vl30        30   1   -   Active   0007.b400.1e01  local           -
Vl30        30   2   -   Listen   0007.b400.1e02  172.16.30.3     -
SW3# show glbp brief
Interface   Grp  Fwd Pri State    Address         Active router   Standby router
Vl30        30   -   100 Standby  172.16.30.1     172.16.30.2     local
Vl30        30   1   -   Listen   0007.b400.1e01  172.16.30.2     -
Vl30        30   2   -   Active   0007.b400.1e02  local           -

The command show glbp displays additional information, including the timers, preemption settings, and statuses for the AVG and AVFs for the GLBP group. Example 15-22 shows the command show glbp run on SW2. Notice that the MAC addresses and interface IP addresses are listed under the group members, which can be used to correlate MAC address identities in other portions of the output.

Example 15-22 Viewing the Detailed GLBP Status

SW2# show glbp
Vlan30 - Group 30
  State is Active                                                                    
    1 state change, last state change 00:01:26
  Virtual IP address is 172.16.30.1
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 1.664 secs
  Redirect time 600 sec, forwarder time-out 14400 sec
  Preemption enabled, min delay 0 sec
  Active is local
  Standby is 172.16.30.3, priority 100 (expires in 7.648 sec)
  Priority 100 (default)
  Weighting 100 (default 100), thresholds: lower 1, upper 100
  Load balancing: round-robin                                                        
  Group members:
    70b3.17a7.7b65 (172.16.30.3)                                                     
    70b3.17e3.cb65 (172.16.30.2) local
  There are 2 forwarders (1 active)
  Forwarder 1                                                                        
    State is Active
      1 state change, last state change 00:01:16
    MAC address is 0007.b400.1e01 (default)
    Owner ID is 70b3.17e3.cb65
    Redirection enabled
    Preemption enabled, min delay 30 sec
    Active is local, weighting 100
  Forwarder 2                                                                        
    State is Listen
    MAC address is 0007.b400.1e02 (learnt)
    Owner ID is 70b3.17a7.7b65
    Redirection enabled, 597.664 sec remaining (maximum 600 sec)
    Time to live: 14397.664 sec (maximum 14400 sec)
    Preemption enabled, min delay 30 sec
    Active is 172.16.30.3 (primary), weighting 100 (expires in 8.160 sec)

By default, GLBP balances the load of traffic in a round-robin fashion, as highlighted in Example 15-22. However, GLBP supports three methods of load balancing traffic:

  • Round robin: Uses each virtual forwarder MAC address to sequentially reply for the virtual IP address.

  • Weighted: Defines weights to each device in the GLBP group to define the ratio of load balancing between the devices. This allows for a larger weight to be assigned to bigger routers that can handle more traffic.

  • Host dependent: Uses the host MAC address to decide to which virtual forwarder MAC to redirect the packet. This method ensures that the host uses the same virtual MAC address as long as the number of virtual forwarders does not change within the group.

The load-balancing method can be changed with the command glbp instance-id load-balancing {host-dependent | round-robin | weighted}. The weighted load-balancing method has the AVG direct traffic to the AVFs based on the percentage of weight a router has over the total weight of all GLBP routers. Increasing the weight on more capable, bigger routers allows them to take more traffic than smaller devices. The weight can be set for a router with the command glbp instance-id weighting weight.

Example 15-23 shows how to change the load balancing to weighted and setting the weight to 20 on SW2 and 80 on SW3 so that SW2 receives 20% of the traffic and SW3 receives 80% of the traffic.

Example 15-23 Changing the GLBP Load Balancing to Weighted

SW2(config)# interface vlan 30
SW2(config-if)# glbp 30 load-balancing weighted
SW2(config-if)# glbp 30 weighting 20
SW3(config)# interface vlan 30
SW3(config-if)# glbp 30 load-balancing weighted
SW3(config-if)# glbp 30 weighting 80

Example 15-24 shows that the load-balancing method has been changed to weighted and that the appropriate weight has been set for each AVF.

Example 15-24 Verifying GLBP Weighted Load Balancing

SW2# show glbp
Vlan30 - Group 30
  State is Active
    1 state change, last state change 00:04:55
  Virtual IP address is 172.16.30.1
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 0.160 secs
  Redirect time 600 sec, forwarder time-out 14400 sec
  Preemption enabled, min delay 0 sec
  Active is local
  Standby is 172.16.30.3, priority 100 (expires in 9.216 sec)
  Priority 100 (default)
  Weighting 20 (configured 20), thresholds: lower 1, upper 20
  Load balancing: weighted                                                           
  Group members:
    70b3.17a7.7b65 (172.16.30.3)
    70b3.17e3.cb65 (172.16.30.2) local
 There are 2 forwarders (1 active)
  Forwarder 1
    State is Active
      1 state change, last state change 00:04:44
    MAC address is 0007.b400.1e01 (default)
    Owner ID is 70b3.17e3.cb65
    Redirection enabled
    Preemption enabled, min delay 30 sec
    Active is local, weighting 20
  Forwarder 2
    State is Listen
    MAC address is 0007.b400.1e02 (learnt)
    Owner ID is 70b3.17a7.7b65
    Redirection enabled, 599.232 sec remaining (maximum 600 sec)
    Time to live: 14399.232 sec (maximum 14400 sec)
    Preemption enabled, min delay 30 sec
    Active is 172.16.30.3 (primary), weighting 80 (expires in 9.408 sec)

Network Address Translation

In the early stages of the Internet, large network blocks were assigned to organizations (for example, universities, companies). Network engineers started to realize that as more people connected to the Internet, the IP address space would become exhausted. RFC 1918 established common network blocks that should never be seen on the Internet (that is, they are non-globally routed networks):

  • 10.0.0.0/8 accommodates 16,777,216 hosts.

  • 172.16.0.0/24 accommodates 1,048,576 hosts.

  • 192.168.0.0/16 accommodates 65,536 hosts.

These address blocks provide large private network blocks for companies to connect their devices together, but how can devices with private network addressing reach servers that are on the public Internet? If a packet is sourced from a 192.168.1.1 IP address and reaches the server with a 100.64.1.1 IP address, the server will not have a route back to the 192.168.1.1 network—because it does not exist on the Internet.

Connectivity is established with Network Address Translation (NAT). Basically, NAT enables the internal IP network to appear as a publicly routed external network. A NAT device (typically a router or firewall) modifies the source or destination IP addresses in a packet’s header as the packet is received on the outside or inside interface.

NAT can be used in use cases other than just providing Internet connectivity to private networks. It can also be used to provide connectivity when a company buys another company, and the two companies have overlapping networks (that is, the same network ranges are in use).

Note

Most routers and switches perform NAT translation only with the IP header addressing and do not translate IP addresses within the payload (for example, DNS requests). Some firewalls have the ability to perform NAT within the payload for certain types of traffic.

Four important terms are related to NAT:

  • Inside local: The actual private IP address assigned to a device on the inside network(s).

  • Inside global: The public IP address that represents one or more inside local IP addresses to the outside.

  • Outside local: The IP address of an outside host as it appears to the inside network. The IP address does not have to be reachable by the outside but is considered private and must be reachable by the inside network.

  • Outside global: The public IP address assigned to a host on the outside network. This IP address must be reachable by the outside network.

Three types of NAT are commonly used today:

  • Static NAT: Provides a static one-to-one mapping of a local IP address to a global IP address.

  • Pooled NAT: Provides a dynamic one-to-one mapping of a local IP address to a global IP address. The global IP address is temporarily assigned to a local IP address. After a certain amount of idle NAT time, the global IP address is returned to the pool.

  • Port Address Translation (PAT): Provides a dynamic many-to-one mapping of many local IP addresses to one global IP address. The NAT device needs a mechanism to identify the specific private IP address for the return network traffic. The NAT device translates the private IP address and port to a different global IP address and port. The port is unique from any other ports, which enables the NAT device to track the global IP address to local IP addresses based on the unique port mapping.

The following sections explain these types of NAT.

NAT Topology

Figure 15-7 is used throughout this section to illustrate NAT. R5 performs the translation; its Gi0/0 interface (10.45.1.5) is the outside interface, and its Gi0/1 (10.56.1.5) interface is the inside interface. R1, R2, R3, R7, R8, and R9 all act as either clients or servers to demonstrate how NAT functions.

A NAT topology is shown.

Figure 15-7 NAT Topology

R1, R2, and R3 all have a static default route toward R4, and R4 has a static default route toward R5. R7, R8, and R9 all have a static default route toward R6, and R6 has a static default route to R5. R5 contains a static route to the 10.123.4.0/24 network through R4, and a second static route to the 10.78.9.0/24 network through R6. Example 15-25 shows the routing tables of R1, R5, and R7.

Example 15-25 Routing Tables of R1, R5, and R7

R1# show ip route | begin Gateway
Gateway of last resort is 10.123.4.4 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 10.123.4.4
      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.123.4.0/24 is directly connected, GigabitEthernGi0/0
R5# show ip route | begin Gateway
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C        10.45.1.0/24 is directly connected, GigabitEthernGi0/0
C        10.56.1.0/24 is directly connected, GigabitEthernGi0/1
S        10.78.9.0/24 [1/0] via 10.56.1.6
S        10.123.4.0/24 [1/0] via 10.45.1.4
R7# show ip route  | begin Gateway
Gateway of last resort is 10.78.9.6 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 10.78.9.6
      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.78.9.0/24 is directly connected, GigabitEthernGi0/0

The topology provides full connectivity between the outside hosts (R1, R2, and R3) and the inside hosts (R7, R8, and R9). Example 15-26 shows a traceroute from R1 to R7.

Example 15-26 Traceroute from R1 to R7

R1# traceroute 10.78.9.7
Type escape sequence to abort.
Tracing the route to 10.78.9.7
VRF info: (vrf in name/id, vrf out name/id)
  1 10.123.4.4 1 msec 0 msec 0 msec
  2 10.45.1.5 1 msec 0 msec 0 msec
  3 10.56.1.6 1 msec 0 msec 0 msec
  4 10.78.9.7 1 msec *  1 msec

Using an IOS XE router for hosts (R1, R2, R3, R7, R8, and R9) enables you to log in using Telnet and identify the source and destination IP addresses by examining the TCP session details. In Example 15-27, R7 (10.78.9.7) initiates a Telnet connection to R1 (10.123.4.1). When you are logged in, the command show tcp brief displays the source IP address and port, along with the destination IP address and port.

The local IP address reflects R1 (10.123.4.1), and the remote address is R7 (10.78.9.7). These IP addresses match expectations, and therefore no NAT has occurred on R5 for this Telnet session.

Example 15-27 Viewing the Source IP Address

R7# telnet 10.123.4.1
Trying 10.123.4.1 ... Open
*************************************************************
* You have remotely connected to R1 on line 2
*************************************************************
User Access Verification
Password:

R1# show tcp brief
TCB       Local Address               Foreign Address             (state)
F69CE570  10.123.4.1.23              10.78.9.7.49024             ESTAB

Static NAT

Static NAT involves the translation of a global IP address to a local IP address, based on a static mapping of the global IP address to the local IP address. There are two types of static NAT, as described in the following sections:

  • Inside static NAT

  • Outside static NAT

Inside Static NAT

Inside static NAT involves the mapping of an inside local (private) IP address to an inside global (public) IP address. In this scenario, the private IP addresses are being hidden from the outside hosts.

The steps for configuring inside static NAT are as follows:

Step 1. Configure the outside interfaces by using the command ip nat outside.

Step 2. Configure the inside interface with the command ip nat inside.

Step 3. Configure the inside static NAT by using the command ip nat inside source static inside-local-ip inside-global-ip.

Example 15-28 shows the inside static NAT configuration on R5, where packets sourced from R7 (10.78.9.7) appear as if they came from 10.45.1.7.

Example 15-28 Configuring Inside Static NAT

R5# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)# interface GigabitEthernGi0/0
R5(config-if)# ip nat outside
R5(config-if)# interface GigabitEthernGi0/1
R5(config-if)# ip nat inside
R5(config-if)# exit
R5(config)# ip nat inside source static 10.78.9.7 10.45.1.7

Note

Most network engineers assume that the inside-global-ip must reside on the outside network. In this scenario, that would be an IP address on the 10.45.1.0/24 network. First, the inside-global-ip address should not be associated with the outside interface. Second, the inside-global-ip address could be an address for a network that does not exist on the NAT router (for example, 10.77.77.77). However, all outside routers must have a route for forwarding packets toward the router performing the NAT for that IP address (that is, 10.77.77.77).

Now that the NAT has been configured on R5, R7 initiates a Telnet session with R1, as demonstrated in Example 15-29. Upon viewing the TCP session on R1, the local address remains 10.123.4.1 as expected, but the remote address now reflects 10.45.1.7. This is a different source IP address than the baseline example in Example 15-27, where the remote address is 10.78.9.7.

Example 15-29 Identification of the Source with Inside Static NAT

R7# telnet 10.123.4.1
Trying 10.123.4.1 ... Open
*************************************************************
* You have remotely connected to R1 on line 3
*************************************************************
User Access Verification
Password:

R1# show tcp brief
TCB       Local Address               Foreign Address             (state)
F6D25D08  10.123.4.1.23              10.45.1.7.56708             ESTAB

The NAT translation table consists of static and dynamic entries. The NAT translation table is displayed with the command show ip nat translations. Example 15-30 shows R5’s NAT translation table after R7 initiated a Telnet session to R1. There are two entries:

  • The first entry is the dynamic entry correlating to the Telnet session. The inside global, inside local, outside local, and outside global fields all contain values. Notice that the ports in this entry correlate with the ports in Example 15-29.

  • The second entry is the inside static NAT entry that was configured.

Example 15-30 NAT Translation Table for Inside Static NAT

R5# show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
tcp 10.45.1.7:56708    10.78.9.7:56708    10.123.4.1:23      10.123.4.1:23
--- 10.45.1.7          10.78.9.7          ---                ---

Figure 15-8 displays the current topology with R5’s translation table. The NAT translation follows these steps:

  1. As traffic enters on R5’s Gi0/1 interface, R5 performs a route lookup for the destination IP address, which points out of its Gi0/0 interface. R1 is aware that the Gi0/0 interface is an outside NAT interface and that the Gi0/1 interface is an inside NAT interface and therefore checks the NAT table for an entry.

  2. Only the inside static NAT entry exists, so R5 creates a dynamic inside NAT entry with the packet’s destination (10.123.4.1) for the outside local and outside global address.

  3. R5 translates (that is, changes) the packet’s source IP address from 10.78.9.7 to 10.45.1.7.

  4. R1 registers the session as coming from 10.45.1.7 and then transmits a return packet. The packet is forwarded to R4 using the static default route, and R4 forwards the packet using the static default route.

  5. As the packet enters on R5’s Gi0/0 interface, R5 is aware that the Gi0/0 interface is an outside NAT interface and checks the NAT table for an entry.

  6. R5 correlates the packet’s source and destination ports with the first NAT entry, as shown in Example 15-30, and knows to modify the packet’s destination IP address from 10.45.1.7 to 10.78.9.7.

  7. R5 routes the packet out the Gi0/1 interface toward R6.

Remember that a static NAT entry is a one-to-one mapping between the inside global and the inside local address. As long as the outside devices can route traffic to the inside global IP address, they can use it to reach the inside local device as well.

In Example 15-31, R2, with no sessions to any device in the topology, establishes a Telnet session with R7, using the inside global IP address 10.45.1.7. R5 simply creates a second dynamic entry for this new session. From R7’s perspective, it has connected with R2 (10.123.4.2).

A figure represents inside static NAT topology for R7 as 10.45.1.7.

Figure 15-8 Inside Static NAT Topology for R7 as 10.45.1.7

Example 15-31 Connectivity from External Devices to the Inside Global IP Address

R2# telnet 10.45.1.7
Trying 10.45.1.7 ... Open
*************************************************************
* You have remotely connected to R7 on line 2
*************************************************************
User Access Verification
Password:

R7# show tcp brief
TCB       Local Address               Foreign Address             (state)
F6561AE0  10.78.9.7.23               10.123.4.2.63149            ESTAB
F65613E0  10.78.9.7.33579            10.123.4.1.23               ESTAB
R5# show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
tcp 10.45.1.7:56708    10.78.9.7:56708    10.123.4.1:23      10.123.4.1:23
tcp 10.45.1.7:23       10.78.9.7:23       10.123.4.2:63149   10.123.4.2:63149
--- 10.45.1.7          10.78.9.7          ---                ---
Outside Static NAT

Outside static NAT involves the mapping of an outside global (public) IP address to an outside local (private) IP address. In this scenario, the real external IP addresses are being hidden from the inside hosts.

The steps for configuring outside static NAT are as follows:

Step 1. Configure the outside interfaces by using the command ip nat outside.

Step 2. Configure the inside interface by using the command ip nat inside.

Step 3. Configure the outside static NAT entry by using the command ip nat outside source static outside-global-ip outside-local-ip [add-route]. The router performs a route lookup first for the outside-local-ip address, and a route must exist for that network to forward packets out of the outside interface before NAT occurs. The optional add-route keyword adds the appropriate static route entry automatically.

Example 15-32 shows the outside static NAT configuration on R5, where packets sent from R6, R7, R8, or R9 to 10.123.4.222 will be sent to R2 (10.123.4.2). R5 already has a static route to the 10.123.4.0/24 network, so the add-route keyword is not necessary.

Example 15-32 Configuring Outside Static NAT

R5# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)# interface GigabitEthernGi0/0
R5(config-if)# ip nat outside
R5(config-if)# interface GigabitEthernGi0/1
R5(config-if)# ip nat inside
R5(config-if)# exit
R5(config)# ip nat outside source static 10.123.4.2 10.123.4.222

R6, R7, R8, or R9 could initiate a Telnet session directly with R2’s IP address (10.123.4.2), and no NAT translation would occur. The same routers could initiate a Telnet session with the R2’s outside local IP address 10.123.4.222; or R2 could initiate a session with any of the inside hosts (R6, R7, R8, or R9) to demonstrate the outside static NAT entry.

Example 15-33 shows R2 establishing a Telnet session with R9 (10.78.9.9). From R9’s perspective, the connection came from 10.123.4.222. At the same time, R8 initiated a Telnet session with the outside static NAT outside local IP address (10.123.4.222), but from R2’s perspective, the source address is R8’s 10.78.9.8 IP address.

Example 15-33 Generating Network Traffic with Outside Static NAT

R2# telnet 10.78.9.9
Trying 10.78.9.9 ... Open
*************************************************************
* You have remotely connected to R9 on line 2
*************************************************************
User Access Verification
Password:

R9#show tcp brief
TCB       Local Address               Foreign Address             (state)
F6A23AF0  10.78.9.9.23               10.123.4.222.57126          ESTAB
R8# telnet 10.123.4.222
Trying 10.123.4.222 ... Open
*************************************************************
* You have remotely connected to R2 on line 2
*************************************************************
User Access Verification
Password:

R2# show tcp brief
TCB       Local Address               Foreign Address             (state)
F64C9460  10.123.4.2.57126           10.78.9.9.23                ESTAB
F64C9B60  10.123.4.2.23              10.78.9.8.11339             ESTAB

Figure 15-9 shows R5’s translation table for R2’s outside static NAT entry for 10.123.4.222. Notice that there is a static mapping, and there are two dynamic entries for the two sessions on R2.

A figure represents outside static NAT topology for R2 as 10.123.4.222.

Figure 15-9 Outside Static NAT Topology for R2 as 10.123.4.222

Example 15-34 shows R5’s NAT translation table. There are three entries:

  • The first entry is the outside static NAT entry that was configured.

  • The second entry is the Telnet session launched from R8 to the 10.123.4.222 IP address.

  • The third entry is the Telnet session launched from R2 to R9’s IP address (10.78.9.9).

Example 15-34 NAT Translation Table for Outside Static NAT

R5# show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
--- ---                ---                10.123.4.222       10.123.4.2
tcp 10.78.9.8:11339    10.78.9.8:11339    10.123.4.222:23    10.123.4.2:23
tcp 10.78.9.9:23       10.78.9.9:23       10.123.4.222:57126 10.123.4.2:57126

Note

Outside static NAT configuration is not very common and is typically used to overcome the problems caused by duplicate IP/network addresses in a network.

Pooled NAT

Static NAT provides a simple method of translating addresses. A major downfall to the use of static NAT is the number of configuration entries that must be created on the NAT device; in addition, the number of global IP addresses must match the number of local IP addresses.

Pooled NAT provides a more dynamic method of providing a one-to-one IP address mapping—but on a dynamic, as-needed basis. The dynamic NAT translation stays in the translation table until traffic flow from the local address to the global address has stopped and the timeout period (24 hours by default) has expired. The unused global IP address is then returned to the pool to be used again.

Pooled NAT can operate as inside NAT or outside NAT. In this section, we focus on inside pooled NAT. The steps for configuring inside pooled NAT are as follows:

Step 1. Configure the outside interfaces by using the command ip nat outside.

Step 2. Configure the inside interface by using the command ip nat inside.

Step 3. Specify which by using a standard or extended ACL referenced by number or name. Using a user-friendly name may be simplest from an operational support perspective.

Step 4. Define the global pool of IP addresses by using the command ip nat pool nat-pool-name starting-ip ending-ip prefix-length prefix-length.

Step 5. Configure the inside pooled NAT by using the command ip nat inside source list acl pool nat-pool-name.

Example 15-35 shows a sample configuration for inside pooled NAT. This example uses a NAT pool with the IP addresses 10.45.1.10 and 10.45.1.11. A named ACL, ACL-NAT-CAPABLE, allows only packets sourced from the 10.78.9.0/24 network to be eligible for pooled NAT.

Example 15-35 Configuring Inside Pooled NAT

R5# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)# ip access-list standard ACL-NAT-CAPABLE
R5(config-std-nacl)# permit 10.78.9.0 0.0.0.255
R5(config-std-nacl)# exit
R5(config)# interface GigabitEthernGi0/0
R5(config-if)# ip nat outside
R5(config-if)# interface GigabitEthernGi0/1
R5(config-if)# ip nat inside
R5(config-if)# exit
R5(config)# ip nat pool R5-OUTSIDE-POOL 10.45.1.10 10.45.1.11 prefix-length 24
R5(config)# ip nat inside source list ACL-NAT-CAPABLE pool R5-OUTSIDE-POOL

To quickly generate some traffic and build the dynamic inside NAT translations, R7 (10.78.9.7) and R8 (10.78.9.8), ping R1 (10.123.4.1), as demonstrated in Example 15-36. This could easily be another type of traffic (such as Telnet).

Example 15-36 Initial Traffic for Pooled NAT

R7# ping 10.123.4.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.123.4.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R8# ping 10.123.4.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.123.4.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

In this case, the pings should have created a dynamic inside NAT translation and removed the 10.45.1.10 and 10.45.1.11 binding. Example 15-37 confirms this assumption. There are a total of four translations in R5’s translation table. Two of them are for the full flow and specify the protocol, inside global, inside local, outside local, and outside global IP addresses.

Example 15-37 Viewing the Pooled NAT Table for R5

R5# show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 10.45.1.10:0      10.78.9.7:0        10.123.4.1:0       10.123.4.1:0
--- 10.45.1.10         10.78.9.7          ---                ---
icmp 10.45.1.11:0      10.78.9.8:0        10.123.4.1:0       10.123.4.1:0
--- 10.45.1.11         10.78.9.8          ---                ---

The other two translations are dynamic one-to-one mappings that could be used as R7 or R8 create additional dynamic flows and maintain the existing global IP address. Based on the mapping before the flow, the additional flows from R8 (10.78.9.8) should be mapped to the global IP address 10.45.1.11.

In Example 15-38, R8 establishes a Telnet session with R2. R2 detects that the remote IP address of the session is 10.45.1.11. A second method of confirmation is to examine the NAT translation on R5, where there is a second dynamic translation entry for the full Telnet session.

Example 15-38 Using the Dynamic One-to-One Mappings for Address Consistency

R8# telnet 10.123.4.2
Trying 10.123.4.2 ... Open
*************************************************************
* You have remotely connected to R2 on line 2
*************************************************************
User Access Verification
Password:

R2# show tcp brief
TCB       Local Address               Foreign Address             (state)
F3B64440  10.123.4.2.23              10.45.1.11.34115            ESTAB
R5# show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 10.45.1.10:1      10.78.9.7:1        10.123.4.1:1       10.123.4.1:1
--- 10.45.1.10         10.78.9.7          ---                ---
icmp 10.45.1.11:1      10.78.9.8:1        10.123.4.1:1       10.123.4.1:1
tcp 10.45.1.11:34115   10.78.9.8:34115    10.123.4.2:23      10.123.4.2:23           
--- 10.45.1.11         10.78.9.8          ---                ---

A downfall to using pooled NAT is that when the pool is exhausted, no additional translation can occur until the global IP address is returned to the pool. To demonstrate this concept, R5 has enabled debugging for NAT, and R9 tries to establish a Telnet session with R1. Example 15-39 demonstrates the concept, with the NAT translation failing on R5 and the packet being dropped.

Example 15-39 Failed NAT Pool Allocation

R9# telnet 10.123.4.1
Trying 10.123.4.1 ...
% Destination unreachable; gateway or host down
R5# debug ip nat detailed
IP NAT detailed debugging is on
R5#
 02:22:58.685: NAT: failed to allocate address for 10.78.9.9, list/map ACL-NAT-CAPABLE
 02:22:58.685:  mapping pointer available mapping:0
 02:22:58.685: NAT*: Can't create new inside entry - forced_punt_flags: 0
 02:22:58.685: NAT: failed to allocate address for 10.78.9.9, list/map ACL-NAT-CAPABLE
 02:22:58.685:  mapping pointer available mapping: 0
 02:22:58.685: NAT: translation failed (A), dropping packet s=10.78.9.9 d=10.123.4.1

The default timeout for NAT translations is 24 hours, but this can be changed with the command ip nat translation timeout seconds. The dynamic NAT translations can be cleared out with the command clear ip nat translation {ip-address | *}, which removes all existing translations and could interrupt traffic flow on active sessions as they might be assigned new global IP addresses.

Example 15-40 demonstrates the reset of the NAT translations on R5 for all IP addresses and then on R9, which is successfully able to gain access to R1 through the newly allocated (reset) global IP address.

Example 15-40 Clearing NAT Translation to Reset the NAT Pool

R5# clear ip nat translation *
R9# telnet 10.123.4.1
Trying 10.123.4.1 ... Open
*************************************************************
* You have remotely connected to R1 on line 2
*************************************************************
User Access Verification
Password:

R1#

Port Address Translation

Pooled NAT translation simplifies the management of maintaining the one-to-one mapping for NAT (compared to static NAT). But pooled NAT translation still faces the limitation of ensuring that the number of global IP addresses is adequate to meet the needs of the local IP addresses.

Port Address Translation (PAT) is an iteration of NAT that allows for a mapping of many local IP addresses to one global IP address. The NAT device maintains the state of translations by dynamically changing the source ports as a packet leaves the outside interface. Another term for PAT is NAT overload.

Configuring PAT involves the following steps:

Step 1. Configure the outside interface by using the command ip nat outside.

Step 2. Configure the inside interface by using the command ip nat inside.

Step 3. Specify which traffic can be translated by using a standard or extended ACL referenced by number or name. Using a user-friendly name may be simplest from an operational support perspective.

Step 4. Configure Port Address Translation by using the command the command ip nat inside source list acl {interface interface-id | pool nat-pool-name} overload. Specifying an interface involves using the primary IP address assigned to that interface. Specifying a NAT pool requires the creation of the NAT pool, asdemonstrated earlier, and involves using those IP addresses as the global address.

Example 15-41 demonstrates R5’s PAT configuration, which allows network traffic sourced from the 10.78.9.0/24 network to be translated to R5’s Gi0/0 interface (10.45.1.5) IP address.

Example 15-41 Configuring PAT on R5

R5# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)# ip access-list standard ACL-NAT-CAPABLE
R5(config-std-nacl)# permit 10.78.9.0 0.0.0.255
R5(config-std-nacl)# exit
R5(config)# interface GigabitEthernGi0/0
R5(config-if)# ip nat outside
R5(config-if)# interface GigabitEthernGi0/1
R5(config-if)# ip nat inside
R5(config)# ip nat source list ACL-NAT-CAPABLE interface GigabitEthernGi0/0 overloa

Now that PAT has been configured on R5, traffic can be generated for testing. R7, R8, and R9 ping R1 (10.123.4.1), and R7 and R8 establish a Telnet session. Based on the TCP sessions in Example 15-42, you can see that both Telnet sessions are coming from R5’s Gi0/0 (10.45.1.5) IP address. R7 has a remote port of 51,576, while R8 has a remote port of 31,515.

Example 15-42 Generating Network Traffic for PAT

R7# ping 10.123.4.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.123.4.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R8# ping 10.123.4.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.123.4.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R9# ping 10.123.4.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.123.4.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R7# telnet 10.123.4.2
Trying 10.123.4.2 ... Open
*************************************************************
* You have remotely connected to R2 on line 2
*************************************************************
User Access Verification
Password:
R2# show tcp brief
TCB       Local Address               Foreign Address             (state)
F3B64440  10.123.4.2.23              10.45.1.5.51576             ESTAB
R8# telnet 10.123.4.2
Trying 10.123.4.2 ... Open
*************************************************************
* You have remotely connected to R2 on line 3
*************************************************************
User Access Verification
Password:

R2# show tcp brief
TCB       Local Address               Foreign Address             (state)
F3B64440  10.123.4.2.23              10.45.1.5.51576             ESTAB
F3B65560  10.123.4.2.23              10.45.1.5.31515             ESTAB

Figure 15-10 shows R5’s translation table after all the various flows have established. Notice that the inside global IP address is R5’s Gi0/0 (10.45.1.5) IP address, while the inside local IP addresses are different. In addition, notice that the ports for the inside global entries are all unique—especially for the first two entries, which have an outside local entry for 10.123.4.1:3. PAT must make the inside global ports unique to maintain the one-to-many mapping for any return traffic.

A figure shows R5's translation table for PAT.

Figure 15-10 R5’s Translation Table for PAT

Example 15-43 shows R5’s NAT translation table. By taking the ports from the TCP brief sessions on R2 and correlating them to R5’s NAT translation table, you can identify which TCP session belongs to R7 or R8.

Example 15-43 R5’s NAT Translation Table with PAT

R5# show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 10.45.1.5:4       10.78.9.7:3        10.123.4.1:3       10.123.4.1:4
icmp 10.45.1.5:3       10.78.9.8:3        10.123.4.1:3       10.123.4.1:3
icmp 10.45.1.5:1       10.78.9.9:1        10.123.4.1:1       10.123.4.1:1
tcp 10.45.1.5:51576    10.78.9.7:51576    10.123.4.2:23      10.123.4.2:23
tcp 10.45.1.5:31515    10.78.9.8:31515    10.123.4.2:23      10.123.4.2:2

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a couple of choices for exam preparation: the exercises here, Chapter 30, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep Software Online.

Review All Key Topics

Review the most important topics in the chapter, noted with the key topics icon in the outer margin of the page. Table 15-3 lists these key topics and the page number on which each is found.

Table 15-3 Key Topics for Chapter 15

Key Topic Element

Description

Page

Section

Network Time Protocol

396

Paragraph

NTP stratums

396

Section

Stratum preferences

399

Section

NTP peers

400

Paragraph

First-hop redundancy protocol (FHRP)

402

Section

Hot Standby Router Protocol (HSRP)

404

List

HSRP configuration

405

Paragraph

HSRP object tracking

408

Section

Virtual Router Redundancy Protocol

409

List

Legacy VRRP configuration

410

List

Hierarchical VRRP configuration

411

Section

Global Load Balancing Protocol

413

List

GLBP configuration

413

List

GLBP load-balancing options

415

Paragraph

Network Address Translation (NAT)

417

List

NAT terms

418

List

Common NAT types

418

List

Inside static NAT configuration

421

Paragraph

Viewing the NAT translation table

422

List

NAT processing

422

List

Outside static NAT configuration

424

List

Pooled NAT configuration

426

Paragraph

NAT timeout

429

Paragraph

Port Address Translation (PAT)

429

List

PAT configuration

429

Complete Tables and Lists from Memory

There are no memory tables in this chapter.

Define Key Terms

Define the following key terms from this chapter, and check your answers in the glossary:

first-hop redundancy protocol

inside global

inside local

Network Address Translation (NAT)

NTP client

NTP peer

NTP server

outside local

outside global

pooled NAT

Port Address Translation (PAT)

static NAT

stratum

Use the Command Reference to Check Your Memory

Table 15-4 lists the important commands from this chapter. To test your memory, cover the right side of the table with a piece of paper, read the description on the left side, and see how much of the command you can remember.

Table 15-4 Command Reference

Task

Command Syntax

Configure a device as an NTP client with the IP address of the NTP server

ntp server ip-address [prefer] [source interface-id]

Configure a device so that it can respond authoritatively to NTP requests when it does not have access to an atomic clock or an upstream NTP server

ntp master stratum-number

Configure the peering with another device with NTP

ntp peer ip-address

Configure the tracking of an interface’s line protocol state

track object-number interface interface-id line-protocol

Configure a device to track the installation of a route in the routing table

track object-number ip route route/prefix-length reachability

Configure the VIP for the HSRP instance

standby instance-id ip vip-address

Enable preemption for the HSRP instance

standby instance-id preempt

Specify the MAC address for the HSRP VIP

standby instance-id mac-address mac-address

Configure the HSRP timers for neighbor health checks

standby instance-id timers {seconds | msec milliseconds}

Link object tracking to a decrease in priority upon failure of the HSRP

standby instance-id track object-id decrement decrement-value

Configure the VIP gateway for the VRRP instance

vrrp instance-id ip vip-address

Configure the priority for the VRRP instance

vrrp instance-id priority priority

Link object tracking to a decrease in priority upon failure with VRRP

vrrp instance-id track object-id decrement decrement-value

Configure the VIP gateway for a GLBP instance

glbp instance-id ip vip-address

Enable preemption for a GLBP instance

glbp instance-id preempt

Configure the priority for a GLBP instance

glbp instance-id priority priority

Configure GLBP timers for neighbor health checks

glbp instance-id timers {hello-seconds | msec hello-milliseconds} {hold-seconds | msec hold-milliseconds}

Configure the GLBP load-balancing algorithm

glbp instance-id load-balancing {host-dependent | round-robin | weighted}.

Configure the devices GLBP weight for traffic load balancing

glbp instance-id weighting weight

Configure an interface as an outside interface for NAT

ip nat outside

Configure an interface as an inside interface for NAT

ip nat inside

Configure static inside NAT

ip nat inside source static inside-local-ip inside-global-ip

Configure static outside NAT

ip nat outside source static outside-global-ip outside-local-ip [add-route]

Configure pooled NAT

ip nat pool nat-pool-name starting-ip ending-ip prefix-length prefix-length

Define the NAT pool for global IP addresses

ip nat inside source list acl pool nat-pool-name

Configure a device for PAT

ip nat inside source list acl {interface interface-id | pool nat-pool-name} overload

Modify the NAT timeout period

ip nat translation timeout seconds

Clear a dynamic NAT entry

clear ip nat translation {ip-address | *}

Display the status of the NTP service, hardware clock synchronization status, reference time, and time since last polling cycle

show ntp status

Display the list of configured NTP servers and peers and their time offset from the local device

show ntp associations

Display the status of a tracked object

show track [object-number]

Display the status of an HSRP VIP

show standby [interface-id] [brief]

Display the status of a VRRP VIP

show vrrp [brief]

Display the status of a GLBP VIP

show glbp [brief]

Display the translation table on a NAT device

show ip nat translations

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
44.203.58.132