Warning: Use these Cisco Debug Commands at Your Own Risk

In today's article, I'll show you some useful ways that you can take advantage of the Cisco IOS debug feature.

First of all, I'd like to point out that all the commands presented in this article, and in general all IOS debug commands, should be used with great caution.

Cisco recommends that the use of debug commands should be performed under the direction and guidance of specialized technical personnel, because they may lead to operation disruption and even total device failure.

Although the commands that I'll introduce in this article are not that dangerous, I recommend you don't use them on a production router with high load traffic.

It's best to test them first on a test router before applying them on a live platform.

Before getting into all the details of these useful debug commands, let's go over some important pre-debug tasks.

You'll need to follow these closely if you want to preserve your router's operability and get the most benefit from your troubleshooting activity.

Pre-Debugging Tasks

Before enabling a debug command, always ask yourself this:

What output am I expecting from this debug command and how much traffic load will I introduce by applying this command?

It is very important to know what traffic passes through your router and the volume of this traffic. For example, if you have an AS5300 gateway with four T1 interfaces, all running at high traffic volume, debugging isdn events on the gateway will probably generate so much traffic that may crash the system.

Therefore, it is very important to know your router's activities and estimate the consequences of your debug commands.

The following key points should be followed prior to debugging:

Take a look at your router's CPU load by issuing the show processes cpu command.Make sure that you have plenty of CPU available before commencing your debugging. If you have high CPU utilization do not issue any debug commands.

Check out this Cisco document on Troubleshooting High CPU Utilization on Cisco Routers to find more details on ways to handle high CPU loads.

Keep in mind that routers are able to log debug command outputs to the console, auxiliary and vty ports. They are also able to log debug output to an internal buffer or to an external syslog server.By default, debug logging is enabled on the console port of the router and this cannot be disabled. Even if you use a different port to capture debug output, the console port always processes this output.

Cisco recommends disabling console logging messages to be displayed by using the no logging console command and enable it only when necessary by using the logging console command.

If you connect to an auxiliary port or via telnet (vty port) then you should use the terminal monitor command to direct debug messages to these ports.

It's good practice to copy log messages to the internal buffer using the logging buffered command so that you may display them at a later stage by using the show logging command.

Apply time stamps to your debugging output for accurate and easier troubleshooting. These time stamps add the date and time (in hours:minutes:seconds:milliseconds).Use the service timestamps debug datetime msec and service timestamps log datetime msec commands to configure millisecond timestamps for display and buffere logging messages.

Debug IP Packet Command

Use the debug ip packet command to monitor packets that are processed by the routers routing engine and are not fast switched.

This command generates an output for every single packet, therefore it should be used with great caution.

A sample output of the debug ip packet command is presented below:

The best way to limit the output is to create an access list and apply it to the debug process so that only packets that match the access list will be processed by the debug command.

(Learn all about access lists in my next post -- grab our RSS feed to get it first!)

For example if you want to monitor traffic from 200.30.100.196 to 212.30.100.201 then you should apply the following commands:

Debug IP Packet Detail Command

Similar to the debug ip packet command, the debug ip packet detail command presents a more detailed output of the packet's processes by the routing engine.

A sample output is presented below. I recommend that you use this command in conjunction with an access list to limit the traffic load logged by this command.

Debug IP UDP Command

Use the debug ip udp command to monitor UDP traffic only. Sample output from this command is presented below:

Debug ISDN Q931 Command

Use the debug isdn q931 command when investigating ISDN routing errors (layer 3). To troubleshoot ISDN layer 2 problems use the debug isdn q921 command.

A sample output from the debug isdn q931 command is presented below. Notice the details obtained regarding calling and called party numbers, bearer capability, message sequence, etc.

Debug cch323 all Command

Use the debug cch323 all command to investigate H323 VoIP problems. This debug command presents details regarding the H323 message flow and it's useful in determining the correct handling of H323 protocol stack (H225 RAS, H225 call setup , H245 ,etc.).

A sample output from this command is presented below:

You've Been Warned ...

Be very careful when applying these and other debug commands.

It's always good to do a little bit of research on each debug command that you're about to use. It will give you a chance to find any potential caveats and harmful effects that you might need to be aware of.

If at any time you enabled a debugging that floods your screen with a great amount of messages the quickest way to turn it off is to run the undebug all or for short the un all command. Then use the show debug command to verify that you have stopped the debug.

Remember that the commands no logging console and terminal no monitor are used only to prevent debug output from being displayed on the console, aux or vty ports respectively. But remember, these commands do not stop the debugging process.

Use the no logging all command to turn off all message logging (buffer, syslog, aux, vty) except console logging (always on).

Ready to test your skills in CISCO? See how they stack up with this assessment from Smarterer. Start this CISCO test now