Describe DNS lookup operation

If you want to use a hostname instead of an IP address to connect to a remote device, the device that you're using to make the connection must be able to translate the hostname to an IP address.

There are two ways to resolve hostnames to IP addresses. The first is by building a host table on each router, and the second is to build a Domain Name System (DNS) server. The latter method is similar to creating a dynamic host table, assuming that you're dealing with dynamic DNS.

Building a Host Table

An important factor to remember is that although a host table provides name resolution, it does that only on the specific router that it was built upon. The command you use to build a host table on a router looks like this:

ip host host_name [tcp_port_number] ip_address

The default is TCP port number 23, but you can create a session using Telnet with a different TCP port number if you want. You can also assign up to eight IP addresses to a hostname.

Here's how I configured a host table on the SW-1 switch with two entries to resolve the names for the SW-2 and SW-3:

SW-1#config t

SW-1(config)#ip host SW-2 ?

  <0-65535>   Default telnet port number

  A.B.C.D     Host IP address

  additional  Append addresses

 

SW-1(config)#ip host SW-2 10.100.128.9

SW-1(config)#ip host SW-3 10.100.128.8

Notice that I can just keep adding IP addresses to reference a unique host, one after another. To view our newly built host table, I'll just use the show hosts command:

SW-1(config)#do sho hosts

Default domain is not set

Name/address lookup uses domain service

Name servers are 255.255.255.255

Codes: u - unknown, e - expired, * - OK, ? - revalidate

       t - temporary, p - permanent

Host                   Port  Flags      Age Type   Address(es)

SW-3                   None  (perm, OK)  0   IP    10.100.128.8

SW-2                   None  (perm, OK)  0   IP    10.100.128.9

In this output, you can see the two hostnames plus their associated IP addresses. The perm in the Flags column means that the entry has been manually configured. If it read temp, it would be an entry that was resolved by DNS.

To verify that the host table resolves names, try typing the hostnames at a router prompt. Remember that if you don't specify the command, the router will assume you want to telnet.

In the following example, I'll use the hostnames to telnet into the remote devices and press Ctrl+Shift+6 and then X to return to the main console of the SW-1 router:

SW-1#sw-3

Trying SW-3 (10.100.128.8)... Open

 

User Access Verification

 

Password:

SW-3> Ctrl+Shift+6

SW-1#

It worked—I successfully used entries in the host table to create a session to the SW-3 device by using the name to telnet into it. And just so you know, names in the host table are not case sensitive.

Notice that the entries in the following show sessions output now display the hostnames and IP addresses instead of just the IP addresses:

SW-1#sh sessions

Conn Host                Address             Byte  Idle Conn Name

   1 SW-3                10.100.128.8        0     1    SW-3

*  2 SW-2                10.100.128.9        0     1    SW-2

SW-1#

If you want to remove a hostname from the table, all you need to do is use the no ip host command like this:

SW-1(config)#no ip host SW-3

The drawback to going with this host table method is that you must create a host table on each router in order to be able to resolve names. So clearly, if you have a whole bunch of routers and want to resolve names, using DNS is a much better option!

Using DNS to Resolve Names

If you have a lot of devices, you don't want to create a host table in each one of them unless you've also got a lot of time to waste. Since most of us don't, I highly recommend using a DNS server to resolve hostnames instead!

Anytime a Cisco device receives a command it doesn't understand, it will try to resolve it through DNS by default. Watch what happens when I type the special command todd at a Cisco router prompt:

SW-1#todd

Translating "todd"...domain server (255.255.255.255)

% Unknown command or computer name, or unable to find

  computer address

SW-1#

Because it doesn't know my name or the command I'm trying to type, it tries to resolve this through DNS. This is really annoying for two reasons: first, because it doesn't know my name <grin>, and second, because I need to hang out and wait for the name lookup to time out. You can get around this and prevent a time-consuming DNS lookup by using the no ip domain-lookup command on your router from global configuration mode.

So if you have a DNS server on your network, you'll need to add a few commands to make DNS name resolution work well for you:

• The first command is ip domain-lookup, which is turned on by default. It needs to be entered only if you previously turned it off with the no ip domain-lookup command. The command can be used without the hyphen as well with the syntax ip domain lookup.
• The second command is ip name-server. This sets the IP address of the DNS server. You can enter the IP addresses of up to six servers.
• The last command is ip domain-name. Although this command is optional, you really set it because it appends the domain name to the hostname you type in. Since DNS uses a fully qualified domain name (FQDN) system, you must have a second-level DNS name, in the form domain.com.

Here's an example of using these three commands:

SW-1#config t

SW-1(config)#ip domain-lookup

SW-1(config)#ip name-server ?

  A.B.C.D  Domain server IP address (maximum of 6)

SW-1(config)#ip name-server 4.4.4.4

SW-1(config)#ip domain-name lammle.com

SW-1(config)#^Z

Exam Essentials

Build a static host table on a router. By using the global configuration command ip host host_name [tcp_port_number] ip_address, you can build a static host table on your router. You can apply multiple IP addresses against the same host entry.

Troubleshoot client connectivity issues involving DNS

After the DNS configurations have been set, you can test the DNS server by using a hostname to ping or telnet into a device like this:

SW-1#ping SW-3

Translating "SW-3"...domain server (4.4.4.4) [OK]

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.100.128.8, timeout is

  2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max

  = 28/31/32 ms

Notice that the router uses the DNS server to resolve the name.

After a name is resolved using DNS, use the show hosts command to verify that the device cached this information in the host table. If I hadn't used the ip domain-name ­lammle.com command in the previous section, “Using DNS to Resolve Names” I would have needed to type in ping sw-3.lammle.com, which is kind of a hassle.

Exam Essentials

Verify the host table on a router. You can verify the host table with the show hosts command.

Configure and verify DHCP on a router (excluding static reservations)

To configure a DHCP server for your hosts, you need the following information at minimum:

Network and mask for each LAN Network ID, also called a scope. All addresses in a subnet can be leased to hosts by default.

Reserved/excluded addresses Reserved addresses for printers, servers, routers, etc. These addresses will not be handed out to hosts. I usually reserve the first address of each subnet for the router, but you don't have to do this.

Default router This is the router's address for each LAN.

DNS address A list of DNS server addresses provided to hosts so they can resolve names.

Server

Here are your configuration steps:

1. Exclude the addresses you want to reserve. The reason you do this step first is because as soon as you set a network ID, the DHCP service will start responding to client requests.
2. Create your pool for each LAN using a unique name.
3. Choose the network ID and subnet mask for the DHCP pool that the server will use to provide addresses to hosts.
4. Add the address used for the default gateway of the subnet.
5. Provide the DNS server address(es).
6. If you don't want to use the default lease time of 24 hours, you need to set the lease time in days, hours, and minutes.

