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:

• What version of IOS is the router running?
• How much RAM does the router have?
• How much of that RAM is IOS using?
• How busy is the router?
• What interfaces does the router have?
• How long has the router been running?
• How did the router last boot?
• What the status of the interfaces?
• Which protocols are configured on the router?

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.

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.

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.

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.

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.

• Hardware Type
• Hardware Version
• Microcode Version
• Statistics

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

• Physical Layer Status
• Data Link Layer Status.

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.

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.

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:

• Console (CTY or CON)
• Asynchronous Serial (TTY)
• Auxiliary (AUX)
• Virtual (VTY)

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.

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:

• The console line is always first; therefore, the console is always line 0.
• Asynchronous serial lines follow the console line; therefore, the absolute line number for the first asynchronous serial line is 1.
• The auxiliary line follows the asynchronous serial lines if they are present; otherwise, it follows the console. The absolute line number of the auxiliary line is one greater than the last asynchronous serial line number.
• The VTY’s follow the auxiliary line. The absolute line number of the first VTY (VTY 0) is one more than the auxiliary line number.

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.

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.

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

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.

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.

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.

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

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.

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.

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

• Syslog Server
• Console Terminal
• Monitor Terminal
• Buffer
• SNMP Management Station

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

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.

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.

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.

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.

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.

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.