Chapter: | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
Cisco IOS Essentials
John Albritton, CCIE
 $55.00  0-07-134743-7
Backward Forward

Reserve your copy at a
Bet@ Bookstore near you!
Contact Bet@ Books
© 1999 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Bet@ Book(TM) is subject to the rules stated in the Terms of Use.

Chapter 5

  1. Examining IOS

Network engineers and administrators do more looking around than configuring on an IOS-based router. We are going to cover some of the things that are useful to look at on a new router and some of the things that are useful to look at regularly on a production router. Some of the things we need to know about a router are as follows:

All of these items can be found by using one of the most used commands in the IOS, the show command. The show command is used to look at IOS stuff, and it can be issued in either user mode or privileged mode. The output of each show command used in this chapter is accompanied by a brief description of its contents. From user mode, we can look at just about anything on the router except the configuration files.

The IOS examination in the chapter will, for the most part, be independent of the routed and routing protocols. The examination of protocol dependent details will be covered in the protocol configuration chapters.

    1. General Router Information

The user mode command show version gives us information about the general configuration of the router. Figure 5-1 has the output generated by the show version command on our test 2520 router Dallas.

    1. Dallas>show version
    2. Cisco Internetwork Operating System Software
    3. IOS (tm) 2500 Software (C2500-JS-L), Version 11.3(5), RELEASE SOFTWARE (fc1)
    4. Copyright (c) 1986-1998 by cisco Systems, Inc.
    5. Compiled Tue 11-Aug-98 04:06 by phanguye
    6. Image text-base: 0x030489A8, data-base: 0x00001000
    7. ROM: System Bootstrap, Version 11.0(10c), SOFTWARE
    8. BOOTFLASH: 3000 Bootstrap Software (IGS-BOOT-R), Version 11.0(10c), RELEASE SOFTWARE (fc1)
    9. Dallas uptime is 4 hours, 18 minutes
    10. System restarted by reload
    11. System image file is "flash:c2500-js-l.113-5", booted via flash
    12. cisco 2520 (68030) processor (revision M) with 6144K/2048K bytes of memory.
    13. Processor board ID 10353405, with hardware revision 00000003
    14. Bridging software.
    15. X.25 software, Version 3.0.0.
    16. SuperLAT software copyright 1990 by Meridian Technology Corp).
    17. TN3270 Emulation software.
    18. Basic Rate ISDN software, Version 1.0.
    19. 1 Ethernet/IEEE 802.3 interface(s)
    20. 2 Serial network interface(s)
    21. 2 Low-speed serial(sync/async) network interface(s)
    22. 1 ISDN Basic Rate interface(s)
    23. 32K bytes of non-volatile configuration memory.
    24. 16384K bytes of processor board System flash (Read ONLY)
    25. Configuration register is 0x2102
    26. Dallas>

<<<Figure 5-1 Show Version Output on 2520>>>

You should output similar to this from Section 3.4.2. IOS sends this type of system information out the console port when a router boots. On Line 3, there is the router’s IOS version, 11.3(5). On Line 5, we see who compiled the image and when; this may not be of immediate interest to you, but is may be of interest to the Cisco Technical Assistance Center (TAC) if you ever have a very weird problem. Lines 8 and 9 show the bootstrap software version, 11.0(10c), stored in both ROM and boot flash.

Figure 5-1, Lines 11 through 13, tells us the router was booted 4 hours 18 minutes ago because someone issued the privileged mode command reload. At that time, the IOS image named c2500-js-l.113-5 was loaded from system flash.

