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