Cisco optimize

Troubleshoot Cisco routers and switches using the debug commands

David Davis shows you how to get to the bottom of router and switch issues with Cisco's debug commands. Debug can give you a lot of detailed troubleshooting information, but watch out for the debug mistakes that can seriously affect your network.

David DavisOften, you cannot solve router and switch issues with "show" commands alone. At some point, you will have to use Debug commands to find out what is really going on behind the scenes. In this article, you will learn about Cisco IOS Debug commands and how they can help you.

What makes Cisco IOS Debug commands so useful?

Cisco IOS Show commands can tell you many things about what is going on with your router or switch, but they can't tell you everything. For example, Show commands cannot tell you when routes drop in or out of the routing table, why an ISDN line failed to connect, whether a packet really went out the router, or what ICMP error code was received. On the other hand, Cisco IOS Debug commands can tell you all these things, and more.

Besides providing more detailed information than what Show commands can provide, Debug commands have the benefit of providing information in "real time" (or dynamically). This is contrary to Show commands that just take a snapshot in time and display the results on your console (somewhat static results). This real-time difference can be very helpful in diagnosing problems.

How do I use Debug commands?

Let's take a look at a simple example. We are going to view RIP (Routing Information Protocol) in Debug mode.

Router# debug ip RIP
RIP protocol debugging is on

To verify what debugging is enabled, use this command:

Router# show debug
  RIP protocol debugging is on

The output from whatever type of debug is enabled will be sent to wherever the Cisco IOS logging system tells that output to go. Either you will receive the output on your screen, it will go to the buffered log on the router, or it will go to a syslog server across the network (or all of these).

To see what level the various outputs are set to and where the output will go, type:

Router# show logging
Syslog logging: enabled (1 messages dropped, 3 messages rate-limited,
                0 flushes, 0 overruns, xml disabled, filtering disabled)
    Console logging: level debugging, 8 messages logged, xml disabled,
                     filtering disabled
    Monitor logging: level debugging, 0 messages logged, xml disabled,
                     filtering disabled
    Buffer logging: level warnings, 2 messages logged, xml disabled,
                    filtering disabled
    Logging Exception size (4096 bytes)
    Count and timestamp logging messages: disabled
    Trap logging: level informational, 12 message lines logged

Log Buffer (51200 bytes):

*Jun  9 20:56:49.195: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Jun  9 20:56:49.231: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
Router#

The console should display RIP updates that are sent and received through the RIP protocol. Here is an example of what you might see for RIP debugging:

*Jun  9 21:13:56.471: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (1.1.1.1)
*Jun  9 21:13:56.471: RIP: build update entries - suppressing null update
*Jun  9 21:14:22.519: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (1.1.1.1)
*Jun  9 21:14:22.519: RIP: build update entries - suppressing null update

Remember that you should use Debug only for a short time to get a snippet of information, and then turn Debug off as it can be a serious performance hit on your router.

There are several commands for turning off Debug. You could type undebug all or a precreated alias, un all (for more information on aliases, see my article "Enter Commands More Efficiently with Cisco Command Aliases"), but the no debug command works fine also.

Router# no debug

If you type debug ?, you will see that there are over 200+ Debug commands, and each of those has many options. Debugging RIP is just a very simple example.

What are the three most common mistakes made when using Debug?

Using Debug can be a risky proposition, and even experienced admins have made mistakes when using it.

I'd say the number one common mistake is to forget that you have left Debug on in a production environment. Sometimes, we get so focused on resolving the issue that when we get it resolved, we are on to the next "opportunity" and forget to issue the no debug command to turn off debugging. I think that many a network admin can attest to horror stories of when they brought their router to its knees because they forgot this simple task of turning off Debug.

The second common mistake would be not realizing the effect on your router of issuing a lot of Debug commands at the same time. Remember that the router's job is to forward packets, not to monitor processes and generate Debug messages. For example, you are having a problem with the packets on your router, so you issue the Debug statement debug ip packet. Then you decide that you want to view the events on the RIP protocol. Now, you have two separate Debug statements that are being processed and sent to the console. Debug statements are processed at a higher priority than other network traffic, so, needless to say, these Debug statements can jeopardize your router's performance.

