The Router and Switch Boot Sequence

When a Cisco device boots up, it performs a series of steps, called the boot sequence, to test the hardware and load the necessary software. The boot sequence comprises the following steps, as shown in Figure 7.1:

1. The IOS device performs a POST, which tests the hardware to verify that all components of the device are present and operational. The post takes stock of the different interfaces on the switch or router, and it’s stored in and runs from read-only memory (ROM).
2. The bootstrap in ROM then locates and loads the Cisco IOS software by executing programs responsible for finding where each IOS program is located. Once they are found, it then loads the proper files. By default, the IOS software is loaded from flash memory in all Cisco devices.
3. The IOS software then looks for a valid configuration file stored in NVRAM. This file is called startup-config and will be present only if an administrator has copied the running-config file into NVRAM.
4. If a startup-config file is found in NVRAM, the router or switch will copy it, place it in RAM, and name the file the running-config. The device will use this file to run, and the router/switch should now be operational. If a startup-config file is not in NVRAM, the router will broadcast out any interface that detects carrier detect (CD) for a TFTP host looking for a configuration, and when that fails (typically it will fail—most people won’t even realize the router has attempted this process), it will start the setup mode configuration process.

Backing Up the Cisco Configuration

To copy the configuration from an IOS device to a TFTP server, you can use either the copy running-config tftp or the copy startup-config tftp command. Either one will back up the router configuration that’s currently running in DRAM or one that’s stored in NVRAM.

Router#show running-config
Building configuration...
 
Current configuration : 855 bytes
!
version 15.0

Router#sh start
Using 855 out of 524288 bytes
!
! Last configuration change at 04:49:14 UTC Fri Mar 5 1993
!
version 15.0

Router#copy running-config startup-config
Destination filename [startup-config]?[enter]
Building configuration...
[OK]

Router#copy running-config ?
  flash:          Copy to flash: file system
  ftp:            Copy to ftp: file system
  http:           Copy to http: file system
  https:          Copy to https: file system
  null:           Copy to null: file system
  nvram:          Copy to nvram: file system
  rcp:            Copy to rcp: file system
  running-config  Update (merge with) current system configuration
  scp:            Copy to scp: file system
  startup-config  Copy to startup configuration
  syslog:         Copy to syslog: file system
  system:         Copy to system: file system
  tftp:           Copy to tftp: file system
  tmpsys:         Copy to tmpsys: file system

Todd#copy running-config tftp
Address or name of remote host []? 10.10.10.254
Destination filename [todd-confg]?
!!
776 bytes copied in 0.800 secs (970 bytes/sec)

Restoring the Cisco Configuration

What do you do if you’ve changed your running-config file and want to restore the configuration to the version in the startup-config file? The easiest way to get this done is to use the copy startup-config running-config command, or copy start run for short, but this will work only if you copied running-config into NVRAM before you made any changes! Of course, a reload of the device will work too!

If you did copy the configuration to a TFTP server as a second backup, you can restore the configuration using the copy tftp running-config command (copy tftp run for short), or the copy tftp startup-config command (copy tftp start for short), as shown in the following output. Just so you know, the old command we used to use for this is config net:

Todd#copy tftp running-config
Address or name of remote host []?10.10.10.254
Source filename []?todd-confg
Destination filename[running-config]?[enter]
Accessing tftp://10.10.10.254/todd-confg...
Loading todd-confg from 10.10.10.254 (via FastEthernet0/0):
!!
[OK - 776 bytes]
776 bytes copied in 9.212 secs (84 bytes/sec)
Todd#
*Mar  7 17:53:34.071: %SYS-5-CONFIG_I: Configured from
    tftp://10.10.10.254/todd-confg by console

Okay that the configuration file is an ASCII text file . . . meaning that before you copy the configuration stored on a TFTP server back to a router, you can make changes to the file with any text editor.

Erasing the Configuration

To delete the startup-config file on a Cisco router or switch, use the command erase startup-config, like this:

Todd#erase startup-config
Erasing the nvram filesystem will remove all configuration files!
    Continue? [confirm][enter]
