Chapter 5. Examining IOSNetwork 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.
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. <<<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. 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. 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. <<<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. <<<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.
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? 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. 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. <<<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. <<<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. <<<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. <<<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.
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.
<<<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.
<<<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. <<<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. <<<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.
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. <<<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.
<<<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 4.3.1.1). 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. <<<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 172.16.11.2; 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 euless.tx.witcon.com. 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.
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. Use the user mode command show processes cpu to find out how busy the CPU is and what IOS processes are running. <<<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.
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. <<<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. <<<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.
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. <<<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.
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. <<<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.
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 routeWhere 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. <<<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. <<<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.
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.
<<<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.
<<<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.
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. <<<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. <<<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.
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. <<<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 interfaceWhere 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. 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. <<<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.
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. 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. <<<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 172.16.0.0 network; that is all of them.
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. <<<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... [OK] Dallas# 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. <<<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).
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. |