Using Device Diagnostic Commands

Cisco Security Network devices have numerous integrated commands to assist you in monitoring and troubleshooting your network. The following sections describe the basic use of these commands:

• show commands

• debug commands

show Commands

The show commands are powerful monitoring and troubleshooting tools. You can use the show commands to perform several functions:

• Monitor device behavior during initial installation

• Monitor normal network operation

• Isolate problems with interfaces, nodes, media, or applications

• Determine when a network is congested

• Determine the status of servers, clients, or other neighbors

The show commands have different effects for different devices as explained in this text, chapter by chapter. However, some common commands are used in every device. For instance, the show version command displays the configuration of the system hardware, the software version, the names and sources of configuration files, and the boot images. The show running-config command displays the router configuration currently running.

Some of the Cisco Network Security devices have a convenient Graphical User Interface (GUI) for obtaining status and various statistics which is equivalent to the output of show command using CLI. One such tool is the PIX Device Manager (PDM). You can use either the show command or the PDM to obtain statistics and configuration information on the PIX firewall.

debug Commands

The debug commands can provide a wealth of information about the traffic being seen (or not seen) on an interface, error messages generated by nodes on the network, protocol-specific diagnostic packets, and other useful troubleshooting data. Exercise care when using debug commands. Many debug commands are processor-intensive and can cause serious network problems (such as degraded performance or loss of connectivity) if they are enabled on an already heavily loaded router. When you finish using a debug command, remember to disable it with its specific no debug command (or use the no debug all or undebug all command to turn off all debugging).

It is best to use debug commands to isolate problems, not to monitor normal network operation. Because of high processor overhead, debug commands can disrupt device operation, and therefore you should use them only when you are looking for specific types of traffic or problems, and have narrowed your problems to a likely subset of causes.

Output formats vary with each debug command. Some generate a single line of output per packet, and others generate multiple lines of output per packet. Some frequently generate large amounts of output, and others generate only occasional output. Some generate lines of text, and others generate information in field format.

To minimize the negative impact of using debug commands, follow this procedure:

Step 1.	Use the no logging console global configuration command on your router. This command disables all logging to the console terminal.
Step 2.	Use Telnet to access the network devices (for example, router, PIX, and so on) and go into enable mode. For a router, you then execute the terminal monitor command to copy debug command output and system error messages to your current terminal display. By redirecting output to your current terminal display, you can remotely view the output of the debug command, without being connected through the console port. If you use debug commands at the console port, character-by-character processor interrupts are generated, maximizing the processor load already caused by using debug. If you intend to keep the output of the debug command, spool the output to a file.
Step 3.	You can also send the debug output to the buffer or a syslog server for reliability checks and capturing debug output, especially when you cannot remain in front of the Telnet window of the device. For collecting debug output or other syslog messages in real time, the Telnet window (the monitor mode on the router for syslog) is preferred. However, if you need to collect the debug output or other syslog messages on the router over a period of time, the only choices are sending the debug and other syslog messages to a buffer or the syslog servers. Sometimes, because of buffer limitations on the device, syslog server is the only choice.