Senior Acquisitions Editor: Kenyon Brown Development Editor: Kim Wimpsett

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

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

FIGURE 7.3

Configuring a DHCP relay

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 the

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

Verifying DHCP on Cisco IOS

There are some really useful verification commands to use on a Cisco IOS

device for monitoring and verifying a DHCP service. You’ll get to see the

output for these commands when I build the network in Chapter 9, “IP

Routing,” and add DHCP to the two remote LANs. I just want you to

begin getting familiar with them, so here’s a list of four very important

ones and what they do:

show ip dhcp binding

Lists state information about each IP address

currently leased to a client.

show ip dhcp pool [poolname]

Lists the configured range of IP

addresses, plus statistics for the number of currently leased addresses

and the high watermark for leases from each pool.

show ip dhcp server statistics

Lists DHCP server statistics—a lot of

them!

show ip dhcp conflict

If someone statically configures an IP address

on a LAN and the DHCP server hands out that same address, you’ll

end up with a duplicate address. This isn’t good, which is why this

command is so helpful!

Again, no worries because we’ll cover these vital commands thoroughly in

Chapter 9.

Syslog

Reading system messages from a switch’s or router’s internal buffer is the

most popular and efficient method of seeing what’s going on with your

network at a particular time. But the best way is to log messages to a

syslog server, which stores messages from you and can even time-stamp

and sequence them for you, and it’s easy to set up and configure!

Syslog allows you to display, sort, and even search messages, all of which

makes it a really great troubleshooting tool. The search feature is

especially powerful because you can use keywords and even severity

levels. Plus, the server can email admins based on the severity level of the

message.

Network devices can be configured to generate a syslog message and

forward it to various destinations. These four examples are popular ways

to gather messages from Cisco devices:

Logging buffer (on by default)

Console line (on by default)

Terminal lines (using the

terminal monitor

command)

Syslog server

As you already know, all system messages and debug output generated by

the IOS go out only the console port by default and are also logged in

buffers in RAM. And you also know that Cisco routers aren’t exactly shy

about sending messages! To send a message to the VTY lines, use the

terminal monitor

command. We’ll also add a small configuration needed

for syslog, which I’ll show you soon in the configuration section.

So by default, we’d see something like this on our console line:

*Oct 21 17:33:50.565:%LINK-5-CHANGED:Interface FastEthernet0/0,

changed

state to administratively down

*Oct 21 17:33:51.565:%LINEPROTO-5-UPDOWN:Line protocol on Interface

FastEthernet0/0, changed state to down

And the Cisco router would send a general version of the message to the

syslog server that would be formatted into something like this:

Seq no:timestamp: %facility-severity-MNEMONIC:description

The system message format can be broken down in this way:

seq no This stamp logs messages with a sequence number, but not by

default. If you want this output, you’ve got to configure it.

Timestamp Data and time of the message or event, which again will

show up only if configured.

Facility The facility to which the message refers.

Severity A single-digit code from 0 to 7 that indicates the severity of the

message.

MNEMONIC Text string that uniquely describes the message.

Description Text string containing detailed information about the event

being reported.

The severity levels, from the most severe level to the least severe, are

explained in

Table 7.2

. Informational is the default and will result in all

messages being sent to the buffers and console.

TABLE 7.2

Severity levels

Severity Level

Explanation

Emergency (severity 0)

System is unusable.

Alert (severity 1)

Immediate action is needed.

Critical (severity 2)

Critical condition.

Error (severity 3)

Error condition.

Warning (severity 4)

Warning condition.

Notification (severity 5)

Normal but significant condition.

Informational (severity 6) Normal information message.

Debugging (severity 7)

Debugging message.

If you are studying for your Cisco exam, you need to memorize

Table 7.2

using this acronym: Every Awesome Cisco Engineer Will

Need Icecream Daily.

Understand that only emergency-level messages will be displayed if

you’ve configured severity level 0. But if, for example, you opt for level 4

instead, level 0 through 4 will be displayed, giving you emergency, alert,

critical, error, and warning messages too. Level 7 is the highest-level

security option and displays everything, but be warned that going with it

could have a serious impact on the performance of your device. So always

use debugging commands carefully, with an eye on the messages you

really need to meet your specific business requirements!

Configuring and Verifying Syslog

As I said, Cisco devices send all log messages of the severity level you’ve

chosen to the console. They’ll also go to the buffer, and both happen by

default. Because of this, it’s good to know that you can disable and enable

these features with the following commands:

Router(config)#