((Mention the other possible things other than reload (power-on, crash). Show time from last boot.)

Knowing when a router last booted and what initiated the boot is important. If the router had been power cycled, Line 12 would have looked like this.

System restarted by power-on

If the router had crashed (It happens.), Line 12 would have looked something like this.

System restarted by bus error at PC 0x384B3DE, address 0xD0D0D0D

Line 15 shows that the router is a 2520, and it has 8 MB of RAM. The 8 MB is the sum of the valued 6144 KB and 2048 KB. On a 2500-series router, the RAM is divided into system RAM, for IOS system functions and tables, and shared RAM, for Input/Output (I/O) operations.

Figure 5-1, Lines 22 through 27, tell us about the physical configuration of the router. Lines 22 through 25 show what interfaces are in the router. The 32 KB of non-volatile configuration memory mentioned on Line 26 is the amount of NVRAM; so the router has 32 KB of memory to hold its startup configuration. Line 27 says that there is 16 MB of system flash, and we cannot currently write to it. System flash is normally read-only on a 2500-series router that booted from flash because IOS stays in flash while it runs as opposed to getting completely loaded into RAM to run.

The last line of the show version command output (Figure 5-1, Line 31) contains the value of the configuration register. The value is hexadecimal (hex) 2102. The configuration register has many purposes including controlling how the router boots and setting the console port baud rate. Hex 2102 is the default value for a 2500-series router.

The general information displayed by the show version command is consistent from one router model to another; however, the specific information varies. With this one command, we get plenty of good information about the router’s hardware and software.

    1. Input/Output Devices
    2. There are many input/output devices on Cisco routers. Some of those that we can control and configure are flash, controllers, interfaces, and terminal lines. This section covers the basic commands to check these devices.

      1. Flash

We can check the contents of flash memory with the user mode command show flash. Figure 5-2 shows the output of the show flash command on our test router Dallas.

    1. Dallas>show flash
    2. System flash directory:
    3. File Length Name/status
    4. 1 8945732 c2500-js-l.113-5
    5. [8945796 bytes used, 7831420 available, 16777216 total]
    6. 16384K bytes of processor board System flash (Read ONLY)
    7. Dallas>
    8. <<<Figure 5-2 Show Flash Output on 2520>>>

      The show flash command displays a directory of the contents of flash memory. On the 2500-series routers, flash is in SIMM form inside the router. On Line 5, we see that there is one file in Dallas’ flash; this an IOS image, and it is the same image that Dallas is running. The image is 8,945,732 bytes in length. Since there are 16 MB of RAM, this leaves 7,831,420 bytes available (Line 6).

      On the 7x00-series routers (7000, 7200, 7500), flash memory can either be imbedded internally as a SIMM or installed externally as PCMCIA cards. Normally these routers have two slots for PCMCIA flash cards; the slots are numbered 0 and 1. The show flash command works, but to see contents of individual flash devices, we should use the user mode command dir (short for directory). Figure 5-3 shows a sample output of the dir command from a Cisco 7206 router.

    9. Router>dir slot0:
    10. -#- -length- -----date/time------ name
    11. 1 3375568 Feb 19 1998 08:24:32 c7200-is-mz.112-11.P.bin
    12. 2 3391852 Mar 23 1998 11:26:41 c7200-is-mz.112-12.P.bin
    13. 1227716 bytes available (6767676 bytes used)
    14. Router>

<<<Figure 5-3 Dir Output on 7206>>>

According to Figure 5-3, Line 6, this PCMCIA slot has an 8 MB flash card (1,227716 bytes available plus 6,767,676 bytes used). The card contains two files shown on Lines 3 and 4.

        1. Flash Contents
        2. The files that on flash are usually IOS images that a can run. We are allowed to put as many files in flash as it can hold. A router will, by default, attempt to boot the first IOS image from flash.

          Let us compare the 2520 flash contents from Figure 5-2 with the 7206 flash contents shown in Figure 5-3. The 2520 flash contains one IOS image, and that image is over 8 MB. However, the 7206 flash, which has half the size of the 2520’s, has two files, and each is just over 3 MB. The 2520 IOS image would not even fit on the 7206 flash card. The 7206 is supposed to be one of the high-end routers; one would expect just the opposite. How can this be?

          The answer lies in the difference between the way that the 2500-series routers run IOS and the way 7x00-series routers run IOS. In Section 5.1, we stated that the 2500-series routers usually run IOS in flash; that is why flash memory was marked as read-only. Since IOS is running in flash, we cannot write to flash, and the IOS image cannot be compressed. On the 7x00-series router, IOS runs in RAM; therefore, the IOS images can be stored in flash in a compressed form. When a 7x00-series router runs an image from flash, the image is uncompressed into RAM before it runs. This is one of the reasons that the 2520 image is much larger than the 7206 images.

          The other reason is the IOS feature set of the images. The 2520 image has the enterprise feature set, and the 7206 image has the IP feature set. The enterprise feature set image has most of the possible IOS features included; therefore, it is obviously going to be bigger than an image that has only IP features, compressed or not. How can we tell that just by looking at the image name?

        3. Image Names

Cisco uses their own naming convention to name IOS files (Reference). The naming convention allows us to look at an image name and determine its router platform, its feature set, its version, where it runs (flash or RAM), and if it is compressed. This naming convention changes occasionally, but here are some recent highlights using the images from Figure 5-2 and Figure 5-3.

The image name is composed of at least two sections separated by periods (.). The first section has three parts separated by hyphens (-). The first part (c2500 and c7200) is the router platform. The second part (js and is) is the feature set. The j represents the enterprise feature set; the i represents the IP feature set, and the s means that additional features have been added to the images. The third part (l and mz) tells us where the image is supposed to run and if it is compressed. The l means that the image is relocatable; that is, it can run in either flash or RAM. The m means that the image runs in RAM, and the z means that the image is zip compressed.

The next section contains the version of the image. On the 2520 this is 113-5, which means IOS version 11.3(5). On the 7206, the second section for the first file is 112-11, which means IOS version 11.2(11). The 7206 has a third section (P) and a fourth section (bin). The P indicates that this image contains platform-specific features for the 7200-series. The bin means that the image is a binary file; of course, all IOS images are binary files.

      1. Controllers

A controller handles the communication and signaling for router hardware. There are many different types of controllers, and the controllers available on a router depend on the router model and its physical configuration. All interfaces connect to the router through a controller, and on the high-end routers, the communications bus has a controller.

The user mode command show controllers with its arguments can be used to display information about the installed controllers or information about an individual controller. The show controllers command can provide us with the following information for each controller.

We are going to show examples from several different routers just to show some of the different types of controllers. The output for the show controllers command can be rather lengthy; therefore, we going to show just the first few lines of the output for most of the examples.

To see all of the controllers on a router, the show controllers command without any arguments should work. However, if we want information about just one controller in a router, use the guestion mark to get help and find out what arguments are available.

Each interface on a 2500-series router usually has its own controller. Controllers for interfaces are numbered starting with zero. Figure 5-4 shows part of the output for a BRI controller on a 2520.

    1. Austin>show controllers bri
    2. BRI unit 0
    3. D Chan Info:
    4. Layer 1 is ACTIVATED
    5. idb 0xBE604, ds 0xCD2C0, reset_mask 0x8
    6. buffer size 1524
    7. [text omitted]
    8. Austin>
    9. <<<Figure 5-4 Show Controllers BRI Output on 2520>>>

      On Line 2, we see that this information is for the first BRI controller, unit 0. A BRI has three channels: two B channels and one D channel. The D channel is used for signaling between the router and the ISDN switch. The message "Layer 1 is ACTIVATED" on Line 4 means that the router’s BRI port is connected to an ISDN switch. If the connection to the switch were down, Layer 1 would be "DEACTIVATED", and it would be "PENDING ACTIVATION" if the connection to the switch were pending.

    10. FortWorth>show controllers ethernet
    11. LANCE unit 0, idb 0xB71B0, ds 0xB8900, regaddr = 0x2130000, reset_mask 0x2
    12. IB at 0x606E64: mode=0x0000, mcfilter 0000/0000/0900/2020
    13. station address 0010.7b3a.d4af default station address 0010.7b3a.d4af
    14. buffer size 1524
    15. [text omitted]
    16. FortWorth>
    17. <<<Figure 5-5 Show Controllers Ethernet Output on 2520>>>

      Figure 5-5 shows part of the output for an Ethernet controller. Line 2 shows that this is the first Ethernet controller, unit 0, and it has a LANCE chip set. Line 4 shows the MAC address for the interface on the controller.

    18. FortWorth>show controllers serial 0
    19. HD unit 0, idb = 0xD7D8C, driver structure at 0xDD028
    20. buffer size 1524 HD unit 0, V.35 DTE cable
    21. cpb = 0x62, eda = 0x408C, cda = 0x40A0
    22. [text omitted]
    23. FortWorth>
    24. <<<Figure 5-6 Show Controllers Serial 0 Output on 2520>>>

      Figure 5-6 shows part of the output for a serial controller. In Line 1, we have put a specific unit number, 0. When a unit number is referenced in the show controllers command, there must be a space between it and the controller type. According to Line 3, the type of cable attached to the serial interface on this controller is a V.35 DTE (Data Terminal Equipment) cable. This cable has a V.35 connector on the end not connected to the router. The V.35 connector is meant to be plugged in to a CSU/DSU, which provides the DCE (Data Circuit-terminating Equipment) side of the connection. On Cisco routers, the electrical interface (EIA/TIA-232 DTE, V.35 DCE, etc.) of a serial interface is determined by the type of cable attached to the port.

    25. Router>show controllers cbus
    26. MEMD at 40000000, 2097152 bytes (unused 0, recarves 1, lost 0)
    27. RawQ 48000100, ReturnQ 48000108, EventQ 48000110
    28. BufhdrQ 48000128 (2378 items), LovltrQ 48000148 (8 items, 2016 bytes)
    29. IpcbufQ 48000158 (16 items, 4096 bytes)
    30. IpcbufQ_classic 48000150 (8 items, 4096 bytes)
    31. 3570 buffer headers (48002000 - 4800FF10)
    32. pool0: 9 buffers, 256 bytes, queue 48000130
    33. pool1: 1147 buffers, 1536 bytes, queue 48000138
    34. pool2: 4 buffers, 1568 bytes, queue 48000140
    35. slot3: VIP2 R5K, hw 2.0, sw 22.20, ccb 5800FF50, cmdq 48000098, vps 8192
    36. software loaded from system
    38. ROM Monitor version 115.0
    39. Ethernet3/0/0, addr 00e0.34b4.a860 (bia 00e0.34b4.a860)
    40. gfreeq 48000138, lfreeq 48000160 (1536 bytes)
    41. rxlo 4, rxhi 860, rxcurr 4, maxrxcurr 5
    42. txq 48001A00, txacc 48001A02 (value 458), txlimit 458
    43. Ethernet3/0/1, addr 00e0.34b4.a861 (bia 00e0.34b4.a861)
    44. gfreeq 48000138, lfreeq 48000168 (1536 bytes)
    45. rxlo 4, rxhi 860, rxcurr 0, maxrxcurr 0
    46. txq 48001A08, txacc 48001A0A (value 458), txlimit 458
    47. Ethernet3/0/2, addr 00e0.34b4.a862 (bia 00e0.34b4.a862)
    48. gfreeq 48000138, lfreeq 48000170 (1536 bytes)
    49. rxlo 4, rxhi 860, rxcurr 0, maxrxcurr 0
    50. txq 48001A10, txacc 48001A12 (value 458), txlimit 458
    51. Ethernet3/0/3, addr 00e0.34b4.a863 (bia 00e0.34b4.a863)
    52. gfreeq 48000138, lfreeq 48000178 (1536 bytes)
    53. rxlo 4, rxhi 860, rxcurr 0, maxrxcurr 0
    54. txq 48001A18, txacc 48001A1A (value 458), txlimit 458
    55. Router>

<<<Figure 5-7 Show Controllers Cbus Output on 7505>>>

Figure 5-7 shows the output for a cbus controller on a 7505 router. Line 11 shows that there is a Versatile Interface Processor 2 (VIP2) in slot 3. This 7505 is running IOS version 12.0(1.0.2)S (Line 13). The VIP2 has four Ethernet interfaces as shown on Lines 15, 19, 23, and 27; the MAC address of each interface is shown. VIP interfaces have unit designators with three numbers separated by forward slashes: slot, port adapter, and port.

Most of the information found with the show controllers command is not very useful for day-to-day monitoring of IOS. The information may, however, come in handy for in-depth troubleshooting.

      1. Interfaces

We frequently need to check an interface’s status or an interface’s statistics like errors and traffic counters. Generally, the first thing we check on an interface is its status. An interface’s status consists of two components:

The first component is the physical layer status; it indicates whether the interface has passed diagnostics and is receiving appropriate signaling. On a serial interface, appropriate signaling could be Carrier Detect (CD) signal or a clocking signal from a WAN. Appropriate signaling on an Ethernet interface could be link signaling from a hub or switch.

The second component, referred to as line protocol, is the data link status; it indicates whether the interface is receiving keepalives (if they are enabled). A keepalive is a small, layer-2 message that is transmitted by a network device to let directly-connected network devices know of its presence.

Keepalives are transmitted out every interface every 10 seconds by default; the time between keepalives is configurable for each interface. On WAN interfaces, the keepalives are meant to be received by a neighboring router or switch, depending on the WAN type; an IOS-based router marks its WAN interface line protocol as up if it is receiving keepalives. On LAN interfaces, the router sends keepalives to itself; an IOS-based router marks its LAN interface line protocol as up if it is receiving its own LAN keepalives.

Figure 5-8 shows the common combinations of the two interface status components along with a possible reason that an interface can have the status.

Physical Layer Status

Data Link Status

Possible Explanation



Interface is probably operational.



Interface physical connection is OK, but interface is not receiving keepalives. Interface is not operational.



Interface physical connection is bad or not connected.

Administratively Down


Interface has been manually shut down or has never been turned on after initial configuration.


Up (looped)

WAN interface is receiving its own keepalives.


Up (spoofing)

WAN dialer-type interface is artificially marked as operational to maintain its network(s) in the routing table(s).

<<<Figure 5-8 Interface Status Possibilities>>>

An operational interface is commonly referred to as "up/up" or "up and up"; this is a shortcut way of saying or writing the two components of an interface’s status. If line protocol (data link status) is up and the interface doesn’t receive a keepalive for three keepalive intervals, line protocol will change state to down.

The general way of checking status and statistics is to use a form of the user mode command show interfaces. Issuing the show interfaces command without any arguments will show information for every interface in a router. This produces more than a terminal screen of information for every interface in a router; this could be a lot of terminal output to wade through to see the very last interface in the router, especially if the router has 30 interfaces. If we know the interface that we want to check, we can put the interface name as an argument to the show interfaces command. Figure 5-9 shows output for an Ethernet interface, and Figure 5-10 shows output for a serial interface.

    1. Router>show interfaces ethernet4/0
    2. Ethernet4/0 is up, line protocol is up
    3. Hardware is cyBus Ethernet, address is 0060.3e22.b880 (bia 0060.3e22.b880)
    4. Description: Third Floor Software Development LAN
    5. Internet address is
    6. MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 26/255
    7. Encapsulation ARPA, loopback not set, keepalive set (10 sec)
    8. ARP type: ARPA, ARP Timeout 4:00:00
    9. Last input 0:00:02, output 0:00:02, output hang never
    10. Last clearing of "show interface" counters 6d18
    11. Output queue 0/40, 9 drops; input queue 0/75, 0 drops
    12. 5 minute input rate 1056000 bits/sec, 546 packets/sec
    13. 5 minute output rate 1027000 bits/sec, 509 packets/sec
    14. 208267944 packets input, 71626541 bytes, 0 no buffer
    15. Received 197995 broadcasts, 0 runts, 0 giants
    16. 7 input errors, 7 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
    17. 0 input packets with dribble condition detected
    18. 207558863 packets output, 3056717135 bytes, 0 underruns
    19. 0 output errors, 25912392 collisions, 0 interface resets, 0 restarts
    20. 0 output buffer failures, 236 output buffers swapped out
    21. Router>
    22. <<<Figure 5-9 Show Interfaces Ethernet Output>>>

      The show interface output, in Figure 5-9, provides plenty of interesting information about a single interface; we will mention the major items. We can tell that this Ethernet interface is probably on a 7x00-series router because its unit designator has two numbers, slot 4 and port 0. On Line 2 we see the status is up/up. The status is always the first thing shown. Line 3 provides the MAC address. The first one is currently being used; the one in parentheses is the BIA (burned-in-address). The IOS allows one way of documenting an IOS configuration on the router, and that is putting a description on an interface; this interface’s description is shown on Line 4. We are given one layer-3 address, the primary IP address on Line 5.

      Figure 5-9, Line 6, shows the Ethernet interface’s MTU (Maximum Transmission Unit) in bytes, BW (bandwidth) in kbps, DLY (delay) in microseconds, rely (reliability) as a fraction of 255, and load (line utilization) as a fraction of 255. MTU is the maximum size of a packet that can transmitted or received on the interface; 1500 is the default for Ethernet. Some processes require a fixed value for the bandwidth of a network; those processes use the bandwidth parameter; its value has no effect on the speed of an interface. Some process also require a fixed value for network delay (how long does it take a signal to get from one side of a network to the other); those processes use the delay parameter; its value also has no effect on the speed of an interface. Reliability is the router’s judgment call based on interface errors for how stable the interface. The value 255 indicates 100 percent reliability. Load is the router’s measured utilization of the interface; the load of 26 shown on Line 6 represents about 10 percent.

      On Line 7 of Figure 5-9, we see that the encapsulation is ARPA (from Advanced Research Projects Agency). This is also referred to as Ethernet_II; it defines the format of the Ethernet frame header. Line 7 also tells us that keepalives are enabled, and they are being transmitted every 10 seconds. Conversely, IOS expects to receive keepalives every 10 seconds on this interface.

      According to Line 10 of Figure 5-9, the interface counters were cleared six days and 18 hours (6d18) ago. The interface counters are those shown in Lines 14 through 20 for input packets, bytes, and errors and output packets, bytes, and errors. We can use these and the five-minute input and output rates from Lines 12 and 13 to help determine what our interface is doing. The five-minute rates are just averages from the last five minutes of interface activity. Based on the statistics, we can tell that the number of packets being received and transmitted on this interface are about the same; however, the amount of data being transmitted is over four times the amount being received (see bytes in Lines 14 and 18). Either transmitting big packets or detecting many collisions could cause this discrepancy. Line 19 shows that Ethernet4/0 has had over 25 million collisions; this seems like an unusually large number of collisions. However, we must compare the collisions with the number of packets that have been transmitted (see packets output in Line 18). About 200 million packets have been transmitted; that makes the collision rate about 12 percent. These are very rough field calculations, but some network experts may consider that to be excessive.

      Figure 5-10 shows similar information for a serial interface. Notice that a serial interface has no MAC address. Line 5 shows the bandwidth to be 1544 kbps (1.544 Mbps); 1544 kbps is the bandwidth of a T1, and it is the default for a fast serial interface. Remember that this bandwidth parameter has no effect on the speed of the interface. On Line 6, the encapsulation is shown as HDLC (High-level Data Link Control). HDLC is the default encapsulation for all IOS-based router serial interfaces. Cisco’s implementation of the HDLC standard is proprietary (just like everybody else’s). HDLC keepalives are being sent every 10 seconds, and IOS expects to receive an HDLC keepalive from the router on the other end of the WAN every 10 seconds.

      The counters have never been cleared according to Line 8 of Figure 5-10. So how do we find out how old they are? Since the counters have never been cleared, they have been counting up since the router booted; therefore, if we find out how long the router has been running, we will know how old the counters are. The show version command covered in Section 5.1 provides router uptime. The counters are almost worthless unless we know how old they are so we can put them in perspective.

    23. Dallas>show interfaces serial1
    24. Serial1 is up, line protocol is up
    25. Hardware is HD64570
    26. Internet address is
    27. MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
    28. Encapsulation HDLC, loopback not set, keepalive set (10 sec)
    29. Last input 00:00:07, output 00:00:01, output hang never
    30. Last clearing of "show interface" counters never
    31. Input queue: 0/75/0 (size/max/drops); Total output drops: 0
    32. Queueing strategy: weighted fair
    33. Output queue: 0/1000/64/0 (size/max total/threshold/drops)
    34. Conversations 0/2/256 (active/max active/max total)
    35. Reserved Conversations 0/0 (allocated/max allocated)
    36. 5 minute input rate 0 bits/sec, 0 packets/sec
    37. 5 minute output rate 0 bits/sec, 0 packets/sec
    38. 71 packets input, 3865 bytes, 0 no buffer
    39. Received 60 broadcasts, 0 runts, 0 giants, 0 throttles
    40. 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
    41. 79 packets output, 4373 bytes, 0 underruns
    42. 0 output errors, 0 collisions, 6 interface resets
    43. 0 output buffer failures, 0 output buffers swapped out
    44. 33 carrier transitions
    45. DCD=up DSR=up DTR=up RTS=up CTS=up
    46. Dallas>
    47. <<<Figure 5-10 Show Interfaces Serial Output>>>

      All of these statistics and pages of information are great, but we just want to find out the status of each of the router’s interfaces. One of my personal favorite IOS commands is the user mode command show ip interface brief. This command will give the status of all the interfaces on a single page, unless you have more than 20 interface. Figure 5-11 has a sample.

    48. Dallas>show ip interface brief
    49. Interface IP-Address OK? Method Status Proto
    50. BRI0 unassigned YES unset administratively down down
    51. BRI0:1 unassigned YES unset administratively down down
    52. BRI0:2 unassigned YES unset administratively down down
    53. Ethernet0 YES manual up up
    54. Serial0 unassigned YES unset administratively down down
    55. Serial1 YES manual up up
    56. Serial2 unassigned YES unset administratively down down
    57. Serial3 unassigned YES unset administratively down down
    58. Dallas>

<<<Figure 5-11 Show IP Interface Brief Output>>>

This output was done on our test router Dallas. It shows that Ethernet0 and Serial1 are both up/up, and all the other interfaces are administratively down. Ethernet0 and Serial1 are the two interfaces we configured on Dallas in Chapter 3.

      1. Terminal Lines

Terminal lines are router devices that allow us to gain access to the IOS command line interface. There are four types of terminal lines:

The console port is a line device, and a router has only one. In Chapter 3, we attached a terminal to the console port to perform the initial configuration. The console port provides an EIA/TIA-232 DCE interface and is used for configuration when physical access to the router is available. We could also attach a modem to the console port and dial in to it; however, the console port provides no flow control signaling or modem control signaling. On older routers, the maximum speed of the console port is 9600 baud; Cisco’s new series of routers allow speeds of up to 115 kbps.

Asynchronous serial ports are usually used for dial-up access using PPP (Point-to-Point Protocol) or SLIP (Serial Line IP). Not all routers have asynchronous serial ports.

The auxiliary port is a line device, and a router has only one (if it has one at all). The auxiliary port provides an EIA/TIA-232 DTE interface and is normally used for dial-up access through a modem since it provides modem control signaling. Older routers have a maximum speed of 38400 baud.

Virtual ports are logical terminal lines used for telnet access to the router. They are commonly referred to as VTY’s. All IOS-based routers have five VTY’s. More can be created if we need the capability of having more than five simultaneous telnet sessions to the router.

The easiest way to check the status of terminal line devices is to issue the user mode command show line. Figure 5-12 shows a sample output.

    1. Dallas>show line
    2. Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns
    3. 0 CTY - - - - - 0 0 0/0
    4. 1 AUX 9600/9600 - - - - - 0 0 0/0
    5. 2 VTY - - - - - 18 0 0/0
    6. * 3 VTY - - - - - 7 0 0/0
    7. 4 VTY - - - - - 37 0 0/0
    8. * 5 VTY - - - - - 64 0 0/0
    9. 6 VTY - - - - - 48 0 0/0
    10. Dallas>

<<<Figure 5-12 Show Line Output>>>

In Figure 5-12, Line 2, the first two columns are labeled "Tty" and Typ". The "Tty" column is for the line number; line numbers, just like interface numbers, start at zero (0). The "Typ" column is for the line type. Only three types are shown in this display. If there were any asynchronous serial lines, they would be shown between the console line (CTY on Line 3) and the auxiliary line (AUX on Line 4). This would affect the line numbering.

There are two types of line numbering schemes: absolute and relative. The numbering scheme shown in Figure 5-12 is the absolute one. All of the lines are shown, and the first one is line 0. Each type of line also has a number. For example, the five default VTY’s are numbered 0 through 4. The numbers 0 through 4 are relative numbers for the VTY’s even though their absolute numbers on the router shown are 2 through 6. If we were to add another VTY, its relative number would be 5, and its absolute number would be 7. Lines can be referenced either by their absolute number (line 2 for example) or by their relative number if the line type is included in the reference (line VTY 0 for example).

The order that IOS puts the lines for determination of absolute line numbers is as follows:

Other important information displayed in Figure 5-12 is whether an inbound access classes ("AccI" column) or an outbound access classes ("AccO" column) are applied to the lines. An access class is a security mechanism used for limiting access to a line. The "Uses" column shows the number of times a network connection has been established to the line. The "Noise" column shows the number of framing errors received on the a line; a framing error, such as a missing stop bit, should occur only on console, asynchronous serial, and auxiliary lines.

Figure 5-12 shows two lines that are in use. In-use lines are designated with an asterisk (*) as the first character of the line display. Lines 3 and 5 (VTY 1 and VTY 3) have a connection established to them. Figure 5-13 shows information about line 5.

    1. Dallas>show line 5
    2. Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns
    3. * 5 VTY - - - - - 64 0 0/0
    4. Line 5, Location: "", Type: "vt100"
    5. Length: 24 lines, Width: 80 columns
    6. Baud rate (TX/RX) is 9600/9600
    7. Status: Ready, Active, No Exit Banner
    8. Capabilities: none
    9. Modem state: Ready
    10. Special Chars: Escape Hold Stop Start Disconnect Activation
    11. ^^x none - - none
    12. Timeouts: Idle EXEC Idle Session Modem Answer Session Dispatch
    13. 00:10:00 never none not set
    14. Modem type is unknown.
    15. Session limit is not set.
    16. Time since activation: never
    17. Editing is enabled.
    18. History is enabled, history size is 10.
    19. Full user help is disabled
    20. Allowed transports are pad v120 telnet. Preferred is telnet.
    21. No output characters are padded
    22. No special data dispatching characters
    23. Dallas>
    24. <<<Figure 5-13 Show Line Output for Individual Line>>>

      To get detailed information for a specific line, we just put the absolute line number as an argument to the show line command as shown in Figure 5-13. On Line 6 of Figure 5-13, we see the terminal length is 24 lines, and the terminal width is 80 characters. These were described in Section 4.3.6. On Line 12 of the figure, the Escape character is shown as "^^x"; this means <Ctrl-Shift-6><x> is the special sequence of characters the user of this connection can type to suspend it. Line 14 shows that the EXEC timeout is 10 minutes; after 10 minutes of inactivity on this line, IOS will kill the connection.

      In Figure 5-13, Line 19, we see that this terminal line has the default command history settings (see Section Line 21 states that the preferred transport is telnet. In Section 4.3, we learned that the IOS, by default, assumes that a single word typed on the command line is the name of a host to which to telnet if the word is not a command. Configuring the preferred transport on a terminal line controls this behavior.

      We have seen which terminal lines are in use. Suppose we now want to see who is connected to them. We can use the user mode command show users to do just that. See Figure 5-14 for an example.

    25. Dallas>show users
    26. Line User Host(s) Idle Location
    27. 3 vty 1 idle 3
    28. * 5 vty 3 idle 0
    29. Dallas>

<<<Figure 5-14 Show Users Output>>>

The show users command displays the current terminal line connections and their originating location, if applicable. For VTY connections, the originating location will be the IP address or name of the host from which the telnet session was established. On Line 3 of Figure 5-14, we see that the connection to VTY 1 originated from the host with the address; that address belongs to FortWorth, one of our test routers. On Line 4, we see that the connection to VTY 3 came from the host The asterisk in the first column of Line 4 indicates that this connection is the current session where the show users command was typed; that is our session.

To see specific information for our current terminal session, we can issue the user mode command show terminal. The output will be similar to that shown in Figure 5-13.

    1. IOS Status
    2. This section will cover a few commands we can use to check the operational status of IOS on a router. IOS has many features and resources, and they should be checked on a regular basis.

      1. CPU Utilization

Use the user mode command show processes cpu to find out how busy the CPU is and what IOS processes are running.

    1. Dallas>show processes cpu
    2. CPU utilization for five seconds: 6%/4%; one minute: 8%; five minutes: 8%
    3. PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
    4. 1 32 233 137 0.00% 0.00% 0.00% 0 Load Meter
    5. 2 3556 1601 2221 0.00% 1.25% 1.06% 0 Exec
    6. 3 2436 69 35304 0.00% 0.12% 0.16% 0 Check heaps
    7. 4 0 1 0 0.00% 0.00% 0.00% 0 Pool Manager
    8. [text omitted]
    9. Dallas>

<<<Figure 5-15 Show Processes CPU Partial Output>>>

Line 2 of Figure 5-14 shows CPU utilization averages over the last five seconds, one minute, and five minutes. On the five-second utilization, there are two numbers separated by forward slashes. The first number is the average utilization, and the second number is the percent of CPU time spent processing interrupts, for example, processing packets.

Starting on Line 4 of Figure 5-14, we are shown all of the processes currently running. The display shows the Process ID (PID), name, and statistics for each process. The "Runtime" for a process is the CPU time it has used in milliseconds (ms). The number of times the processes has been invoked is shown in the "Invoked" column, and the "uSecs" columns shows the average amount of CPU time, in microseconds (usec), each invocation has used. If we multiply the number of invocations by the amount of time for each invocation, the result should be the total amount of CPU time used.

If you believe CPU utilization is too high, check the list of processes to determine which one is using the most CPU time. Much of the output is not shown here; there can be hundreds of processes running on a router.

      1. Memory Utilization

Memory, RAM, is one of those resources that is extremely valuable to IOS. Monitoring memory utilization can be done with the user mode commands show processes memory and show memory. Figure 5-16 shows part of the output from the show process memory command.

    1. Dallas>show processes memory
    2. Total: 7791452, Used: 1540688, Free: 6250764
    3. PID TTY Allocated Freed Holding Getbufs Retbufs Process
    4. 0 0 34956 1252 1206092 0 0 *Init*
    5. 0 0 912 33520 912 0 0 *Sched*
    6. 0 0 2196656 796448 59292 444900 0 *Dead*
    7. 1 0 268 268 1740 0 0 Load Meter
    8. 2 0 212512 111768 45252 0 0 Exec
    9. 3 0 0 0 2740 0 0 Check heaps
    10. 4 0 96 0 2836 0 0 Pool Manager
    11. [text omitted]
    12. 71 0 96 2736 2836 0 0 RIP Send
    13. 72 0 6660 0 11072 0 0 RIP Router
    14. 1540488 Total
    15. Dallas>
    16. <<<Figure 5-16 Show Processes Memory Partial Output>>>

      In Figure 5-16, Line 2, we see a couple of things very important to the health of our router – how much RAM is being used and how much RAM is free. IOS does not put many constraints on how much RAM a process can use; therefore, it is up to us to keep track of it. After all, we do not want messages like the one below showing up when we attempt something from the console.

      %% Low on memory; try again later

      The output in Figure 5-16 shows the processes and their memory statistics. The amount of RAM currently being used by a process is shown in the "Holding" column. If the free memory is constantly going down for no apparent reason, check to see which process is holding more and more memory. That process may have what is called a memory leak; memory leaks will eventually cause the IOS to run out of RAM and die. We can normally repair memory leaks by upgrading IOS on a router.

      To get detailed statistics on memory utilization, use the show memory command to show the characteristics for all of the IOS memory blocks. Part of the output from the show memory command is in Figure 5-17.

    17. Dallas>show memory
    18. Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)
    19. Processor 90CA4 5694300 1079756 4614544 4606572 4614468
    20. I/O 600000 2097152 460952 1636200 1636200 1636032
    21. Processor memory
    22. Address Bytes Prev. Next Ref PrevF NextF Alloc PC What
    23. 90CA4 1064 0 910F8 1 319E578 List Elements
    24. 910F8 2864 90CA4 91C54 1 319E578 List Headers
    25. 91C54 2664 910F8 926E8 1 314D6CC TTY data
    26. 926E8 2000 91C54 92EE4 1 314FA9A TTY Input Buf
    27. [text omitted]
    28. I/O memory
    29. Address Bytes Prev. Next Ref PrevF NextF Alloc PC What
    30. 600000 260 0 600130 1 3181060 *Packet Data*
    31. 600130 260 600000 600260 1 3181060 *Packet Data*
    32. [text omitted]
    33. Dallas>

<<<Figure 5-17 Show Memory Partial Output>>>

The output shown in Figure 5-17 has three sections: memory utilization, processor memory, and I/O memory. The information in the processor memory and I/O memory sections may be a little more than we really need for normal IOS monitoring. With that in mind, here is a word of warning. The complete output of the show memory command can be lengthy; the output that was used for Figure 5-17 was over 2400 lines before it was cut down. If we set our terminal length to zero (0) to avoid having to deal with the More prompt, we will be waiting a very long time for the output to be displayed on our terminal screen.

The memory utilization section of the Figure 5-17 output is Lines 2 through 4. Memory has been divided into processor (system) memory and I/O (shared) memory. See the show version explanation in Section 5.1 (Figure 5-1, Line 15). The total amount of processor memory is about 5.7 million bytes, and the total amount of I/O memory is about 2 million bytes. The number of bytes used and free for each type of memory is shown also. The sum of free processor memory and free I/O memory is about 6.25 million bytes (see Figure 5-16, Line 2). The "Head" column shows the hex address of the beginning of each memory type. The head of processor memory matches the address of the first memory block shown in the processor memory section (Line 9). The head of I/O memory matches the address of the first memory block shown in the I/O memory section (Line 18).

The processor memory and I/O memory sections of the output in Figure 5-17 shows the beginning address, the size in bytes, and the owning process for each block of memory. Again, this is probably more than the average person needs to know.

      1. Buffer Utilization

IOS uses many types of buffers. The most common buffers that we need to keep an eye on are the network packet buffers. There are six types of network packet buffers, each with a different size; some routers have only five types of packet buffers. IOS keeps a pool for each type of buffer. Monitoring these pools is useful during troubleshooting of lost or dropped packets. We can use the user mode command show buffers to check the buffer pools. Figure 5-18 shows a sample output.

    1. Router>show buffers
    2. Buffer elements:
    3. 498 in free list (500 max allowed)
    4. 32853792 hits, 0 misses, 0 created
    5. Public buffer pools:
    6. Small buffers, 104 bytes (total 120, permanent 120):
    7. 115 in free list (20 min, 250 max allowed)
    8. 16890500 hits, 238 misses, 646 trims, 646 created
    9. 0 failures (0 no memory)
    10. Middle buffers, 600 bytes (total 90, permanent 90):
    11. 81 in free list (10 min, 200 max allowed)
    12. 6358828 hits, 292 misses, 386 trims, 386 created
    13. 11 failures (0 no memory)
    14. Big buffers, 1524 bytes (total 90, permanent 90):
    15. 90 in free list (5 min, 300 max allowed)
    16. 87900 hits, 0 misses, 0 trims, 0 created
    17. 0 failures (0 no memory)
    18. VeryBig buffers, 4520 bytes (total 10, permanent 10):
    19. 10 in free list (0 min, 300 max allowed)
    20. 323205 hits, 0 misses, 0 trims, 0 created
    21. 0 failures (0 no memory)
    22. Large buffers, 5024 bytes (total 10, permanent 10):
    23. 10 in free list (0 min, 30 max allowed)
    24. 89441 hits, 0 misses, 0 trims, 0 created
    25. 0 failures (0 no memory)
    26. Huge buffers, 18024 bytes (total 0, permanent 0):
    27. 0 in free list (0 min, 13 max allowed)
    28. 249958 hits, 64 misses, 128 trims, 128 created
    29. 0 failures (0 no memory)
    30. Router>

<<<Figure 5-18 Show Buffers Output>>>

Each public packet buffer can hold a network packet that is being processed by IOS. When a packet is received, a buffer from the appropriate pool is allocated and the packet is placed into the buffer. The appropriate pool is selected based on the packet’s size. The packets are placed into the smallest buffer in which they will fit. The sizes of buffers are described as Small, Middle, Big, VeryBig, Large, and Huge. Suppose, for example, that a 450-byte packet were received. IOS would allocate a Middle buffer (600 bytes) because a Small buffer (104 bytes) does not have enough space to hold the packet. On the display’s first line for each buffer pool are the size of the buffers in the pool, the number of buffers currently in the pool, and the number of permanent buffers in the pool. Permanent buffers are allocated at boot time and are never removed from the pool.

We will examine the Middle buffers in Figure 5-18 to describe the fields of each pool’s description. The number in the free list is the number of buffers that are currently not being used, in other words, the number of buffers that do not contain a packet for processing. On Line 11, we see that the pool contains 90 Middle buffers, and on Line 12, we see that 81 of those are available; therefore, we can calculate that 9 Middle buffers are allocated. Also on Line 12, the minimum and maximum number of free Middle buffers allowed is given. The minimum is shown as 10; therefore, if the Middle buffer free list goes below 10, IOS will create more Middle buffers. The maximum is 200; this means that IOS is allowed to have up to 200 Middle buffers if they are needed for a burst of Middle-buffer sized packets.

On Line 13 of Figure 5-18, we see counters for the number of buffer hits, the number of buffer misses, the number of buffer trims, and the number of buffers created. A buffer hit is a successful attempt to allocate a buffer when a packet needs to be placed in one. A buffer miss is an unsuccessful attempt to allocate a buffer; this is the result of not having enough buffers in the free list. A buffer miss usually results in a new buffer being created unless the maximum number of buffers allowed has been reached. The number of trims is the number of buffers destroyed because they are no longer being used. The number of buffers created is the times a buffer was created as a result of a buffer miss. Line 14 shows the number of failures; this is the number times a buffer allocation failed as a result of not having have a free buffer and not creating another buffer to accommodate the request. The "no memory" counter shows the number of failures resulting from not having enough memory.

      1. Stacks

The user mode command show stacks shows information that only a programmer could love; however, if a router crashes, the show stacks command provides information that is valuable for finding out what caused the crash. Figure 5-19 shows a sample output after a crash.

    1. Router>show stacks
    2. Minimum process stacks:
    3. Free/Size Name
    4. 1020/2000 Router Init
    5. 2832/4000 Init
    6. 1468/2000 RADIUS INITCONFIG
    7. 2056/3000 IP-EIGRP Router
    8. 1396/2000 IP-EIGRP Hello
    9. 2400/4000 Exec
    10. 2012/3000 IGRP Router
    11. 1968/3000 OSPF Router
    12. 848/2000 OSPF Hello
    13. 1688/2000 OSPF Scanner
    14. Interrupt level stacks:
    15. Level Called Unused/Size Name
    16. 1 0 3000/3000 CL-CD2430 transmit interrupts
    17. 2 0 3000/3000 CL-CD2430 receive interrupts
    18. 3 6 2772/3000 Serial interface state change interrupt
    19. 4 18305 2476/3000 Network interfaces
    20. 5 130161 2872/3000 Console Uart
    21. System was restarted by bus error at PC 0x384B3DE, address 0xD0D0D0D
    22. 2500 Software (C2500-JS-L), Version 11.3(2), RELEASE SOFTWARE (fc1)
    23. Compiled Mon 23-Feb-98 22:38 by ccai (current version)
    24. Image text-base: 0x03048154, data-base: 0x00001000
    25. Stack trace from system failure:
    26. FP: 0x19DB50, RA: 0x323F774
    27. FP: 0x19DB6C, RA: 0x31912D6
    28. FP: 0x19DB88, RA: 0x3148F46
    29. FP: 0x19DBA8, RA: 0x31496B8
    30. FP: 0x19DBDC, RA: 0x315BBCE
    31. FP: 0x19DC18, RA: 0x31A7E52
    32. ***************************************************
    33. ******* Information of Last System Crash **********
    34. ***************************************************
    35. Router>

<<<Figure 5-19 Show Stacks Output After a Crash>>>

Lines 23 through 35 have information that can be used to trace the cause of the crash. The Cisco TAC will most likely ask for the output of the show stacks command if you call them after a router crashes and reboots.

      1. Routing and Bridging Tables

Routing and bridging tables are stored in RAM. IOS maintains a routing table for each routed network protocol that has been configured on a router. Without a routing table for a network protocol, IOS cannot route packets for that protocol. If bridging has been configured on a router, IOS maintains a bridging table; without a bridging table, IOS cannot bridge frames. We can examine these tables with the user mode commands show route and show bridge.

The show route command requires a protocol keyword before the word "route". The protocol keyword tells IOS which routing table it should display. The general form of the command looks like this:

show protocol route

Where protocol is the name of a routed protocol such as ip, ipx, appletalk, or decnet. For example, to examine the IP routing table, the complete command is show ip route; Figure 5-20 shows the result.

    1. Dallas>show ip route
    2. Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
    3. D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
    4. N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
    5. E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
    6. i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
    7. U - per-user static route, o - ODR
    8. Gateway of last resort is not set
    9. is subnetted, 3 subnets
    10. R [120/1] via, 00:00:05, Serial1
    11. C is directly connected, Ethernet0
    12. C is directly connected, Serial1
    13. Dallas>
    14. <<<Figure 5-20 Show IP Route Output>>>

      A routing table shows all of the routes, or networks, that IOS has learned. The routing table display starts with a legend that explains the abbreviations that appear in the first column of each route in the table. This routing table from our router Dallas shows two directly-connected routes and one RIP-learned route. The RIP-learned route is the Ethernet LAN on FortWorth (see Figure 3-4). We can get a summary of the IP routing table with the show ip route summary command. Figure 5-21 shows a sample output.

    15. Dallas>show ip route summary
    16. Route Source Networks Subnets Overhead Memory (bytes)
    17. connected 0 2 104 368
    18. static 0 0 0 0
    19. rip 0 1 52 184
    20. internal 1 138
    21. Total 1 3 156 690
    22. Dallas>

<<<Figure 5-21 Show IP Route Summary Output>>>

Figure 5-21 shows counters for the sources of routes in the IP routing table along with the amount of memory that the routing table is using.

The routing and bridging tables will be described in more detail in the protocol configuration chapters.

      1. Logging

Logging allows IOS to inform us when a system event has taken place by sending a message to defined logging locations. By default, all logged messages are sent to the console port. There is also a buffer in RAM where the most recent messages are stored; however, this buffer is small, and it will wrap when it fills up. When the buffer wraps, old messages are purged to make room for new messages.

There are eight levels of logging numbered from 0 through 7. The lower the level number the more serious the condition being reported in the message. The eight levels are normally configured by their names. Figure 5-22 shows the logging level numbers and their names.

Level Number

Level Name

Level Description



System is unusable



Immediate action needed



Critical conditions



Error conditions



Warning conditions



Normal but significant conditions



Informational messages



Debugging messages

<<<Figure 5-22 Logging Levels>>>

The level descriptions in Figure 5-22 are straight out of the IOS context-sensitive help facility. Logged messages for levels 0 through 6 always start with a percent sign (%) and contain a facility code, the severity level number, a mnemonic code, and the message itself. The facility code identifies the part of the router (process or device) to which the message refers. The severity level number is a level number from 0 to 7 that indicates the severity of the situation being reported by the message. The mnemonic code identifies an individual error message for the facility. The message itself is just a text string that describes what happened or what is happening. If we want, we can have IOS add a timestamp to the message. The timestamp can be either the relative time since the router booted or the absolute time from the router’s clock.

The user mode command show logging shows the types of logging that can be configured, and it displays the logged messages that have been buffered. Figure 5-23 shows logging information from Dallas soon after it booted.

    1. Dallas>show logging
    2. Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
    3. Console logging: level debugging, 37 messages logged
    4. Monitor logging: level debugging, 0 messages logged
    5. Trap logging: level informational, 41 message lines logged
    6. Buffer logging: level debugging, 37 messages logged
    7. Log Buffer (4096 bytes):
    8. %LINK-3-UPDOWN: Interface BRI0, changed state to up
    9. %LINK-3-UPDOWN: Interface Ethernet0, changed state to up
    10. %LINK-3-UPDOWN: Interface Serial0, changed state to down
    11. %LINK-3-UPDOWN: Interface Serial1, changed state to up
    12. %LINK-3-UPDOWN: Interface Serial2, changed state to up
    13. %LINK-3-UPDOWN: Interface Serial3, changed state to down
    14. %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0, changed state to down
    15. %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to down
    16. %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2, changed state to down
    17. %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to up
    18. %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to down
    19. %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
    20. %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2, changed state to up
    21. %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3, changed state to down
    22. %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
    23. %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2, changed state to down
    24. %LINK-3-UPDOWN: Interface Serial1, changed state to down
    25. %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to down
    26. %LINK-5-CHANGED: Interface BRI0, changed state to administratively down
    27. %LINK-5-CHANGED: Interface Serial0, changed state to administratively down
    28. %LINK-5-CHANGED: Interface Ethernet0, changed state to administratively down
    29. %LINK-5-CHANGED: Interface Serial1, changed state to administratively down
    30. %LINK-5-CHANGED: Interface Serial2, changed state to administratively down
    31. %LINK-5-CHANGED: Interface Serial3, changed state to administratively down
    32. %IP-5-WEBINST_KILL: Terminating DNS process
    33. %SYS-5-RESTART: System restarted --
    34. Cisco Internetwork Operating System Software
    35. IOS (tm) 2500 Software (C2500-JS-L), Version 11.3(5), RELEASE SOFTWARE (fc1)
    36. Copyright (c) 1986-1998 by cisco Systems, Inc.
    37. Compiled Tue 11-Aug-98 04:06 by phanguye
    38. %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
    39. %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
    40. %SYS-5-CONFIG_I: Configured from console by console
    41. %SYS-5-CONFIG_I: Configured from console by console
    42. %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to up
    43. %LINK-3-UPDOWN: Interface Ethernet0, changed state to up
    44. %LINK-3-UPDOWN: Interface Serial1, changed state to up
    45. %SYS-5-CONFIG_I: Configured from console by console
    46. %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
    47. %AT-6-ONLYROUTER: Ethernet0: AppleTalk interface enabled; no neighbors found
    48. %AT-6-CONFIGOK: Serial1: AppleTalk interface enabled; verified by 1001.200
    49. Dallas>

<<<Figure 5-23 Show Logging Output>>>

There are several locations to which messages can be logged. Some of these are as follows:

Syslog logging (Figure 5-23, Line 2) sends message to an IP host running a syslog server; typically this is a UNIX host running syslogd. Messages are logged to the syslog server only if the severity level of the message is less than or equal to the configured trap level (informational on Line5) and if the IP address of the host has been defined in the IOS configuration.

Console logging (Figure 5-23, Line 3) sends messages to the console. By default all messages for all severity levels are logged to the console. If console logging is enabled the show logging command shows the highest level of messages that are to be sent to the console. Line 3 shows this to be debugging, the default.

Monitor logging (Figure 5-23, Line 4) sends message to a monitor terminal. There are no monitor terminals until we create them. Monitor terminals can be used to view the console message output on a VTY terminal line. We can make give a terminal the monitor functionality by issuing the privileged mode command terminal monitor. When a terminal is a monitor, it has the capability of receiving logging output for message with a severity up to the defined level. The defined monitor logging level on Line 4 is debugging; therefore, all logged messages will be sent to a monitor terminal.

Buffer logging (Figure 5-23, Line 6) sends messages to the buffer in RAM as long as the severity level of the messages are less than or equal to the defined level (debugging on Line 6).

SNMP logging sends messages to an SNMP management station for processing by a network management application.

On Line 8 of Figure 5-23, we see that the log buffer is 4 kB. In Line 10 through 33, the router’s interfaces changed states until they all ended up as administratively down. The severity level for the LINK facility messages is 3, errors; the LINK facility is used for physical layer status of interfaces. The severity level of the LINEPROTO facility messages is a 5, notification; this is not as severe as the LINK facility message since LINEPROTO indicates a data link problem rather than a physical problem. At Line 35 is the message about the system restarting; the severity level for the RESTART message is 5, notification. Lines 49 and 50 have AppleTalk messages with severity level 6, informational. Before AppleTalk becomes operational on an interface, it must locate neighboring AppleTalk devices and verify the cable-range and zone(s) for the network to which the interface is attached.

      1. Time

Every Cisco router has a system clock, and some routers like the high-end, 7x00-series routers have a battery-powered, system calendar. If the router does not have a calendar, the clock is set to midnight (00:00) on March 1, 1993 each time the router boots; otherwise the clock is set from the calendar time when the router boots.

On a running router, several ways are available for setting the system clock. For example, the clock can be set manually by using the privileged mode clock command or automatically by using Network Time Protocol (NTP).

To check the system clock, issue the user mode command show clock. Figure 5-24 and Figure 5-25 are two samples of the show clock command.

    1. Dallas>show clock
    2. *00:26:09.327 UTC Mon Mar 1 1993
    3. Dallas>
    4. <<<Figure 5-24 Show Clock Output Non-Authoritative>>>

      The hours, minutes, seconds, and milliseconds are shown from the system clock. There is also the time zone, month, day, and year. Since Dallas is a 2520 router, it has no battery-powered calendar; therefore, its system clock was set to midnight of March 1, 1993, when it booted. According to the time on Line 2 of Figure 5-24, Dallas has been running for 26 minutes and 9 seconds. The time zone is shown at UTC; this stands for Coordinated Universal Time and is the default time zone. UTC is sometimes referred to as Greenwich Mean Time (GMT) or Zulu time in other texts. Any other time zone must be manually configured. The asterisk (*) in Line 2 means that the time is not authoritative; IOS doesn’t believe that the time is accurate.

      If IOS is configured to get its time from a timing source such as an NTP server, the clock will be shown as authoritative once the router’s system clock has synchronized with the time learned through NTP.

    5. Dallas>show clock
    6. 12:37:15.901 CST Wed Nov 18 1998
    7. Dallas>

<<<Figure 5-25 Show Clock Output Authoritative>>>

Figure 5-25, Line 2 shows the time with no extra character (such as an asterisk) in front of it. This indicates that the time is believed to be accurate (authoritative). An authoritative clock can be used to synchronize clocks on other host systems. The time zone is CST (Central Standard Time); this was set in the configuration file.

      1. Protocols

The easiest way to see what routed protocols have been configured on a router is to issue the user mode command show protocols. The show protocols command tells us all the routed protocols that IOS has been configured to run and all the interfaces’ status and primary routed protocol information. Figure 5-26 shows an output of the show protocols command from Dallas.

    1. Dallas>show protocols
    2. Global values:
    3. Internet Protocol routing is enabled
    4. Appletalk routing is enabled
    5. IPX routing is enabled
    6. BRI0 is administratively down, line protocol is down
    7. BRI0:1 is administratively down, line protocol is down
    8. BRI0:2 is administratively down, line protocol is down
    9. Ethernet0 is up, line protocol is up
    10. Internet address is
    11. AppleTalk address is 100.10, zone Headquarters
    12. IPX address is AC100A00.0010.7b3a.d4bf
    13. Serial0 is administratively down, line protocol is down
    14. Serial1 is up, line protocol is up
    15. Internet address is
    16. AppleTalk address is 1001.100, zone WAN
    17. IPX address is AC100B00.0010.7b3a.d4bf
    18. Serial2 is administratively down, line protocol is down
    19. Serial3 is administratively down, line protocol is down
    20. Dallas>

<<<Figure 5-26 Show Protocols Output>>>

The output has two main sections, global values and interface values. The global values section shows the routed protocols. This is global because the protocols are turned on in global configuration mode. Dallas is running IP, AppleTalk, and IPX (Figure 5-26, Lines 3, 4, and 5, respectively). The interface values section begins on Line 6. The status of all interfaces is given; interfaces Ethernet0 and Serial1 are up/up; all other are administratively down. For those interfaces that have been configured with routed protocol parameters, the output includes the primary parameters. As example, let us examine the Ethernet0 parameters given. Line 10 has the primary IP address and prefix length (network mask); Line 11 has the AppleTalk address and primary zone; Line 12 has the IPX address.

Using the show protocols command is a way to get all of the different protocol addresses for a router’s interfaces. These come in handy for network documentation and troubleshooting.

To get specific information about a routed protocol on an interface, we can use the show interface command that includes a protocol keyword. The command looks like this:

show protocol interface

Where protocol is the name of a routed protocol such as ip, ipx, appletalk, or decnet. For example, to get specific AppleTalk information about all interfaces, the complete command is show appletalk interface. Examples of these commands will be given in the protocol configuration chapters.

      1. Environment

High-end routers like those in the 7x00-series have environmental controllers that monitor things like temperatures and voltage levels in a router; if the temperature gets too high or too low or if voltage levels get too far from normal, the router will be shut down. The user mode commands show environment and show environment all display information about the environmental conditions on a router that has an environmental controller. Figure 5-27 has output from both commands issued on a 7505 router.

    1. Router>show environment
    2. All measured values are normal
    3. Router>show environment all
    4. Arbiter type 1, backplane type 7505 (id 1)
    5. Power supply #1 is 600W AC (id 1)
    6. Active fault conditions: none
    7. Active trip points: Restart_Inhibit
    8. 15 of 15 soft shutdowns remaining before hard shutdown
    9. 01234
    10. Dbus slots: XX
    11. card inlet hotpoint exhaust
    12. RSP(4) 26C/78F 38C/100F 45C/113F
    13. Shutdown temperature source is 'hotpoint' on RSP(4), requested RSP(4)
    14. +12V measured at 12.21
    15. +5V measured at 5.15
    16. -12V measured at -11.98
    17. +24V measured at 23.68
    18. +2.5 reference is 2.49
    19. Router>

<<<Figure 5-27 Show Environment [All] Output>>>

The show environment command gives a status of environmental conditions. Line 2 of Figure 5-27 tells us that all measured values are normal. If we add the all keyword to the command, we get environmental condition details. Line 14 shows the temperatures taken at the router’s RSP4. Air being pulled into the chassis is 78 degrees Fahrenheit (F), and air being blown out is 113 degrees F. Lines 18 through 22 shows actual voltage levels of the router’s test points.

    1. Configuration Files
    2. All of the show commands we have used so far can be issued in user mode; however, sometimes the easiest way to see how a router is configured it to just look at its configuration files. Since the configuration files contains sensitive information like passwords and SNMP community names, we must be in privileged mode to view them.

      The two configuration files are the running configuration and the startup configuration. The running configuration is the current, active configuration of IOS, and it is kept in RAM. The startup configuration is the backup configuration, and it is stored in NVRAM so that IOS can read it into RAM during a boot. We can look at the contents of both files; under normal, stable production conditions the files should be identical.

      IOS always has a running configuration, even when all interfaces are disabled (shutdown); however, a startup configuration does not always exist. For example, a new router does not have a startup configuration. If a startup configuration is not present in NVRAM, the router will ask to enter the System Configuration Dialog.

      1. Running Configuration

The command to view the running configuration is show running-config. This is a privileged mode command. Figure 5-28 contains the output of the show running-config command on Dallas.

    1. Dallas#show running-config
    2. Building configuration...
    3. Current configuration:
    4. !
    5. version 11.3
    6. no service password-encryption
    7. !
    8. hostname Dallas
    9. !
    10. enable secret 5 $1$S.px$gAcVrJaShGu2x6Rvu/F1C/
    11. enable password enableme
    12. !
    13. appletalk routing
    14. ipx routing 0010.7b3a.d4bf
    15. !
    16. interface Ethernet0
    17. ip address
    18. no lat enabled
    19. appletalk cable-range 100-109 100.10
    20. appletalk zone Headquarters
    21. ipx network AC100A00
    22. no mop enabled
    23. !
    24. interface Serial0
    25. no ip address
    26. shutdown
    27. !
    28. interface Serial1
    29. ip address
    30. appletalk cable-range 1001-1001 1001.100
    31. appletalk zone WAN
    32. ipx network AC100B00
    33. !
    34. interface Serial2
    35. no ip address
    36. shutdown
    37. !
    38. interface Serial3
    39. no ip address
    40. shutdown
    41. !
    42. interface BRI0
    43. no ip address
    44. shutdown
    45. !
    46. router rip
    47. network
    48. !
    49. ip classless
    50. !
    51. line con 0
    52. line aux 0
    53. line vty 0 4
    54. password letmein
    55. login
    56. !
    57. end
    58. Dallas#

<<<Figure 5-28 Show Running-Config Output on Dallas>>>

On Line 2, there is the message "Building configuration." To display the running configuration, IOS must examine all of its settings and put them into an easily readable, text format. Depending on a router’s processor speed, this configuration file build could take from one second to five seconds. After the build, the file itself is displayed. IOS separates the sections of the file with exclamation points (!) to make the file easier to read.

Line 9 shows the command that set the router’s host name to Dallas. This host name appears in the command prompt in Line 1. Notice also that the prompt ends with a number sign (#) signifying privileged mode.

Line 10 has the enable secret password. The enable secret password is used to get into privileged mode. The value we assigned to it during the initial configuration is itsasecret; however, that is not what the configuration file shows. Not exactly, anyway. The enable secret password is displayed in its encrypted form in an IOS configuration file. Most network managers and administrators make a practice of keeping copies of their routers’ running configurations on their PC’s, on a TFTP server, or even on hardcopy. Notice the other passwords on Lines 12 and 61; they are easily read in their unencrypted form, which is the default way they are displayed. Without the enable secret password being encrypted, anyone with access to the disk drive files or paper files of the configurations would know all of the passwords. This is not considered to be very secure.

The next major section of the configuration in Figure 5-28 is where the routed protocols get turned on. The command telling IOS to route AppleTalk packets is on Line 14, and the command telling IOS to route IPX packets is on Line 15. We saw in Figure 5-26 that Dallas is also routing IP packets; however the configuration file does not show a command telling IOS to route IP packets. Most of the time, a running configuration file will not contain commands for default settings. The routing of IP packets is turned on by default in IOS; therefore, the command telling IOS to route IP packets (ip routing) is not shown.

As another example of this, look at the configuration sections for interface Ethernet0 (beginning on Line 18) and Serial0 (beginning on Line 26). The shutdown command on Line 28 is used to turn off an interface and put it into administratively down state. The opposite of shutdown is no shutdown. (Remember Section 4.3.5. Just say no.) There is not a no shutdown command under the Ethernet0 configuration section. The reason is that, by default, an interface is turned on, and the default setting is not in the configuration file.

According to Lines 48 and 49, Dallas is running the IP RIP routing protocol on its interfaces that have addresses in the network; that is all of them.

      1. Startup Configuration

The startup configuration is a text file stored in NVRAM. When a router boots, IOS looks in NVRAM for the file and then loads the file into RAM where its commands are entered into the running configuration. Issue the privileged mode command show startup-config to view the startup configuration file. If we bypass the System Configuration Dialog on a new router, NVRAM will remain empty. Figure 5-29 shows that output of the show startup-config command when NVRAM is empty.

    1. Dallas#show startup-config
    2. %% Non-volatile configuration memory has not been set up or has bad checksum
    3. Dallas#
    4. <<<Figure 5-29 Show Startup-Config Output With NVRAM Empty on Dallas>>>

      Figure 5-28 shows the running configuration; however, Figure 5-29 shows that we have no startup configuration. The command to create a startup configuration from the running configuration is as follows:

      Dallas#copy running-config startup-config

      Building configuration...



      The privileged mode command copy running-config startup-config will create the running configuration text file and then put that file into NVRAM. Figure 5-30 shows part of the output from the show startup-config now that there is a startup configuration.

    5. Dallas#show startup-config
    6. Using 833 out of 32762 bytes
    7. !
    8. version 11.3
    9. no service password-encryption
    10. !
    11. hostname Dallas
    12. [text omitted]
    13. Dallas#

<<<Figure 5-30 Show Startup-Config Partial Output on Dallas>>>

Since the startup configuration is already in text format and ready for display, there is no delay associated with preparing for output. Instead, the first message we get refers to the size of the startup configuration file and the size of NVRAM. According Line 2 of Figure 5-30, the size of Dallas’ startup configuration file is 833 bytes, and Dallas has 32762 total bytes of NVRAM (see also Figure 5-1, Line 26, for amount of Dallas’ NVRAM).

    1. Conclusion

The show command in all of its different forms is the most used command in IOS. We have barely scratched the surface of the information available using show. More detailed, protocol-specific information will be covered in the configuration chapters.

One more general show command that you find may useful for fast information gathering is the privileged mode command show tech-support. The show tech-support command will run multiple, pre-configured show commands one after the other. For example, it will issue the show version, show running-config, show controllers, show interfaces, and a few other commands in quick succession. The command will also temporarily set you terminal length to zero (0) thus disabling the More prompt and causing the information to scroll very fast. The output of the show tech-support command is meant to be captured to a log file by your terminal emulation software and then sent to the Cisco TAC. The resulting file provides them (and us) with an overview of a router’s configuration and status.

Backward Forward
Chapter: | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

Reserve your copy at a
Bet@ Bookstore near you!
Contact Bet@ Books
© 1999 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Bet@ Book(TM) is subject to the rules stated in the Terms of Use.

Bet@ Books | Bet@ Bookstores | Computing McGraw-Hill

Professional Publishing Home | Contact Us | Customer Service | For Authors | International Offices | New Book Alert | Search Catalog/Order | Site Map | What's New

A Division of the McGraw-Hill Companies
Copyright © 1999 The McGraw-Hill Companies, Inc. All rights reserved. Any use is subject to the Terms of Use the corporation also has a comprehensive Privacy Policy governing information we may collect from our customers. Bet@ Books (TM) is a registered trademark of The McGraw-Hill Companies, Inc.