[OK]
Erase of nvram: complete
*Mar  7 17:56:20.407: %SYS-7-NV_BLOCK_INIT: Initialized the geometry of nvram
Todd#reload
System configuration has been modified. Save? [yes/no]:n
Proceed with reload? [confirm][enter]
 *Mar  7 17:56:31.059: %SYS-5-RELOAD: Reload requested by console.
    Reload Reason: Reload Command.

This command deletes the contents of NVRAM on the switch and router. If you type reload while in privileged mode and say no to saving changes, the switch or router will reload and come up into setup mode.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

SW-3(config)#no lldp run
SW-3(config)#lldp run

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

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.

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.

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 need to 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

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, I would have needed to type in ping sw-3.lammle.com, which is kind of a hassle.

Using the ping Command

So far, you’ve seen lots of examples of pinging devices to test IP connectivity and name resolution using the DNS server. To see all the different protocols that you can use with the Ping program, type ping ?:

SW-1#ping ?
  WORD  Ping destination address or hostname
  clns  CLNS echo
  ip    IP echo
  ipv6  IPv6 echo
  tag   Tag encapsulated IP echo
  <cr>

The ping output displays the minimum, average, and maximum times it takes for a ping packet to find a specified system and return. Here’s an example:

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

This output tells us that the DNS server was used to resolve the name, and the device was pinged in a minimum of 28 ms (milliseconds), an average of 31 ms, and up to 32 ms. This network has some latency!

Using the traceroute Command

Traceroute—the traceroute command, or trace for short—shows the path a packet takes to get to a remote device. It uses time to live (TTL), time-outs, and ICMP error messages to outline the path a packet takes through an internetwork to arrive at a remote host.

The trace command, which you can deploy from either user mode or privileged mode, allows you to figure out which router in the path to an unreachable network host should be examined more closely as the probable cause of your network’s failure.

To see the protocols that you can use with the traceroute command, type traceroute ?:

SW-1#traceroute ?
  WORD       Trace route to destination address or hostname
  appletalk  AppleTalk Trace
  clns       ISO CLNS Trace
  ip         IP Trace
  ipv6       IPv6 Trace
  ipx        IPX Trace
  mac        Trace Layer2 path between 2 endpoints
  oldvines   Vines Trace (Cisco)
  vines      Vines Trace (Banyan)
  <cr>

The traceroute command shows the hop or hops that a packet traverses on its way to a remote device.

Here’s an example of using tracert on a Windows prompt—notice that the command is tracert, not traceroute:

C:>tracert www.whitehouse.gov
 
Tracing route to a1289.g.akamai.net [69.8.201.107]
over a maximum of 30 hops:
 
  1     *        *        *     Request timed out.
  2    53 ms    61 ms    53 ms  hlrn-dsl-gw15-207.hlrn.qwest.net [207.225.112.207]
  3    53 ms    55 ms    54 ms  hlrn-agw1.inet.qwest.net [71.217.188.113]
  4    54 ms    53 ms    54 ms  hlr-core-01.inet.qwest.net [205.171.253.97]
  5    54 ms    53 ms    54 ms  apa-cntr-01.inet.qwest.net [205.171.253.26]
  6    54 ms    53 ms    53 ms  63.150.160.34
  7    54 ms    54 ms    53 ms  www.whitehouse.gov [69.8.201.107]
 
Trace complete.

Okay, let’s move on now and talk about how to troubleshoot your network using the debug command.

Debugging

Debug is a useful troubleshooting command that’s available from the privileged exec mode of Cisco IOS. It’s used to display information about various router operations and the related traffic generated or received by the router, plus any error messages.

Even though it’s a helpful, informative tool, there are a few important facts that you need to know about it. Debug is regarded as a very high-overhead task because it can consume a huge amount of resources and the router is forced to process-switch the packets being debugged. So you don’t just use debug as a monitoring tool—it’s meant to be used for a short period of time and only as a troubleshooting tool. It’s highly useful for discovering some truly significant facts about both working and faulty software and/or hardware components, but remember to limit its use as the beneficial troubleshooting tool it’s designed to be.