logging ?

Hostname or A.B.C.D IP address of the logging host

buffered Set buffered logging parameters

buginf Enable buginf logging for debugging

cns-events Set CNS Event logging level

console Set console logging parameters

count Count every log message and timestamp last

occurrence

esm Set ESM filter restrictions

exception Limit size of exception flush output

facility Facility parameter for syslog messages

filter Specify logging filter

history Configure syslog history table

host Set syslog server IP address and parameters

monitor Set terminal line (monitor) logging

parameters

on Enable logging to all enabled destinations

origin-id Add origin ID to syslog messages

queue-limit Set logger message queue size

rate-limit Set messages per second limit

reload Set reload logging level

server-arp Enable sending ARP requests for syslog

servers when

first configured

source-interface Specify interface for source address in

logging

transactions

trap Set syslog server logging level

userinfo Enable logging of user info on privileged

mode enabling

Router(config)#

logging console

Router(config)#

logging buffered

Wow—as you can see in this output, there are plenty of options you can

use with the

logging

command! The preceding configuration enabled the

console and buffer to receive all log messages of all severities, and don’t

forget that this is the default setting for all Cisco IOS devices. If you want

to disable the defaults, use the following commands:

Router(config)#

no logging console

Router(config)#

no logging buffered

I like leaving the console and buffer commands on in order to receive the

logging info, but that’s up to you. You can see the buffers with the

show

logging

command here:

Router#

sh logging

Syslog logging: enabled (11 messages dropped, 1 messages rate-

limited,

0 flushes, 0 overruns, xml disabled, filtering

disabled)

Console logging: level debugging, 29 messages logged, xml

disabled,

filtering disabled

Monitor logging: level debugging, 0 messages logged, xml

disabled,

filtering disabled

Buffer logging: level debugging, 1 messages logged, xml

disabled,

filtering disabled

Logging Exception size (4096 bytes)

Count and timestamp logging messages: disabled

No active filter modules.

Trap logging: level informational, 33 message lines logged

Log Buffer (4096 bytes):

*Jun 21 23:09:37.822: %SYS-5-CONFIG_I: Configured from console by

console

Router#

The default trap (message from device to NMS) level is

debugging

, but you

can change this too. And now that you’ve seen the system message format

on a Cisco device, I want to show you how you can also control the format

of your messages via sequence numbers and time stamps, which aren’t

enabled by default. We’ll begin with a basic, simple example of how to

configure a device to send messages to a syslog server, demonstrated in

Figure 7.4

.

FIGURE 7.4

Messages sent to a syslog server

A syslog server saves copies of console messages and can time-stamp

them for viewing at a later time. This is actually pretty easy to configure,

and here’s how doing that would look on the SF router:

SF(config)#

logging 172.16.10.1

SF(config)#

logging informational

This is awesome—now all the console messages will be stored in one

location to be viewed at your convenience! I typically use the

logging

host

ip_address

command, but

logging

IP_address

without the

host

keyword gets the same result.

We can limit the amount of messages sent to the syslog server, based on

severity, with the following command:

SF(config)#

logging trap ?

<0-7> Logging severity level

alerts Immediate action needed (severity=1)

critical Critical conditions (severity=2)

debugging Debugging messages (severity=7)

emergencies System is unusable (severity=0)

errors Error conditions (severity=3)

informational Informational messages (severity=6)

notifications Normal but significant conditions (severity=5)

warnings Warning conditions (severity=4)

SF(config)#

logging trap informational

Notice that we can use either the number or the actual severity level name

—and they are in alphabetical order, not severity order, which makes it

even harder to memorize the order! (Thanks, Cisco!) Since I went with

severity level 6 (Informational), I’ll receive messages for levels 0 through

6. These are referred to as local levels as well, such as, for example, local6

—no difference.

Now let’s configure the router to use sequence numbers:

SF(config)#

no service timestamps

SF(config)#

service sequence-numbers

SF(config)#

^Z

000038: %SYS-5-CONFIG_I: Configured from console by console

When you exit configuration mode, the router will send a message like

the one shown in the preceding code lines. Without the time stamps

enabled, we’ll no longer see a time and date, but we will see a sequence

number.

So we now have the following:

Sequence number: 000038

Facility: %SYS

Severity level: 5

MNEMONIC: CONFIG_I

Description: Configured from console by console

I want to stress that of all of these, the severity level is what you need to

pay attention to the most for the Cisco exams as well as for a means to

control the amount of messages sent to the syslog server.

