Senior Acquisitions Editor: Kenyon Brown Development Editor: Kim Wimpsett

TABLE 7.3

Output of the

show cdp neighbors

command

Field

Description

Device ID

The hostname of the device directly connected.

Local

Interface

The port or interface on which you are receiving the CDP

packet.

Holdtime

The remaining amount of time the router will hold the

information before discarding it if no more CDP packets are

received.

Capability

The capability of the neighbor—the router, switch, or

repeater. The capability codes are listed at the top of the

command output.

Platform

The type of Cisco device directly connected. In the previous

output, the SW-3 shows it’s directly connected to two 3560

switches.

Port ID

The neighbor device’s port or interface on which the CDP

packets are multicast.

It’s imperative that you can look at the output of a

show cdp

neighbors

command and decipher the information gained about the

neighbor device’s capability, whether it’s a router or switch, the model

number (platform), your port connecting to that device (local

interface), and the port of the neighbor connecting to you (port ID).

Another command that will deliver the goods on neighbor information is

the

show cdp neighbors detail

command (

show cdp nei de

for short).

This command can be run on both routers and switches, and it displays

detailed information about each device connected to the device you’re

running the command on. Check out the router output in Listing 7.1.

Listing 7.1:

Showing CDP neighbors

SW-3#

sh cdp neighbors detail

-------------------------

Device ID: SW-1

Entry address(es):

IP address: 10.100.128.10

Platform: cisco WS-C3560-24TS, Capabilities: Switch IGMP

Interface: FastEthernet0/1, Port ID (outgoing port):

FastEthernet0/15

Holdtime : 137 sec

Version :

Cisco IOS Software, C3560 Software (C3560-IPSERVICESK9-M), Version

12.2(55)SE7, RELEASE SOFTWARE (fc1)

Technical Support:

http://www.cisco.com/techsupport

Copyright (c) 1986-2013 by Cisco Systems, Inc.

Compiled Mon 28-Jan-13 10:10 by prod_rel_team

advertisement version: 2

Protocol Hello: OUI=0x00000C, Protocol ID=0x0112; payload len=27,

value=00000000FFFFFFFF010221FF000000000000001C575EC880Fc00f000

VTP Management Domain: 'NULL'

Native VLAN: 1

Duplex: full

Power Available TLV:

Power request id: 0, Power management id: 1, Power available:

0, Power management level: -1

Management address(es):

IP address: 10.100.128.10

-------------------------

[ouput cut]

-------------------------

Device ID: SW-2

Entry address(es):

IP address: 10.100.128.9

Platform: cisco WS-C3560-8PC, Capabilities: Switch IGMP

Interface: FastEthernet0/5, Port ID (outgoing port):

FastEthernet0/5

Holdtime : 129 sec

Version :

Cisco IOS Software, C3560 Software (C3560-IPBASE-M), Version

12.2(35)SE5, RELEASE SOFTWARE (fc1)

Copyright (c) 1986-2007 by Cisco Systems, Inc.

Compiled Thu 19-Jul-07 18:15 by nachen

advertisement version: 2

Protocol Hello: OUI=0x00000C, Protocol ID=0x0112; payload len=27,

value=00000000FFFFFFFF010221FF000000000000B41489D91880Fc00f000

VTP Management Domain: 'NULL'

Native VLAN: 1

Duplex: full

Power Available TLV:

Power request id: 0, Power management id: 1, Power available:

0, Power management level: -1

Management address(es):

IP address: 10.100.128.9

[output cut]

So what’s revealed here? First, we’ve been given the hostname and IP

address of all directly connected devices. And in addition to the same

information displayed by the

show cdp neighbors

command (see

Table

7.3

), the

show cdp neighbors detail

command tells us about the IOS

version and IP address of the neighbor device—that’s quite a bit!

The

show cdp entry *

command displays the same information as the

show cdp neighbors detail

command. There isn’t any difference between

these commands.

CDP Can Save Lives!

Karen has just been hired as a senior network consultant at a large

hospital in Dallas, Texas, so she’s expected to be able to take care of

any problem that rears its ugly head. As if that weren’t enough

pressure, she also has to worry about the horrid possibility that

people won’t receive correct health care solutions—even the correct

medications—if the network goes down. Talk about a potential life-or-

death situation!

But Karen is confident and begins her job optimistically. Of course,

it’s not long before the network reveals that it has a few problems.

Unfazed, she asks one of the junior administrators for a network map

so she can troubleshoot the network. This person tells her that the old

senior administrator, who she replaced, had them with him and now

no one can find them. The sky begins to darken!

Doctors are calling every couple of minutes because they can’t get the

necessary information they need to take care of their patients. What

should she do?

It’s CDP to the rescue! And it’s a gift that this hospital happens to be

running Cisco ​routers and switches exclusively, because CDP is

enabled by default on all Cisco devices. Karen is also in luck because

the disgruntled former administrator didn’t turn off CDP on any

devices before he left!

So all Karen has to do now is to use the

show cdp neighbor detail

command to find all the information she needs about each device to

