Cisco IOS Debug Troubleshooting Tool

Handling the Cisco IOS Debug Troubleshooting Tool

Debug is a troubleshooting command that is available from the privileged exec mode (of Cisco IOS). This command can be used to display information about various router operations and the related traffic generated or received by the router, as well as any error messages. This tool is very useful and informative, but you must be aware of the following facts regarding its use: Debug is treated as a very high priority task. It can consume a significant amount of resources, and the router is forced to process-switch the packets being debugged. Debug must not be used as a monitoring tool—it is meant to be used for a short period of time and as a troubleshooting tool. By using it you discover significant facts about the working and faulty software and/or hardware components. The following is a list of recommendations on proper usage of the debug command:

If you are interested to see a timestamp with each line of the debug output, you must load the timestamp service using this command:

router(config)#service timestamps debug [datetime | uptime)
If you plan to see the debug output from within a Telnet session, you need to enter the terminal monitor command.

Usually, the debug command is used to diagnose a specific facility, task, or protocol. Sometimes a protocol suite has a specific member (e.g., TCP from among the TCP/IP protocol suite members) that you may want to focus on. When you choose the protocol you want to debug, then you usually have a choice to use the events option or the packets option of the debug command for that specific protocol. Event debugging is less resource intensive than packet debugging, but packet debugging produces more information.

Turning debugging on for everything (using the debug all command) is seriously discouraged in production networks. You get a tremendous amount of information, very fast, but it can severely diminish the router's performance or even render it unusable. The debug all command is also quite useless since it presents overlapping information that is difficult if not impossible to interpret.

Before using the debug command, see the CPU utilization of your router (using the show processes cpu command). If your router's CPU utilization is consistently at 50% or more, you are advised to debug events instead of packets.

If possible, use the debug command during periods when network traffic is not at its peak and fewer critical business applications are active. Cisco routers give the debug command higher priority (with respect to CPU cycles) than network traffic.

Always remember to undo debug as soon as possible. You can use the no debug {argument} to turn off a specific debugging type. The no debug all or undebug all commands can be used to turn off all types of debugging that may be on.

For troubleshooting, also consider using protocol analyzers to capture and display network traffic. These have little or no impact on your network performance, yet they provide valuable information. I also recommend capturing debug info to a file for offline perusal and training.

Using an access list with your debug command helps you focus the debug output on the task you are troubleshooting. See the next section for more information on this technique.