Network Time Protocol (NTP)

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, as shown in

Figure

7.4

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

:

SF(config)#

ntp server 172.16.10.1 version 4

FIGURE 7.5

Synchronizing time information

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.

Exploring Connected Devices Using CDP and

LLDP

Cisco Discovery Protocol (CDP) is a proprietary Layer 2 protocol

designed by Cisco to help administrators collect information about locally

attached Cisco devices. Armed with CDP, you can gather hardware and

protocol information about neighbor devices, which is crucial

information to have when troubleshooting and documenting the network.

Another dynamic discovery protocol is Link Layer Discovery Protocol

(LLDP), but instead of being proprietary like CDP, it is vendor

independent.

Let’s start by exploring the CDP timer and CDP commands we’ll need to

verify our network.

Getting CDP Timers and Holdtime Information

The

show cdp

command (

sh cdp

for short) gives you information about

two CDP global parameters that can be configured on Cisco devices:

CDP timer delimits how often CDP packets are transmitted out all

active interfaces.

CDP holdtime delimits the amount of time that the device will hold

packets received from neighbor devices.

Both Cisco routers and switches use the same parameters. Check out

Figure 7.6

to see how CDP works within a switched network that I set up

for my switching labs in this book.

FIGURE 7.6

Cisco Discovery Protocol

The output on my 3560 SW-3 looks like this:

SW-3#

sh cdp

Global CDP information:

Sending CDP packets every 60 seconds

Sending a holdtime value of 180 seconds

Sending CDPv2 advertisements is enabled

This output tells us that the default transmits every 60 seconds and will

hold packets from a neighbor in the CDP table for 180 seconds. I can use

the global commands

cdp holdtime

and

cdp timer

to configure the CDP

holdtime and timer on a router if necessary like this:

SW-3(config)#

cdp ?

advertise-v2 CDP sends version-2 advertisements

holdtime Specify the holdtime (in sec) to be sent in packets

run Enable CDP

timer Specify the rate at which CDP packets are sent (in

sec)

tlv Enable exchange of specific tlv information

SW-3(config)#

cdp holdtime ?

<10-255> Length of time (in sec) that receiver must keep this

packet

SW-3(config)#

cdp timer ?

<5-254> Rate at which CDP packets are sent (in sec)

You can turn off CDP completely with the

no cdp run

command from

global configuration mode of a router and enable it with the

cdp run

command:

SW-3(config)#

no cdp run

SW-3(config)#

cdp run

To turn CDP off or on for an interface, use the

no cdp enable

and

cdp

enable

commands.

Gathering Neighbor Information

The

show cdp neighbor

command (

sh cdp nei

for short) delivers

information about directly connected devices. It’s important to remember

that CDP packets aren’t passed through a Cisco switch and that you only

see what’s directly attached. So this means that if your router is

connected to a switch, you won’t see any of the Cisco devices connected

beyond that switch!

The following output shows the

show cdp neighbor

command I used on

my SW-3:

SW-3#

sh cdp neighbors

Capability Codes: R - Router, T - Trans Bridge, B - Source Route

Bridge

S - Switch, H - Host, I - IGMP, r - Repeater, P -

Phone,

D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform

Port ID

SW-1 Fas 0/1 170 S I WS-C3560- Fas 0/15

SW-1 Fas 0/2 170 S I WS-C3560- Fas 0/16

SW-2 Fas 0/5 162 S I WS-C3560- Fas 0/5

SW-2 Fas 0/6 162 S I WS-C3560- Fas 0/6

Okay—we can see that I’m directly connected with a console cable to the

SW-3 switch and also that SW-3 is directly connected to two other

switches. However, do we really need the figure to draw out our network?

We don’t! CDP allows me to see who my directly connected neighbors are

and gather information about them. From the SW-3 switch, we can see

that there are two connections to SW-1 and two connections to SW-2.

SW-3 connects to SW-1 with ports Fas 0/1 and Fas 0/2, and we have

connections to SW-2 with local interfaces Fas 0/5 and Fas 0/6. Both the

SW-1 and SW-2 switches are 3650 switches, and SW-1 is using ports Fas

0/15 and Fas 0/16 to connect to SW-3. SW-2 is using ports Fas 0/5 and

Fas 0/6.

To sum this up, the device ID shows the configured hostname of the

connected device, that the local interface is our interface, and the port ID

is the remote devices’ directly connected interface. Remember that all you

get to view are directly connected devices!

Table 7.3

summarizes the information displayed by the

show cdp

neighbor

command for each device.