The third common mistake made with the Debug command is entering debug all or debug ip packet detail on a production router. Either one of these commands can crash a heavily loaded production router. Luckily, there is an "are you sure" prompt before these take effect; however, that hasn't prevented every debug-related catastrophe. You should be as specific as possible when using Debug, and then turn it off as quickly as possible. Also, always test your Debug commands on a test router before using them in a production environment.

What are some common scenarios when using Debug to troubleshoot?

To learn about the top 10 most useful Cisco IOS Debug commands, please read my TechRepublic article "Get IT Done: 10 Ways to Mitigate Problems Using Cisco IOS Debug."

In conclusion

The Cisco IOS Debug commands are very powerful commands that every Cisco admin should know how to use properly. With Cisco IOS Debug commands, you can get down to the details of whatever protocol or feature you are troubleshooting in order to resolve your problem.

For more information on Cisco IOS Debug commands, see the Cisco IOS Debug Command Reference.

David Davis has worked in the IT industry for twelve years and holds several certifications, including CCIE, MCSE+I, CISSP, CCNA, CCDA, and CCNP. He currently manages a group of systems/network administrators for a privately owned retail company and performs networking/systems consulting on a part-time basis.

Want to learn more about router and switch management? Automatically sign up for our free Cisco Routers and Switches newsletter, delivered each Friday!

6 comments
mike610
mike610

Least two more other than deug ip rip commands and their functions and information that they can provide regarding to trouble shooting routing updates.

computab
computab

Unfortunately these commands do not work with other routers, such as Netgear, Buffalo, Dlink, etc. Are there any that will work on these?

mtoney
mtoney

Another easy way to troubleshoot problems to determine if you are fighting a configuration problem, a line problem, a smartjack issue or a bad pairing/demark or related issue, is to issue a "show controller t3 1/0/1:0 (or appropriate interface)" "show controller serial 0" etc... which will tell you the alarm condition, the counters, including CRCs, aborts, runts, retries, etc... and will give you the time frame for the last 24 hours broken into 15 minute increments. You can then tell whether you are fighting a line problem or if the line is up and you are fighting a configuation issue. I have mistyped an ACL or other simple config problem and thought I was fighting a line issue when a simple sh contr ser 0 was all that was needed to realize that the line was up, with no alarms, I just needed to look closer at my config to see that I had typed ser 0/1 instead of serial 0/0 or forgotten to type "no shutdown". Sometimes it is the simple things. But as David mentions, the worst thing you can do, is to forget to type "no debug" when you are done. As your network counters go up and the network gets busier, buffering that data will add more latency and perhaps bring your router down. This especially so on your border routers on higher speed lines. HP routers have a hidden, undocumented command that will give you more information than you ever wanted to sift through. Try piping it out to a text file. Type: show tech >tech.txt -Have fun looking at everything your router and switch is doing. You will find a thousand entries you didn't know were there. It can help you with about any configuration you ever had trouble with. THE Engineer. windowsmt60@hotmail.com

Photogenic Memory
Photogenic Memory

Wow! That's a pretty powerful debug command. Most definitely used sparringly ( hopefully ). This is a great post. Thanks for putting it up? I would like to own my own Cisco equipment to practice. Since new stuff is unaffordable for home owners; is Ebay a safe place to get them from? What I mean is how can you tell if your equipment is legit and not a Chinese knock off with backdoors, LOL! It's a dumb question but legit. How do you?

ddavis
ddavis

Hi adambrown, Thanks for your comments! Yes, I think that ebay is a safe place to get Cisco gear. From what I have heard, it is VERY difficult to tell the difference between Chinese knock off Cisco gear and authentic. However, as I have heard that only the modules were being knocked off (not the whole router), it probably wouldn't be that big of a concern if you are just buying a couple of routers & a switch for a home lab. Thanks for reading TechRepublic! Anyone else out there care to share any comments about the Cisco IOS debug command? David Davis