Because debugging output takes priority over other network traffic, and because the debug all command generates more output than any other debug command, it can severely diminish the router’s performance—even render it unusable! Because of this, it’s nearly always best to use more specific debug commands.

As you can see from the following output, you can’t enable debugging from user mode, only privileged mode:

SW-1>debug ?
% Unrecognized command
SW-1>en
SW-1#debug ?
  aaa                   AAA Authentication, Authorization and Accounting
  access-expression     Boolean access expression
  adjacency             adjacency
  aim                   Attachment Information Manager
  all                   Enable all debugging
  archive               debug archive commands
  arp                   IP ARP and HP Probe transactions
  authentication        Auth Manager debugging
  auto                  Debug Automation
  beep                  BEEP debugging
  bgp                   BGP information
  bing                  Bing(d) debugging
  call-admission        Call admission control
  cca                   CCA activity
  cdp                   CDP information
  cef                   CEF address family independent operations
  cfgdiff               debug cfgdiff commands
  cisp                  CISP debugging
  clns                  CLNS information
  cluster               Cluster information
  cmdhd                 Command Handler
  cns                   CNS agents
  condition             Condition
  configuration         Debug Configuration behavior
[output cut]

If you’ve got the freedom to pretty much take out a router or switch and you really want to have some fun with debugging, use the debug all command:

Sw-1#debug all

This may severely impact network performance. Continue? (yes/[no]):yes
All possible debugging has been turned on

At this point my switch overloaded and crashed and I had to reboot it. Try this on your switch at work and see if you get the same results. Just kidding!

To disable debugging on a router, just use the command no in front of the debug command:

SW-1#no debug all

I typically just use the undebug all command since it is so easy when using the shortcut:

SW-1#un all

Remember that instead of using the debug all command, it’s usually a much better idea to use specific commands—and only for short periods of time. Here’s an example:

S1#debug ip icmp
ICMP packet debugging is on
S1#ping 192.168.10.17

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.17, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
S1#
1w4d: ICMP: echo reply sent, src 192.168.10.17, dst 192.168.10.17
1w4d: ICMP: echo reply rcvd, src 192.168.10.17, dst 192.168.10.17
1w4d: ICMP: echo reply sent, src 192.168.10.17, dst 192.168.10.17
1w4d: ICMP: echo reply rcvd, src 192.168.10.17, dst 192.168.10.17
1w4d: ICMP: echo reply sent, src 192.168.10.17, dst 192.168.10.17
1w4d: ICMP: echo reply rcvd, src 192.168.10.17, dst 192.168.10.17
1w4d: ICMP: echo reply sent, src 192.168.10.17, dst 192.168.10.17
1w4d: ICMP: echo reply rcvd, src 192.168.10.17, dst 192.168.10.17
1w4d: ICMP: echo reply sent, src 192.168.10.17, dst 192.168.10.17
1w4d: ICMP: echo reply rcvd, src 192.168.10.17, dst 192.168.10.17
SW-1#un all

I’m sure you can see that the debug command is one powerful command. And because of this, I’m also sure you realize that before you use any of the debugging commands, you should make sure you check the CPU utilization capacity of your router. This is important because in most cases, you don’t want to negatively impact the device’s ability to process the packets on your internetwork. You can determine a specific router’s CPU utilization information by using the show processes command.

Using the show processes Command

As I’ve said, you’ve really got to be careful when using the debug command on your devices. If your router’s CPU utilization is consistently at 50 percent or more, it’s probably not a good idea to type in the debug all command unless you want to see what a router looks like when it crashes!

So what other approaches can you use? Well, the show processes (or show processes cpu) is a good tool for determining a given router’s CPU utilization. Plus, it’ll give you a list of active processes along with their corresponding process ID, priority, scheduler test (status), CPU time used, number of times invoked, and so on. Lots of great stuff! Plus, this command is super handy when you want to evaluate your router’s performance and CPU utilization and are otherwise tempted to reach for the debug command!

Okay—what do you see in the following output? The first line shows the CPU utilization output for the last 5 seconds, 1 minute, and 5 minutes. The output provides 5%/0% in front of the CPU utilization for the last 5 seconds: The first number equals the total utilization, and the second one indicates the utilization due to interrupt routines. Take a look:

SW-1#sh processes
CPU utilization for five seconds: 5%/0%; one minute: 7%; five minutes: 8%
 PID QTy       PC Runtime(ms)   Invoked   uSecs    Stacks   TTY Process
   1 Cwe  29EBC58      0        22       0  5236/6000    0 Chunk Manager
   2 Csp  1B9CF10    241    206881       1  2516/3000    0 Load Meter
   3 Hwe  1F108D0      0         1       0  8768/9000    0 Connection Mgr
   4 Lst  29FA5C4 9437909    454026   20787  5540/6000   0 Check heaps
   5 Cwe  2A02468      0         2       0  5476/6000    0 Pool Manager
   6 Mst  1E98F04      0         2       0  5488/6000    0 Timers
   7 Hwe  13EB1B4   3686    101399      36  5740/6000    0 Net Input
   8 Mwe  13BCD84      0         1       0 23668/24000   0 Crash writer
   9 Mwe  1C591B4   4346     53691      80  4896/6000    0 ARP Input
  10 Lwe  1DA1504      0         1       0  5760/6000    0 CEF MIB API
  11 Lwe  1E76ACC      0         1       0  5764/6000    0 AAA_SERVER_DEADT
  12 Mwe  1E6F980      0         2       0  5476/6000    0 AAA high-capacit
  13 Mwe  1F56F24      0         1       0 11732/12000   0 Policy Manager [output cut]

So basically, the output from the show processes command reveals that our router is happily able to process debugging commands without being overloaded—nice!

Written Lab 7.1: IOS Management

Write the answers to the following questions:

1. What is the command to copy the startup-config file to DRAM?
2. What command can you use to see the neighbor router’s IP address from your router prompt?
3. What command can you use to see the hostname, local interface, platform, and remote port of a neighbor router?
4. What keystrokes can you use to telnet into multiple devices simultaneously?
5. What command will show you your active Telnet connections to neighbor and remote devices?
6. What command can you use to merge a backup configuration with the configuration in RAM?
7. What protocol can be used on a network to synchronize clock and date information?
8. What command is used by a router to forward a DHCP client request to a remote DHCP server?
9. What command enables your switch or router to receive clock and date information and synchronize with the NTP server?
10. Which NTP verification command will show the reference master for the client?

Written Lab 7.2: Router Memory

Identify the location in a router where each of the following files is stored by default.

1. Cisco IOS
2. Bootstrap
3. Startup configuration
4. POST routine
5. Running configuration
6. ARP cache
7. Mini-IOS
8. ROM Monitor
9. Routing tables
10. Packet buffers

Hands-on Lab 7.1: Backing Up the Router Configuration

In this lab, you’ll back up the router configuration:

1. Log into your router and go into privileged mode by typing en or enable.
2. Ping the TFTP server to make sure you have IP connectivity.
3. From RouterB, type copy run tftp.
4. When prompted, type the IP address of the TFTP server (for example, 172.16.30.2) and press Enter.

5. By default, the router will prompt you for a filename. The hostname of the router is followed by the suffix -confg (yes, I spelled that correctly). You can use any name you want.

   Name of configuration file to write [RouterB-confg]?

   Press Enter to accept the default name.

   Write file RouterB-confg on host 172.16.30.2? [confirm]

   Press Enter to confirm.

Hands-on Lab 7.2: Using the Cisco Discovery Protocol (CDP)

CDP is an important objective for the Cisco exams. Please go through this lab and use CDP as much as possible during your studies.

1. Log into your router and go into privileged mode by typing en or enable.
2. From the router, type sh cdp and press Enter. You should see that CDP packets are being sent out to all active interfaces every 60 seconds and the holdtime is 180 seconds (these are the defaults).

3. To change the CDP update frequency to 90 seconds, type cdp timer 90 in global configuration mode.

   Router#config t
   Enter configuration commands, one per line.  End with
     CNTL/Z.
   Router(config)#cdp timer ?
     <5-900>  Rate at which CDP packets are sent (in sec)
   Router(config)#cdp timer 90