help draw out the hospital network, bringing it back up to speed so

the personnel who rely upon it can get on to the important business of

saving lives!

The only snag for you nailing this in your own network is if you don’t

know the passwords of all those devices. Your only hope then is to

somehow find out the access passwords or to perform password

recovery on them.

So, use CDP—you never know when you may end up saving

someone’s life.

By the way, this is a true story!

Documenting a Network Topology Using CDP

With that moving real-life scenario in mind, I’m now going to show you

how to document a sample network by using CDP. You’ll learn to

determine the appropriate router types, interface types, and IP addresses

of various interfaces using only CDP commands and the

show running-

config

command. And you can only console into the Lab_A router to

document the network. You’ll have to assign any remote routers the next

IP address in each range. We’ll use a different figure for this example

—

Figure 7.7

— to help us to complete the necessary documentation.

FIGURE 7.7

Documenting a network topology using CDP

In this output, you can see that you have a router with four interfaces:

two Fast Ethernet and two serial. First, determine the IP addresses of

each interface by using the

show

​

running-config

command like this:

Lab_A#

sh running-config

Building configuration...

Current configuration : 960 bytes

!

version 12.2

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname Lab_A

!

ip subnet-zero

!

!

interface FastEthernet0/0

ip address 192.168.21.1 255.255.255.0

duplex auto

!

interface FastEthernet0/1

ip address 192.168.18.1 255.255.255.0

duplex auto

!

interface Serial0/0

ip address 192.168.23.1 255.255.255.0

!

interface Serial0/1

ip address 192.168.28.1 255.255.255.0

!

ip classless

!

line con 0

line aux 0

line vty 0 4

!

end

With this step completed, you can now write down the IP addresses of the

Lab_A router’s four interfaces. Next, you must determine the type of

device on the other end of each of these interfaces. It’s easy—just use the

show cdp neighbors

command:

Lab_A#

sh cdp neighbors

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

Bridge

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

Device ID Local Intrfce Holdtme Capability Platform Port

ID

Lab_B Fas 0/0 178 R 2501 E0

Lab_C Fas 0/1 137 R 2621

Fa0/0

Lab_D Ser 0/0 178 R 2514 S1

Lab_E Ser 0/1 137 R 2620 S0/1

Wow—looks like we’re connected to some old routers! But it’s not our job

to judge. Our mission is to draw out our network, so it’s good that we’ve

got some nice information to meet the challenge with now. By using both

the

show running-config

and

show cdp neighbors

commands, we know

about all the IP addresses of the Lab_A router, the types of routers

connected to each of the Lab_A router’s links, and all the interfaces of the

remote routers.

Now that we’re equipped with all the information gathered via

show

running-config

and

show cdp neighbors

, we can accurately create the

topology in

Figure 7.8

.

FIGURE 7.8

Network topology documented

If we needed to, we could’ve also used the

show cdp neighbors detail

command to view the neighbor’s IP addresses. But since we know the IP

addresses of each link on the Lab_A router, we already know what the

next available IP address is going to be.

Link Layer Discovery Protocol (LLDP)

Before moving on from CDP, I want to tell you about a nonproprietary

discovery protocol that provides pretty much the same information as

CDP but works in multi-vendor networks.

The IEEE created a new standardized discovery protocol called 802.1AB

for Station and Media Access Control Connectivity Discovery. We’ll just

call it Link Layer Discovery Protocol (LLDP).

LLDP defines basic discovery capabilities, but it was also enhanced to

specifically address the voice application, and this version is called LLDP-

MED (Media Endpoint Discovery). It’s good to remember that LLDP and

LLDP-MED are not compatible.

LLDP has the following configuration guidelines and limitations:

LLDP must be enabled on the device before you can enable or disable

it on any ​interface.

LLDP is supported only on physical interfaces.

LLDP can discover up to one device per port.

LLDP can discover Linux servers.

You can turn off LLDP completely with the

no lldp run

command from

global configuration mode of a device and enable it with the

lldp run

command, which enables it on all interfaces as well:

SW-3(config)#

no lldp run

SW-3(config)#

lldp run

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

lldp transmit

and

lldp

receive

commands.

SW-3(config-if)#

no lldp transmit

SW-3(config-if)#

no lldp receive

SW-3(config-if)#

lldp transmit

SW-3(config-if)#

lldp receive

Using Telnet

As part of the TCP/IP protocol suite, Telnet is a virtual terminal protocol

that allows you to make connections to remote devices, gather

information, and run programs.

After your routers and switches are configured, you can use the Telnet

program to reconfigure and/or check up on them without using a console

cable. You run the Telnet program by typing

telnet

from any command

prompt (Windows or Cisco), but you need to have VTY passwords set on

the IOS devices for this to work.

Remember, you can’t use CDP to gather information about routers and

switches that aren’t directly connected to your device. But you can use the

Telnet application to connect to your neighbor devices and then run CDP

on those remote devices to get information on them.

You can issue the

telnet

command from any router or switch prompt. In

the following code, I’m trying to telnet from switch 1 to switch 3:

SW-1#