I'll configure the switch in Figure 5.1 to be the DHCP server for the Sales wireless LAN.

Understand that this configuration could just have easily been placed on the router in Figure 5.1. Here's how we'll configure DHCP using the 192.168.10.0/24 network ID:

Switch(config)#ip dhcp excluded-address 192.168.10.1 192.168.10.10

Switch(config)#ip dhcp pool Sales_Wireless

Switch(dhcp-config)#network 192.168.10.0 255.255.255.0

Switch(dhcp-config)#default-router 192.168.10.1

Switch(dhcp-config)#dns-server 4.4.4.4

Switch(dhcp-config)#lease 3 12 15

First, you can see that I reserved 10 addresses in the range for the router, servers, and printers, etc. I then created the pool named Sales_Wireless, added the default gateway and DNS server, and set the lease to 3 days, 12 hours, and 15 minutes (which isn't really significant because I just set it that way for demonstration purposes). Pretty straightforward, right? The switch will now respond to DHCP client requests. But what happens if we need to provide an IP address from a DHCP server to a host that's not in our broadcast domain, or if we want to receive a DHCP address for a client from a remote server?

Relay

If you need to provide addresses from a DHCP server to hosts that aren't on the same LAN as the DHCP server, you can configure your router interface to relay or forward the DHCP client requests, as shown in Figure 5.2. If we don't provide this service, our router would receive the DHCP client broadcast, promptly discard it, and the remote host would never receive an address—unless we added a DHCP server on every broadcast domain! Let's take a look at how we would typically configure DHCP service in today's networks.

So we know that because the hosts off the router don't have access to a DHCP server, the router will simply drop their client request broadcast messages by default. To solve this problem, we can configure the Fa0/0 interface of the router to accept the DHCP client requests and forward them to the DHCP server like this:

Router#config t

Router(config)#interface fa0/0

Router(config-if)#ip helper-address 10.10.10.254

Now I know that was a pretty simple example, and there are definitely other ways to configure the relay, but rest assured that I've covered this objective for you. Also, I want you to know that ip helper-address forwards more than just DHCP client requests, so be sure to research this command before you implement it! Now that I've demonstrated how to create the DHCP service, let's take a minute to verify DHCP before moving on to NTP.

Client

The client configuration merely consists of configuring the router or switch as a DHCP client. This is done on a per-interface basis. On each interface, rather than configuring an IP address, execute the following command:

Router(config-if)#ip address dhcp

TFTP, DNS, and Gateway Options

Specifying a default gateway and a DNS server for DHCP clients was covered in the section “Server.” To provide a TFTP server address of 192.168.2.9, execute the following command at the dhcp pool configuration prompt:

Router(config)#ip dhcp pool 50

Router(dhcp-config)#option 150 ip 192.168.2.9

Exam Essentials

Describe the functions of DHCP in the network. Dynamic Host Configuration Protocol (DHCP) provides network configuration information (including IP addresses) to hosts, eliminating the need to perform the configurations manually.

Troubleshoot client- and router-based DHCP connectivity issues

Consider the following DHCP configuration:

Corp#config t

Corp(config)#ip dhcp excluded-address 192.168.10.1

Corp(config)#ip dhcp excluded-address 192.168.20.1

Corp(config)#ip dhcp pool SF_LAN

Corp(dhcp-config)#network 192.168.10.0 255.255.255.0

Corp(dhcp-config)#default-router 192.168.10.1

Corp(dhcp-config)#dns-server 4.4.4.4

Corp(dhcp-config)#exit

Corp(config)#ip dhcp pool LA_LAN

Corp(dhcp-config)#network 192.168.20.0 255.255.255.0

Corp(dhcp-config)#default-router 192.168.20.1

Corp(dhcp-config)#dns-server 4.4.4.4

Corp(dhcp-config)#exit

Corp(config)#exit

Corp#copy run start

Destination filename [startup-config]?

Building configuration...

Creating DHCP pools on a router is actually a simple process, and you would go about the configuration the same way on any router you wish to add a DHCP pool to. To designate a router as a DHCP server, you just create the pool name, add the network/subnet and the default gateway, and then exclude any addresses that you don't want handed out. You definitely want to make sure you've excluded the default gateway address, and you'd usually add a DNS server as well. I always add any exclusions first, and remember that you can conveniently exclude a range of addresses on a single line. Soon, I'll demonstrate verification commands, but first, we need to figure out why the Corp router can't assign IP addresses to remote networks by default!

Now I'm pretty sure I configured DHCP correctly, but I just have this nagging feeling I forgot something important. What could that be? Well, if some hosts are remote across a router, what would I need to do that would allow them to get an address from a DHCP server? If you concluded that I've got to configure the local router interfaces in those remote networks to forward the DHCP client requests to the server, you got it! For example if I had two routers (LA and SF) that I wanted to perform this forwarding, I would configure them with the IP address of the DHCP server (Corp).

Here's how we'd go about doing that:

LA#config t

LA(config)#int f0/0

LA(config-if)#ip helper-address 172.16.20.1

 

SF#config t

SF(config)#int f0/0

SF(config-if)#ip helper-address 172.16.10.1

Now to test my configuration of the DHCP server on the Corp router. I'm going to go to each host on the SF and LA routers and make them DHCP clients. By the way, I'm using an old router to represent “hosts,” which just happens to work great for studying purposes. Here's how I did that:

SF_PC(config)#int e0

SF_PC(config-if)#ip address dhcp

SF_PC(config-if)#no shut

Interface Ethernet0 assigned DHCP address 192.168.10.8, mask 255.255.255.0

LA_PC(config)#int e0

LA_PC(config-if)#ip addr dhcp

LA_PC(config-if)#no shut

Interface Ethernet0 assigned DHCP address 192.168.20.4, mask 255.255.255.0

Nice! Don't you love it when things just work the first time? Sadly, this just isn't exactly a realistic expectation in the networking world, so we must be able to troubleshoot and verify our networks. Let's verify our DHCP server with a few show commands:

Corp#sh ip dhcp binding

Bindings from all pools not associated with VRF:

IP address          Client-ID/              Lease expiration        Type

                    Hardware address/

                    User name

192.168.10.8        0063.6973.636f.2d30.    Sept 16 2013 10:34 AM    Automatic

                    3035.302e.3062.6330.

                    2e30.3063.632d.4574.

                    30

192.168.20.4        0063.6973.636f.2d30.    Sept 16 2013 10:46 AM    Automatic

                    3030.322e.3137.3632.

                    2e64.3032.372d.4574.

                    30

We can see from earlier that our little DHCP server is working! Let's try another couple of commands:

Corp#sh ip dhcp pool SF_LAN

Pool SF_LAN :

 Utilization mark (high/low)    : 100 / 0

 Subnet size (first/next)       : 0 / 0

 Total addresses                : 254

 Leased addresses               : 3

 Pending event                  : none

 1 subnet is currently in the pool :

 Current index        IP address range                    Leased addresses

 192.168.10.9         192.168.10.1     - 192.168.10.254    3

 

Corp#sh ip dhcp conflict

IP address        Detection method   Detection time          VRF

The last command would tell us if we had two hosts with the same IP address, so it's good news because there are no conflicts reported! Two detection methods are used to confirm this:

• A ping from the DHCP server to make sure no other host responds before handing out an address
• A gratuitous ARP from a host that receives a DHCP address from the server

The DHCP client will send an ARP request with its new IP address, looking to see if anyone responds, and if so, it will report the conflict to the server.

Exam Essentials

Troubleshoot DHCP in the network. Use the show ip dhcp pool, show ip dhcp binding, and show ip dhcp conflict commands to identify issues preventing proper operation of DHCP.

Configure, verify, and troubleshoot basic HSRP

HSRP is a Cisco proprietary protocol that can be run on most, but not all, of Cisco's router and multilayer switch models. It defines a standby group, and each standby group that you define includes the following routers:

• Active router
• Standby router
• Virtual router
• Any other routers that may be attached to the subnet

The problem with HSRP is that with it, only one router is active and two or more routers just sit there in standby mode and won't be used unless a failure occurs—not very cost effective or efficient! Figure 5.3 shows how only one router is used at a time in an HSRP group. The standby group will always have at least two routers participating in it. The primary players in the group are the one active router and one standby router that communicate to each other using multicast Hello messages. The Hello messages provide all of the required communication for the routers. The Hellos contain the information required to accomplish the election that determines the active and standby router positions. They also hold the key to the failover process. If the standby router stops receiving Hello packets from the active router, it then takes over the active router role, as shown in Figure 5.4.

As soon as the active router stops responding to Hellos, the standby router automatically becomes the active router and starts responding to host requests.

Virtual MAC Address

A virtual router in an HSRP group has a virtual IP address and a virtual MAC address. So where does that virtual MAC address come from? The virtual IP address isn't that hard to figure out; it just has to be a unique IP address on the same subnet as the hosts defined in the configuration. But MAC addresses are a little different, right? Or are they? The answer is yes—sort of. With HSRP, you create a totally new, made-up MAC address in addition to the IP address.

The HSRP MAC address has only one variable piece in it. The first 24 bits still identify the vendor who manufactured the device (the organizationally unique identifier, or OUI). The next 16 bits in the address tell us that the MAC address is a well-known HSRP MAC address. Finally, the last 8 bits of the address are the hexadecimal representation of the HSRP group number.

Let me clarify all this with an example of what an HSRP MAC address would look like:

0000.0c07.ac0a

• The first 24 bits (0000.0c) are the vendor ID of the address; in the case of HSRP being a Cisco protocol, the ID is assigned to Cisco.
• The next 16 bits (07.ac) are the well-known HSRP ID. This part of the address was assigned by Cisco in the protocol, so it's always easy to recognize that this address is for use with HSRP.
• The last 8 bits (0a) are the only variable bits and represent the HSRP group number that you assign. In this case, the group number is 10 and is converted to hexadecimal when placed in the MAC address, where it becomes the 0a that you see.

You can see this displayed with every MAC address added to the ARP cache of every router in the HSRP group. There will be the translation from the IP address to the MAC address, as well as the interface on which it's located.

HSRP Timers

Before we get deeper into the roles that each of the routers can have in an HSRP group, I want to define the HSRP timers. The timers are very important to HSRP function because they ensure communication between the routers, and if something goes wrong, they allow the standby router to take over. The HSRP timers include hello, hold, active, and standby.

Hello timer The hello timer is the defined interval during which each of the routers send out Hello messages. Their default interval is 3 seconds and they identify the state that each router is in. This is important because the particular state determines the specific role of each router and, as a result, the actions each will take within the group. Figure 5.5 shows the Hello messages being sent and the router using the hello timer to keep the network flowing in case of a failure.

This timer can be changed, and people used to avoid doing so because it was thought that lowering the hello value would place an unnecessary load on the routers. That isn't true with most of the routers today; in fact, you can configure the timers in milliseconds, meaning the failover time can be in milliseconds! Still, keep in mind that increasing the value will make the standby router wait longer before taking over for the active router when it fails or can't communicate.

Hold timer The hold timer specifies the interval the standby router uses to determine whether the active router is offline or out of communication. By default, the hold timer is 10 seconds, roughly three times the default for the hello timer. If one timer is changed for some reason, I recommend using this multiplier to adjust the other timers too. By setting the hold timer at three times the hello timer, you ensure that the standby router doesn't take over the active role every time there's a short break in communication.

Active timer The active timer monitors the state of the active router. The timer resets each time a router in the standby group receives a Hello packet from the active router. This timer expires based on the hold time value that's set in the corresponding field of the HSRP Hello message.

Standby timer The standby timer is used to monitor the state of the standby router. The timer resets anytime a router in the standby group receives a Hello packet from the standby router and expires based on the hold time value that's set in the respective Hello packet.

Group Roles

Each of the routers in the standby group has a specific function and role to fulfill. The three main roles are as virtual router, active router, and standby router. Additional routers can also be included in the group.

Virtual router As its name implies, the virtual router is not a physical entity. It really just defines the role that's held by one of the physical routers. The physical router that communicates as the virtual router is the current active router. The virtual router is nothing more than a separate IP address and MAC address to which packets are sent.

Active router The active router is the physical router that receives data sent to the virtual router address and routes it onward to its various destinations. As I mentioned, this router accepts all the data sent to the MAC address of the virtual router in addition to the data that's been sent to its own physical MAC address. The active router processes the data that's being forwarded and will also answer any ARP requests destined for the virtual router's IP address.

Standby router The standby router is the backup to the active router. Its job is to monitor the status of the HSRP group and quickly take over packet-forwarding responsibilities if the active router fails or loses communication. Both the active and standby routers transmit Hello messages to inform all other routers in the group of their role and status.

Other routers An HSRP group can include additional routers, which are members of the group but don't take the primary roles of either active or standby states. These routers monitor the Hello messages sent by the active and standby routers to ensure that an active and standby router exists for the HSRP group that they belong to. They will forward data that's specifically addressed to their own IP addresses, but they will never forward data addressed to the virtual router unless elected to the active or standby state. These routers send “speak” messages based on the hello timer interval that informs other routers of their position in an election.

Interface Tracking

By now, you probably understand why having a virtual router on a LAN is a great idea. You also know why it's a very good thing that the active router can change dynamically, giving us much needed redundancy on our inside network. But what about the links to the upstream network or the Internet connection off of those HSRP-enabled routers? And how will the inside hosts know if an outside interface goes down or if they are sending packets to an active router that can't route to a remote network? Key questions, and HSRP does provide a solution for them; it's called interface tracking.

Figure 5.6 shows how HSRP-enabled routers can keep track of the interface status of the outside interfaces and how they can switch the inside active router as needed to keep the inside hosts from losing connectivity upstream.

If the outside link of the active router goes down, the standby router will take over and become the active router. There is a default priority of 100 on routers configured with an HSRP interface, and if you raise this priority (we'll do this in a minute), it means your router has a higher priority to become the active router. The reason I am bringing this up now is because when a tracked interface goes down, it decrements the priority of the router on which the tracked interface went down.

Configuring and Verifying HSRP

Configuring and verifying the different HSRP can be pretty simple, especially regarding the Cisco objectives, but as with most technologies, you can quickly get into advanced configurations and territory with HSRP if you're not careful, so I'll show you exactly what you need to know.

The Cisco objectives don't cover much about the configuration of HSRP, but verification and troubleshooting is important, so I'll use a simple configuration on two routers here. Figure 5.7 shows the network I'll use to demonstrate HSRP.

This is a simple configuration for which you really need only one command: standby group ip virtual_ip. After using this single mandatory command, I'll name the group and set the interface on router HSRP1 so it wins the election and becomes the active router by default.

HSRP1#config t

HSRP1(config)#int fa0/0

HSRP1(config-if)#standby ?

  <0-255>         group number

  authentication  Authentication

  delay           HSRP initialisation delay

  ip              Enable HSRP and set the virtual IP address

  mac-address     Virtual MAC address

  name            Redundancy name string

  preempt         Overthrow lower priority Active routers

  priority        Priority level

  redirect        Configure sending of ICMP Redirect messages with an HSRP

                  virtual IP address as the gateway IP address

  timers          Hello and hold timers

  track           Priority tracking

  use-bia         HSRP uses interface's burned in address

  version         HSRP version

HSRP1(config-if)#standby 1 ip 10.1.1.10

HSRP1(config-if)#standby 1 name HSRP_Test

HSRP1(config-if)#standby 1 priority ?

  <0-255>  Priority value

 

HSRP1(config-if)#standby 1 priority 110

000047: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Speak -> Standby

000048: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active110

Priority

There are quite a few commands available to use in an advanced setting with the standby command, but we'll stick with the simple commands that follow the Cisco objectives. First, I numbered the group (1), which must be the same on all routers sharing HSRP duties; then I added the virtual IP address shared by all routers in the HSRP group. Optionally, I named the group and then set the priority of HSRP1 to 110, and I left HSRP2 to a default of 100. The router with the highest priority will win the election to become the active router. Let's configure the HSRP2 router now:

HSRP2#config t

HSRP2(config)#int fa0/0

HSRP2(config-if)#standby 1 ip 10.1.1.10

HSRP2(config-if)#standby 1 name HSRP_Test

*Jun 23 21:40:10.699:%HSRP-5-STATECHANGE:FastEthernet0/0 Grp 1 state

Speak -> Standby

I really only needed the first command—naming it was for administrative purposes only. Notice that the link came up and HSRP2 became the standby router because it had the lower priority of 100 (the default). Make a note that this priority comes into play only if both routers were to come up at the same time. This means that HSRP2 would be the active router, regardless of the priority, if it comes up first.

Let's take a look at the configurations with the show standby and show standby brief commands:

HSRP1(config-if)#do show standby

FastEthernet0/0 - Group 1

  State is Active

    2 state changes, last state change 00:03:40

  Virtual IP address is 10.1.1.10

  Active virtual MAC address is 0000.0c07.ac01

    Local virtual MAC address is 0000.0c07.ac01 (v1 default)

  Hello time 3 sec, hold time 10 sec

    Next hello sent in 1.076 secs

  Preemption disabled

  Active router is local

  Standby router is 10.1.1.2, priority 100 (expires in 7.448 sec)

  Priority 110 (configured 110)

  IP redundancy name is "HSRP_Test" (cfgd)

 

HSRP1(config-if)#do show standby brief

                     P indicates configured to preempt.

                     |

Interface   Grp Prio P State    Active          Standby         Virtual IP

Fa0/0       1   110    Active   local           10.1.1.2        10.1.1.10

Notice the group number in each output—it's a key troubleshooting spot! Each router must be configured in the same group or they won't work. Also, you can see the virtual MAC and configured virtual IP address, as well as the hello time of 3 seconds. The standby and virtual IP addresses are also displayed.

HSRP2's output tells us that it's in standby mode:

HSRP2(config-if)#do show standby brief

                     P indicates configured to preempt.

                     |

Interface   Grp Prio P State    Active          Standby         Virtual IP

Fa0/0       1   100    Standby  10.1.1.1        local           10.1.1.10

HRSP2(config-if)#

Notice so far that you have seen HSRP states of active and standby, but watch what happens when I disable Fa0/0:

HSRP1#config t

HSRP1(config)#interface Fa0/0

HSRP1(config-if)#shutdown

*Nov 20 10:06:52.369: %HSRP-5-STATECHANGE: Ethernet0/0 Grp 1 state Active -> Init

The HSRP went into Init state, meaning it's trying to initialize with a peer. The possible interface states for HSRP are shown in Table 5.1.

Table 5.1 HSRP states

There is one other command that I want to cover. If you're studying and want to understand HSRP, you should learn to use this debug command and have your active and standby routers move. You'll really get to see what is going on:

HSRP2#debug standby

*Sep 15 00:07:32.344:HSRP:Fa0/0 Interface UP

*Sep 15 00:07:32.344:HSRP:Fa0/0 Initialize swsb, Intf state Up

*Sep 15 00:07:32.344:HSRP:Fa0/0 Starting minimum intf delay (1 secs)

*Sep 15 00:07:32.344:HSRP:Fa0/0 Grp 1 Set virtual MAC 0000.0c07.ac01

type: v1 default

*Sep 15 00:07:32.344:HSRP:Fa0/0 MAC hash entry 0000.0c07.ac01, Added

Fa0/0 Grp 1 to list

*Sep 15 00:07:32.348:HSRP:Fa0/0 Added 10.1.1.10 to hash table

*Sep 15 00:07:32.348:HSRP:Fa0/0 Grp 1 Has mac changed? cur 0000.0c07.ac01

new 0000.0c07.ac01

*Sep 15 00:07:32.348:HSRP:Fa0/0 Grp 1 Disabled -> Init

*Sep 15 00:07:32.348:HSRP:Fa0/0 Grp 1 Redundancy "hsrp-Fa0/0-1" state

Disabled -> Init

*Sep 15 00:07:32.348:HSRP:Fa0/0 IP Redundancy "hsrp-Fa0/0-1" added

*Sep 15 00:07:32.348:HSRP:Fa0/0 IP Redundancy "hsrp-Fa0/0-1" update,

Disabled -> Init

*Sep 15 00:07:33.352:HSRP:Fa0/0 Intf min delay expired

*Sep 15 00:07:39.936:HSRP:Fa0/0 Grp 1 MAC addr update Delete

from SMF  0000.0c07.ac01

*Sep 15 00:07:39.936:HSRP:Fa0/0 Grp 1 MAC addr update Delete

from SMF  0000.0c07.ac01

*Sep 15 00:07:39.940:HSRP:Fa0/0 ARP reload

HSRP Load Balancing

As you know, HSRP doesn't really perform true load balancing, but it can be configured to use more than one router at a time for use with different VLANs. This is different from the true load balancing that's possible with GLBP, which I'll demonstrate in a minute, but HSRP still performs a load-balancing act of sorts. Figure 5.8 shows how load balancing would look with HSRP.

How can you get two HSRP routers active at the same time? Well for the same subnet with this simple configuration, you can't, but if you trunk the links to each router, they'll run and be configured with a “router on a stick” (ROAS) configuration. This means that each router can be the default gateway for different VLANs, but you still can have only one active router per VLAN. Typically, in a more advanced setting you won't use HSRP for load balancing; you'll use GLBP, but you can do load-sharing with HSRP, and that is the topic of an objective, so we'll remember that, right? It comes in handy because it prevents situations where a single point of failure causes traffic interruptions. This HSRP feature improves network resilience by allowing for load-balancing and redundancy capabilities between subnets and VLANs.

Preemption

When preemption is set, it allows a router than has gone down to reassume the position of active router when it comes back online. It is set under the interface using the following command, where 1 is the group number.

Router(config-if)#standy 1 preempt

Version

HSRP comes in two versions, 1 and 2. If there is a version mismatch, both routers will become active and you'll again have duplicate IP address warnings.

In version 1, HSRP messages are sent to the multicast IP address 224.0.0.2 and UDP port 1985. HSRP version 2 uses the multicast IP address 224.0.0.102 and UDP port 1985. These IP addresses and ports need to be permitted in the inbound access lists. If the packets are blocked, the peers will not see each other and there will be no HSRP redundancy.

HSRP Troubleshooting

Besides HSRP verification, the troubleshooting of HSRP is the Cisco objective hotspot, so let's go through this.

Most of your HSRP misconfiguration issues can be solved by checking the output of the show standby command. In the output, you can see the active IP and the MAC address, the timers, the active router, and more, as shown earlier in the verification section.

There are several possible misconfigurations of HSRP, but these are what you need to pay attention to for your CCNA. Other than a version mismatch, you can run into these other issues:

Different HSRP virtual IP addresses configured on the peers Console messages will notify you about this, of course, but if you configure it this way and the active router fails, the standby router takes over with a virtual IP address, which is different than the one used previously, and different than the one configured as the default-gateway address for end devices, so your hosts stop working, which defeats the purpose of a FHRP.

Different HSRP groups configured on the peers This misconfiguration leads to both peers becoming active, and you'll start receiving duplicate IP address warnings.

Exam Essentials

Remember the HSRP virtual address. The HSRP MAC address has only one variable piece in it. The first 24 bits still identify the vendor who manufactured the device (the organizationally unique identifier, or OUI). The next 16 bits in the address tell us that the MAC address is a well-known HSRP MAC address. Finally, the last 8 bits of the address are the hexadecimal representation of the HSRP group number.

Let me clarify all this with an example of what an HSRP MAC address would look like:

0000.0c07.ac0a

Configure, verify, and troubleshoot inside source NAT

Network Address Translation (NAT) is similar to Classless Inter-Domain Routing (CIDR) in that the original intention for NAT was to slow the depletion of available IP address space by allowing multiple private IP addresses to be represented by a much smaller number of public IP addresses.

Since then, it's been discovered that NAT is also a useful tool for network migrations and mergers, server load sharing, and creating “virtual servers.” So in the following sections, I'm going to describe the basics of NAT functionality and the terminology common to NAT.

Because NAT really decreases the overwhelming amount of public IP addresses required in a networking environment, it comes in really handy when two companies that have duplicate internal addressing schemes merge. NAT is also a great tool to use when an organization changes its Internet service provider (ISP) but the networking manager needs to avoid the hassle of changing the internal address scheme.

Here's a list of situations when NAT can be especially helpful:

• When you need to connect to the Internet and your hosts don't have globally unique IP addresses
• When you've changed to a new ISP that requires you to renumber your network
• When you need to merge two intranets with duplicate addresses

Static

This type of NAT is designed to allow one-to-one mapping between local and global addresses. Keep in mind that the static version requires you to have one real Internet IP address for every host on your network.

Let's take a look at a simple example of a basic static NAT configuration:

ip nat inside source static 10.1.1.1 170.46.2.2

!

interface Ethernet0

 ip address 10.1.1.10 255.255.255.0

 ip nat inside

!

interface Serial0

 ip address 170.46.2.1 255.255.255.0

 ip nat outside

!

In the preceding router output, the ip nat inside source command identifies which IP addresses will be translated. In this configuration example, the ip nat inside source command configures a static translation between the inside local IP address 10.1.1.1 and the outside global IP address 170.46.2.2.

Scrolling farther down in the configuration, we find an ip nat command under each interface. The ip nat inside command identifies that interface as the inside interface. The ip nat outside command identifies that interface as the outside interface. When you look back at the ip nat inside source command, you can see that the command is referencing the inside interface as the source or starting point of the translation. You could also use the command like this: ip nat outside source. This option indicates that the interface you designated as the outside interface should become the source or starting point for the translation.

Pool

This type gives you the ability to map an unregistered IP address to a registered IP address from out of a pool of registered IP addresses. You don't have to statically configure your router to map each inside address to an individual outside address as you would using static NAT, but you do have to have enough real, bona fide IP addresses for everyone who's going to be sending packets to and receiving them from the Internet at the same time.

Basically, dynamic NAT really means we have a pool of addresses that we'll use to provide real IP addresses to a group of users on the inside. Because we don't use port numbers, we must have real IP addresses for every user who's trying to get outside the local network simultaneously.

Here is a sample output of a dynamic NAT configuration:

ip nat pool todd 170.168.2.3 170.168.2.254

    netmask 255.255.255.0

ip nat inside source list 1 pool todd

!

interface Ethernet0

 ip address 10.1.1.10 255.255.255.0

 ip nat inside

!

interface Serial0

 ip address 170.168.2.1 255.255.255.0

 ip nat outside

!

access-list 1 permit 10.1.1.0 0.0.0.255

!

The ip nat inside source list 1 pool todd command tells the router to translate IP addresses that match access-list 1 to an address found in the IP NAT pool named todd. Here the ACL isn't there to filter traffic for security reasons by permitting or denying traffic. In this case, it's there to select or designate what we often call interesting traffic. When interesting traffic has been matched with the access list, it's pulled into the NAT process to be translated. This is actually a common use for access lists, which aren't always just stuck with the dull job of just blocking traffic at an interface!

The command ip nat pool todd 170.168.2.3 170.168.2.254 netmask 255 .255.255.0 creates a pool of addresses that will be distributed to the specific hosts that require global addresses. When troubleshooting NAT for the Cisco objectives, always check this pool to confirm that there are enough addresses in it to provide translation for all the inside hosts. Last, check to make sure the pool names match exactly on both lines, remembering that they are case sensitive; if they don't, the pool won't work!

PAT

This is the most popular type of NAT configuration. Understand that overloading really is a form of dynamic NAT that maps multiple unregistered IP addresses to a single registered IP address (many-to-one) by using different source ports. Now, why is this so special? Well, because it's also known as Port Address Translation (PAT), which is also commonly referred to as NAT Overload. Using PAT allows you to permit thousands of users to connect to the Internet using only one real global IP address—pretty slick, right? Seriously, NAT Overload is the real reason we haven't run out of valid IP addresses on the Internet. Really—I'm not joking!

This last example shows how to configure inside global address overloading. This is the typical form of NAT that we would use today. It's actually now rare to use static or dynamic NAT unless it is for something like statically mapping a server, for example.

Here is a sample output of a PAT configuration:

ip nat pool globalnet 170.168.2.1 170.168.2.1 netmask 255.255.255.0

ip nat inside source list 1 pool globalnet overload

!

interface Ethernet0/0

 ip address 10.1.1.10 255.255.255.0

 ip nat inside

!

interface Serial0/0

 ip address 170.168.2.1 255.255.255.0

 ip nat outside

!

access-list 1 permit 10.1.1.0 0.0.0.255

The nice thing about PAT is that these are the only differences between this configuration and the previous dynamic NAT configuration:

• Our pool of addresses has shrunk to only one IP address.
• We included the overload keyword at the end of our ip nat inside source command.

A really key factor to see in the example is that the one IP address that's in the pool for us to use is the IP address of the outside interface. This is perfect if you are configuring NAT Overload for yourself at home or for a small office that only has one IP address from your ISP. You could, however, use an additional address such as 170.168.2.2 if you had that address available to you as well, and doing that could prove very helpful in a very large implementation where you've got such an abundance of simultaneously active internal users that you need to have more than one overloaded IP address on the outside!

Simple Verification of NAT

As always, once you've chosen and configured the type of NAT you're going to run, which is typically PAT, you must be able to verify your configuration.

To see basic IP address translation information, use the following command:

Router#show ip nat translations

When looking at the IP NAT translations, you may see many translations from the same host to the corresponding host at the destination. Understand that this is typical when there are many connections to the same server.

You can also verify your NAT configuration via the debug ip nat command. This output will show the sending address, the translation, and the destination address on each debug line:

Router#debug ip nat

But wait—how do you clear your NAT entries from the translation table? Just use the clear ip nat translation command, and if you want to clear all entries from the NAT table, just use an asterisk (*) at the end of the command.

Testing and Troubleshooting NAT

Cisco's NAT gives you some serious power—and it does so without much effort, because the configurations are really pretty simple. But we all know nothing's perfect, so in case something goes wrong, you can figure out some of the more common culprits by running through this list of potential causes:

• Check the dynamic pools. Are they composed of the right scope of addresses?
• Check to see if any dynamic pools overlap.
• Check to see if the addresses used for static mapping and those in the dynamic pools overlap.
• Ensure that your access lists specify the correct addresses for translation.
• Make sure there aren't any addresses left out that need to be there, and ensure that none are included that shouldn't be.
• Check to make sure you've got both the inside and outside interfaces delimited ­properly.

A key thing to keep in mind is that one of the most common problems with a new NAT configuration often isn't specific to NAT at all—it usually involves a routing blooper. So, because you're changing a source or destination address in a packet, make sure your router still knows what to do with the new address after the translation!

The first command you should typically use is the show ip nat translations command:

Router#show ip nat trans

Pro   Inside global   Inside local   Outside local   Outside global

---   192.2.2.1       10.1.1.1       ---             ---

---   192.2.2.2       10.1.1.2       ---             ---

After checking out this output, can you tell me if the configuration on the router is static or dynamic NAT? The answer is yes, either static or dynamic NAT is configured because there's a one-to-one translation from the inside local to the inside global. Basically, by looking at the output, you can't tell if it's static or dynamic per se, but you absolutely can tell that you're not using PAT because there are no port numbers.

Let's take a look at another output:

Router#sh ip nat trans

Pro Inside global      Inside local       Outside local      Outside global

tcp 170.168.2.1:11003  10.1.1.1:11003     172.40.2.2:23      172.40.2.2:23

tcp 170.168.2.1:1067   10.1.1.1:1067      172.40.2.3:23      172.40.2.3:23

Okay, you can easily see that the previous output is using NAT Overload (PAT). The protocol in this output is TCP, and the inside global address is the same for both entries.

Supposedly the sky's the limit regarding the number of mappings the NAT table can hold. But this is reality, so things like memory and CPU, or even the boundaries set in place by the scope of available addresses or ports, can cause limitations on the actual number of entries. Consider that each NAT mapping devours about 160 bytes of memory. And sometimes the amount of entries must be limited for the sake of performance or because of policy restrictions, but this doesn't happen very often. In situations like these, just go to the ip nat translation max-entries command for help.

Another handy command for troubleshooting is show ip nat statistics. Deploying this gives you a summary of the NAT configuration, and it will count the number of active translation types too. Also counted are hits to an existing mapping as well any misses, with the latter causing an attempt to create a mapping. This command will also reveal expired translations. If you want to check into dynamic pools, their types, the total available addresses, how many addresses have been allocated and how many have failed, plus the number of translations that have occurred, just use the pool keyword.

Here is an example of the basic NAT debugging command:

Router#debug ip nat

NAT: s=10.1.1.1->192.168.2.1, d=172.16.2.2 [0]

NAT: s=172.16.2.2, d=192.168.2.1->10.1.1.1 [0]

NAT: s=10.1.1.1->192.168.2.1, d=172.16.2.2 [1]

NAT: s=10.1.1.1->192.168.2.1, d=172.16.2.2 [2]

NAT: s=10.1.1.1->192.168.2.1, d=172.16.2.2 [3]

NAT*: s=172.16.2.2, d=192.168.2.1->10.1.1.1 [1]

Notice the last line in the output and how the NAT at the beginning of the line has an asterisk (*). This means the packet was translated and fast-switched to the destination. What's fast-switched? Well in brief, fast-switching has gone by several aliases, such as cache-based switching and this nicely descriptive name, “route one switch many.” The fast-switching process is used on Cisco routers to create a cache of layer 3 routing information to be accessed at layer 2 so packets can be forwarded quickly through a router without the routing table having to be parsed for every packet. As packets are packet switched (looked up in the routing table), this information is stored in the cache for later use if needed for faster routing processing.

Let's get back to verifying NAT. Did you know you can manually clear dynamic NAT entries from the NAT table? You can, and doing this can come in seriously handy if you need to get rid of a specific rotten entry without sitting around waiting for the timeout to expire! A manual clear is also really useful when you want to clear the whole NAT table to reconfigure a pool of addresses.

You also need to know that the Cisco IOS software just won't allow you to change or delete an address pool if any of that pool's addresses are mapped in the NAT table. The clear ip nat translations command clears entries—you can indicate a single entry via the global and local address and through TCP and UDP translations, including ports, or you can just type in an asterisk (*) to wipe out the entire table. But know that if you do that, only dynamic entries will be cleared because this command won't remove static entries.

Oh, and there's more—any outside device's packet destination address that happens to be responding to any inside device is known as the inside global (IG) address. This means that the initial mapping has to be held in the NAT table so that all packets arriving from a specific connection get translated consistently. Holding entries in the NAT table also cuts down on repeated translation operations happening each time the same inside machine sends packets to the same outside destinations on a regular basis.

Let me clarify: When an entry is placed into the NAT table the first time, a timer begins ticking and its duration is known as the translation timeout. Each time a packet for a given entry translates through the router, the timer gets reset. If the timer expires, the entry will be unceremoniously removed from the NAT table and the dynamically assigned address will then be returned to the pool. Cisco's default translation timeout is 86,400 seconds (24 hours), but you can change that with the ip nat translation timeout command.

Before we move on to actually using the commands I just talked about, let's go through a couple of NAT examples and see if you can figure out the best configuration to go with. To start, look at Figure 5.9 and ask yourself two things: Where would you implement NAT in this design? What type of NAT would you configure?

In Figure 5.9, the NAT configuration would be placed on the Corporate router, and the configuration would be dynamic NAT with overload (PAT). In this next NAT example, what type of NAT is being used?

ip nat pool todd-nat 170.168.10.10 170.168.10.20 netmask 255.255.255.0

ip nat inside source list 1 pool todd-nat

The preceding command uses dynamic NAT without PAT. The pool in the command gives the answer away as dynamic, plus there's more than one address in the pool and there is no overload command at the end of our ip nat inside source command. This means we are not using PAT!

In the next NAT example, refer to Figure 5.10 and see if you can come up with the configuration needed.

Figure 5.10 shows a border router that needs to be configured with NAT and allow the use of six public IP addresses to the inside locals, 192.1.2.109 through 192.1.2.114. However, on the inside network, you have 62 hosts that use the private addresses of 192.168.10.65 through 192.168.10.126. What would your NAT configuration be on the border router?

Actually, two different answers would both work here, but the following would be my first choice based on the exam objectives:

ip nat pool Todd 192.1.2.109 192.1.2.109 netmask 255.255.255.248

access-list 1 permit 192.168.10.64 0.0.0.63

ip nat inside source list 1 pool Todd overload

The command ip nat pool Todd 192.1.2.109 192.1.2.109 netmask 255 .255.255.248 sets the pool name as Todd and creates a dynamic pool of only one address using NAT address 192.1.2.109. Instead of the netmask command, you can use the prefix-length 29 statement. Just in case you're wondering, you cannot do this on router interfaces as well!

The second answer would get you the exact same result of having only 192.1.2.109 as your inside global, but you can type this in and it will also work: ip nat pool Todd 192 .1.2.109 192.1.2.114 netmask 255.255.255.248. But this option really is a waste because the second through sixth addresses would only be used if there was a conflict with a TCP port number. You would use something like what I've shown in this example if you literally had about ten thousand hosts with one Internet connection! You would need it to help with the TCP-Reset issue when two hosts are trying to use the same source port number and get a negative acknowledgment (NAK). But in our example, we've only got up to 62 hosts connecting to the Internet at the same time, so having more than one inside global gets us nothing!

If you're fuzzy on the second line where the access list is set in the NAT configuration, this will become clearer when we cover access lists in Chapter 6, “Infrastructure Security.” But this isn't difficult to grasp because it's easy to see in this access-list line that it's just the network number and wildcard used with that command. I always say, “Every question is a subnet question,” and this one is no exception. The inside locals in this example were 192.168.10.65–126, which is a block of 64, or a 255.255.255.192 mask. As I've said in pretty much every chapter, you really need to be able to subnet quickly!

The command ip nat inside source list 1 pool Todd overload sets the dynamic pool to use PAT by using the overload command.

And be sure to add the ip nat inside and ip nat outside statements on the appropriate interfaces.

One more example, and then you are off to review questions.

The network in Figure 5.11 is already configured with IP addresses as shown in the ­figure, and there is only one configured host. However, you need to add 25 more hosts to the LAN. Now, all 26 hosts must be able to get to the Internet at the same time.

By looking at the configured network, use only the following inside addresses to configure NAT on the Corp router to allow all hosts to reach the Internet:

• Inside globals: 198.18.41.129 through 198.18.41.134
• Inside locals: 192.168.76.65 through 192.168.76.94

This one is a bit more challenging because all we have to help us figure out the configuration is the inside globals and the inside locals. But even meagerly armed with these crumbs of information, plus the IP addresses of the router interfaces shown in the figure, we can still configure this correctly.

To do that, we must first determine what our block sizes are so we can get our subnet mask for our NAT pool. This will also equip us to configure the wildcard for the access list.

You should easily be able to see that the block size of the inside globals is 8 and the block size of the inside locals is 32. Know that it's critical not to stumble on this foundational information!

So we can configure NAT now that we have our block sizes:

ip nat pool Corp 198.18.41.129 198.18.41.134 netmask 255.255.255.248

ip nat inside source list 1 pool Corp overload

access-list 1 permit 192.168.76.64 0.0.0.31

Since we had a block of only 8 for our pool, we had to use the overload command to make sure all 26 hosts can get to the Internet at the same time.

There is one other simple way to configure NAT, and I use this command at my home office to connect to my ISP. One command line and it's done! Here it is:

ip nat inside source list 1 int s0/0/0 overload

I can't say enough how much I love efficiency, and being able to achieve something cool using one measly line always makes me happy! My one little powerfully elegant line essentially says, “Use my outside local as my inside global and overload it.” Nice! Of course, I still had to create ACL 1 and add the inside and outside interface commands to the configuration, but this is a really nice, fast way to configure NAT if you don't have a pool of addresses to use.

Exam Essentials

Remember the three methods of NAT. The three methods are static, dynamic, and overloading; the latter is also called PAT.

Understand static NAT. This type of NAT is designed to allow one-to-one mapping between local and global addresses.

Understand dynamic NAT. This version gives you the ability to map a range of unregistered IP addresses to a registered IP address from out of a pool of registered IP addresses.

Understand overloading. Overloading really is a form of dynamic NAT that maps multiple unregistered IP addresses to a single registered IP address (many-to-one) by using different ports. It's also known as PAT.

Configure and verify NTP operating in a client/server mode

Network Time Protocol provides pretty much what it describes: time to all your network devices. To be more precise, NTP synchronizes clocks of computer systems over packet-switched, variable-latency data networks.

Typically you'll have an NTP server that connects through the Internet to an atomic clock. This time can then be synchronized through the network to keep all routers, switches, servers, etc. receiving the same time information.

Correct network time within the network is important:

• Correct time allows the tracking of events in the network in the correct order.
• Clock synchronization is critical for the correct interpretation of events within the syslog data.
• Clock synchronization is critical for digital certificates.

Making sure all your devices have the correct time is especially helpful for your routers and switches for looking at logs regarding security issues or other maintenance issues. Routers and switches issue log messages when different events take place—for example, when an interface goes down and then back up. As you already know, all messages generated by the IOS go only to the console port by default. However, those console messages can be directed to a syslog server.

A syslog server saves copies of console messages and can time-stamp them so you can view them at a later time. This is actually rather easy to do. Here would be your configuration on the SF router:

SF(config)#service timestamps log datetime msec

Even though I had the messages time-stamped with the command service timestamps log datetime msec, this doesn't mean that we'll know the exact time if using default clock sources.

To make sure all devices are synchronized with the same time information, we'll configure our devices to receive the accurate time information from a centralized server, as shown here in the following command and in Figure 5.12:

SF(config)#ntp server 172.16.10.1 version 4

Just use that one simple command on all your devices and each network device on your network will then have the same exact time and date information. You can then rest assured that your time stamps are accurate. You can also make your router or switch be an NTP server with the ntp master command.

To verify that our NTP client is receiving clocking information, we use the following commands:

SF#sh ntp ?

  associations  NTP associations

  status        NTP status  status     VTP domain status

 

SF#sh ntp status

Clock is unsynchronized, stratum 16, no reference clock

nominal freq is 119.2092 Hz, actual freq is 119.2092 Hz, precision is 2**18

reference time is 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)

clock offset is 0.0000 msec, root delay is 0.00 msec

S1#sh ntp associations

 

address    ref clock     st  when  poll reach  delay  offset    disp

 ~172.16.10.1   0.0.0.0          16     -    64    0     0.0    0.00  16000.

 * master (synced), # master (unsynced), + selected, - candidate, ~ configured

You can see in the example that the NTP client in SF is not synchronized with the server by using the show ntp status command. The stratum value is a number from 1 to 15, and a lower stratum value indicates a higher NTP priority; 16 means there is no clocking received.

There are many other configurations of an NTP client that are available, such as authentication of NTP so a router or switch isn't fooled into changing the time of an attack, for example.

Exam Essentials

Understand how to configure NTP. It's pretty simple to configure NTP, just like it was syslog, but we don't have to remember a bunch of options! It's just telling the syslog to mark the time and date and enable NTP:

SF(config)#service timestamps log datetime msec

SF(config)#ntp server 172.16.10.1 version 4

Review Questions

You can find the answers in the Appendix.

1. You need to configure all your routers and switches so they synchronize their clocks from one time source. What command will you type for each device?
   1. clock synchronization ip_address
   2. ntp master ip_address
   3. sync ntp ip_address
   4. ntp server ip_address version number
2. Which of the following are HSRP states? (Choose two.)
   1. INIT
   2. Active
   3. Established
   4. Idle
3. Which command configures an interface to enable HSRP with the virtual router IP address 10.1.1.10?
   1. standby 1 ip 10.1.1.10
   2. ip hsrp 1 standby 10.1.1.10
   3. hsrp 1 ip 10.1.1.10
   4. standby 1 hsrp ip 10.1.1.10
4. Which command displays the status of all HSRP groups on a Cisco router or layer 3 switch?
   1. show ip hsrp
   2. show hsrp
   3. show standby hsrp
   4. show standby
   5. show hsrp groups
5. Two routers are part of an HSRP standby group and there is no priority configured on the routers for the HSRP group. Which of the following statements is correct?
   1. Both routers will be in the active state.
   2. Both routers will be in the standby state.
   3. Both routers will be in the listen state.
   4. One router will be active, the other standby.
6. Which of the following statements is true about the HSRP version 1 Hello packet?
   1. HSRP Hello packets are sent to multicast address 224.0.0.5.
   2. HSRP RP Hello packets are sent to multicast address 224.0.0.2 with TCP port 1985.
   3. HSRP Hello packets are sent to multicast address 224.0.0.2 with UDP port 1985.
   4. HSRP Hello packets are sent to multicast address 224.0.0.10 with UDP port 1986.
7. Routers HSRP1 and HSRP2 are in HSRP group 1. HSRP1 is the active router with a priority of 120 and HSRP2 has the default priority. When HSRP1 reboots, HSRP2 will become the active router. Once HSRP1 comes back up, which of the following statements will be true? (Choose two.)
   1. HSRP1 will become the active router.
   2. HSRP2 will stay the active router.
   3. HSRP1 will become the active router if it is also configured to preempt.
   4. Both routers will go into speak state.
8. What is the multicast and port number used for HSRP version 2?
   1. 224.0.0.2, UDP port 1985
   2. 224.0.0.2, TCP port 1985
   3. 224.0.0.102, UDP port 1985
   4. 224.0.0.102, TCP port 1985
9. Which of the following are disadvantages of using NAT? (Choose three.)
   1. Translation introduces switching path delays.
   2. NAT conserves legally registered addresses.
   3. NAT causes loss of end-to-end IP traceability.
   4. NAT increases flexibility when connecting to the Internet.
   5. Certain applications will not function with NAT enabled.
   6. NAT reduces address overlap occurrence.
10. Which of the following are advantages of using NAT? (Choose three.)
    1. Translation introduces switching path delays.
    2. NAT conserves legally registered addresses.
    3. NAT causes loss of end-to-end IP traceability.
    4. NAT increases flexibility when connecting to the Internet.
    5. Certain applications will not function with NAT enabled.
    6. NAT remedies address overlap occurrence.