4. Verify that your CDP timer frequency has changed by using the command show cdp in privileged mode.

   Router#sh cdp
   Global CDP information:
   Sending CDP packets every 90 seconds
   Sending a holdtime value of 180 seconds

5. Now use CDP to gather information about neighbor routers. You can get the list of available commands by typing sh cdp ?.

   Router#sh cdp ?
     entry     Information for specific neighbor entry
     interface CDP interface status and configuration
     neighbors CDP neighbor entries
     traffic   CDP statistics
     <cr>

6. Type sh cdp int to see the interface information plus the default encapsulation used by the interface. It also shows the CDP timer information.
7. Type sh cdp entry * to see complete CDP information received from all devices.
8. Type show cdp neighbors to gather information about all connected neighbors. (You should know the specific information output by this command.)
9. Type show cdp neighbors detail. Notice that it produces the same output as show cdp entry *.

Hands-on Lab 7.3: Using Telnet

Secure Shell was covered in Chapter 6, and it is what you should use for remote access into a Cisco device. However, the Cisco objectives cover Telnet configuration, so let’s do a lab on Telnet!

1. Log into your router and go into privileged mode by typing en or enable.
2. From RouterA, telnet into your remote router (RouterB) by typing telnet ip_address from the command prompt. Type exit to disconnect.
3. Now type in RouterB’s IP address from RouterA’s command prompt. Notice that the router automatically tries to telnet to the IP address you specified. You can use the telnet command or just type in the IP address.
4. From RouterB, press Ctrl+Shift+6 and then X to return to RouterA’s command prompt. Now telnet into your third router, RouterC. Press Ctrl+Shift+6 and then X to return to RouterA.
5. From RouterA, type show sessions. Notice your two sessions. You can press the number displayed to the left of the session and press Enter twice to return to that session. The asterisk shows the default session. You can press Enter twice to return to that session.
6. Go to the session for your RouterB. Type show users. This shows the console connection and the remote connection. You can use the disconnect command to clear the session or just type exit from the prompt to close your session with RouterB.
7. Go to RouterC’s console port by typing show sessions on the first router and using the connection number to return to RouterC. Type show user and notice the connection to your first router, RouterA.
8. Type clear line line_number to disconnect the Telnet session.

Hands-on Lab 7.4: Resolving Hostnames

It’s best to use a DNS server for name resolution, but you can also create a local hosts table to resolve names. Let’s take a look.

1. Log into your router and go into privileged mode by typing en or enable.
2. From RouterA, type todd and press Enter at the command prompt. Notice the error you receive and the delay. The router is trying to resolve the hostname to an IP address by looking for a DNS server. You can turn this feature off by using the no ip domain-lookup command from global configuration mode.

3. To build a host table, you use the ip host command. From RouterA, add a host table entry for RouterB and RouterC by entering the following commands:

   ip host routerb ip_address
   ip host routerc ip_address

   Here is an example:

   ip host routerb 172.16.20.2
   ip host routerc 172.16.40.2

4. Test your host table by typing ping routerb from the privileged mode prompt (not the config prompt).

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

5. Test your host table by typing ping routerc.

   RouterA#ping routerc
   Type escape sequence to abort.
   Sending 5, 100-byte ICMP Echos to 172.16.40.2, timeout
     is 2 seconds:
   !!!!!
   Success rate is 100 percent (5/5), round-trip
     min/avg/max = 4/6/8 ms

6. Telnet to RouterB and keep your session to RouterB open to RouterA by pressing Ctrl+Shift+6, then X.
7. Telnet to RouterC by typing routerc at the command prompt.
8. Return to RouterA and keep the session to RouterC open by pressing Ctrl+Shift+6, then X.

9. View the host table by typing show hosts and pressing Enter.

   Default domain is not set
   Name/address lookup uses domain service
   Name servers are 255.255.255.255
   Host                 Flags      Age Type   Address(es)
   routerb             (perm, OK)  0   IP    172.16.20.2
   routerc             (perm, OK)  0   IP    172.16.40.2