telnet 10.100.128.8

Trying 10.100.128.8 ... Open

Password required, but none set

[Connection to 10.100.128.8 closed by foreign host]

Oops—clearly, I didn’t set my passwords—how embarrassing! Remember

that the VTY ports are default configured as

login

, meaning that we have

to either set the VTY passwords or use the

no login

command. If you

need to review the process of setting ​passwords, take a quick look back in

Chapter 6, “Cisco’s Internetworking Operating System (IOS).”

If you can’t telnet into a device, it could be that the password

on the remote device hasn’t been set. It’s also quite possible that an

access control list is filtering the Telnet session.

On a Cisco device, you don’t need to use the

telnet

command; you can

just type in an IP address from a command prompt and the router will

assume that you want to telnet to the device. Here’s how that looks using

just the IP address:

SW-1#

10.100.128.8

Trying 10.100.128.8... Open

Password required, but none set

[Connection to 10.100.128.8 closed by foreign host]

SW-1#

Now would be a great time to set those VTY passwords on the SW-3 that I

want to telnet into. Here’s what I did on the switch named SW-3:

SW-3(config)#

line vty 0 15

SW-3(config-line)#

login

SW-3(config-line)#

password telnet

SW-3(config-line)#

login

SW-3(config-line)#

^Z

Now let’s try this again. This time, I’m connecting to SW-3 from the SW-1

console:

SW-1#

10.100.128.8

Trying 10.100.128.8 ... Open

User Access Verification

Password:

SW-3>

Remember that the VTY password is the user-mode password, not the

enable-mode password. Watch what happens when I try to go into

privileged mode after telnetting into the switch:

SW-3>

en

% No password set

SW-3>

It’s totally slamming the door in my face, which happens to be a really

nice security feature! After all, you don’t want just anyone telnetting into

your device and typing the

enable

command to get into privileged mode

now, do you? You’ve got to set your enable-mode password or enable

secret password to use Telnet to configure remote devices.

When you telnet into a remote device, you won’t see console

messages by default. For example, you will not see debugging output.

To allow console messages to be sent to your Telnet session, use the

terminal monitor

command.

Using the next group of examples, I’ll show you how to telnet into

multiple devices simultaneously as well as how to use hostnames instead

of IP addresses.

Telnetting into Multiple Devices Simultaneously

If you telnet to a router or switch, you can end the connection by typing

exit

at any time. But what if you want to keep your connection to a

remote device going while still coming back to your original router

console? To do that, you can press the Ctrl+Shift+6 key combination,

release it, and then press X.

Here’s an example of connecting to multiple devices from my SW-1

console:

SW-1#

10.100.128.8

Trying 10.100.128.8... Open

User Access Verification

Password:

SW-3>

Ctrl+Shift+6

SW-1#

Here you can see that I telnetted to SW-1 and then typed the password to

enter user mode. Next, I pressed Ctrl+Shift+6, then X, but you won’t see

any of that because it doesn’t show on the screen output. Notice that my

command prompt now has me back at the SW-1 switch.

Now let’s run through some verification commands.

Checking Telnet Connections

If you want to view the connections from your router or switch to a

remote device, just use the

show sessions

command. In this case, I’ve

telnetted into both the SW-3 and SW-2 switches from SW1:

SW-1#

sh sessions

Conn Host Address Byte Idle Conn Name

1 10.100.128.9 10.100.128.9 0 10.100.128.9

* 2 10.100.128.8 10.100.128.8 0 10.100.128.8

SW-1#

See that asterisk (

*

) next to connection 2? It means that session 2 was the

last session I connected to. You can return to your last session by pressing

Enter twice. You can also return to any session by typing the number of

the connection and then Enter.

Checking Telnet Users

You can reveal all active consoles and VTY ports in use on your router

with the

show users

command:

SW-1#

sh users

Line User Host(s) Idle Location

* 0 con 0 10.100.128.9 00:00:01

10.100.128.8 00:01:06

In the command’s output,

con

represents the local console, and we can

see that the console session is connected to two remote IP addresses—in

other words, two devices.

Closing Telnet Sessions

You can end Telnet sessions a few different ways. Typing

exit

or

disconnect

are probably the two quickest and easiest.

To end a session from a remote device, use the

exit

command:

SW-3>

exit

[Connection to 10.100.128.8 closed by foreign host]

SW-1#

To end a session from a local device, use the

disconnect

command:

SW-1#

sh session

Conn Host Address Byte Idle Conn Name

*2 10.100.128.9 10.100.128.9 0 10.100.128.9

SW-1#

disconnect ?

<2-2> The number of an active network connection

qdm Disconnect QDM web-based clients

ssh Disconnect an active SSH connection

SW-1#

disconnect 2

Closing connection to 10.100.128.9 [confirm]

[enter]

In this example, I used session number 2 because that was the connection

I wanted to conclude. As demonstrated, you can use the

show sessions

command to see the connection number.

Resolving Hostnames

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

The

show hosts

command provides information on temporary

DNS entries and permanent name-to-address mappings created using

the

ip host

command.

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>