By Matt Bentley.
Many people shy away from enabling debugging of any kind on a Cisco router. As usual, the reason for shying away from something is lack of understanding. This article attempts to provide an objective look at debugging, listing the risks and how to minimize them, as well as some commonly used debug commands.
A common misconception about debugs is that in order to use them, you have to completely understand them. Fortunately, getting something useful from the majority of debugs available on a Cisco router isn’t rocket science. Perhaps the best explanation I have heard about debugs recommended thinking of them as an intern pouring over the blueprints for the rocket and trying to see if he can find anything that looks slightly abnormal.
Then, with some constructive Googling, it is usually not all that difficult to get yourself pointed in the right direction.
Debugs really give you a look “under the hood” as to what the router is doing. Rather than waiting and hoping that the route finally shows up, or the tester on the conference bridge tells you it’s working now, a debug can allow you to see everything.
A lot of engineers execute a change on a device, and then wait and wonder what the router is doing. Debugging often shows the logic and coding of the router at work as it takes incoming information and performs certain actions based on that. You can get a much better idea as to why something is happening and how to get what you want to happen occur.
Since the level of debugging is in such great detail, of key importance is to make sure you are enabling the right debugs so you get the information you need. Turning on too many debugs makes it impossible to go through the information. You want to be as specific as possible when you turn on debugs, for both performance and ease of interpretation purposes.
Before we get into turning on debugs, we should first look at how to minimize any potential impact turning on a debug might have – because it can have some unintended consequences if you are not careful. For a deeper look into debugging routers, check out the CCNA certification course offered by Intense School.
With debugs, you obviously need a place to see the information generated by the debug. Where this is depends on where the router is configured to print the debug output. They include the console port (if you are connected to the router via the console), the VTY/AUX lines, to a syslog server, and to the buffer of the router.
When choosing where you want the debug output to go, you should remember a couple things. Is to the destination going to prevent you from turning it off? For example, if you’re connected via a console port, and you enable a debug that prints every frame passing through the router, it’s likely going to be very difficult for you to turn off that debug. You will also leave yourself wide open to potentially affecting production traffic – and that is never a good thing.
Secondly, is the destination going to allow you to review it later? A scrolling debug is great, but if your logging buffer wraps after 200 lines, you’re likely not going to be able to get a good idea of what is going on, especially given the amount of output some debugs are capable of generating.
As a general rule, the debug output will go to one of two places: either the logging buffer of the router (visible with the “Show log” command) or a syslog server.
If you choose the logging buffer option, you want to make sure of two things. First, the logging buffer level should be set to debugging. By default, a Cisco router will only send messages of a certain severity generated by the router to the logging buffer. Also, you want to make sure your buffer is big enough. There is a single command that can set both of these options – Logging buffered debugging. The default severity sent to the syslog server is XX.
If you are going to send the output to a syslog server, you must use the “logging trap debugging” command. Otherwise, only XX severity messages get sent to the syslog. Again, you should be aware here that it requires CPU cycles for the router to package up all the output into IP frames and get it off to the syslog. Be wary if you are enabling debugs with exceptionally large amounts of data.
With all this being said, enabling a debug is actually not all that difficult. As you might guess, switching on a debug occurs with the word “debug” on the router. All this is done from privileged mode – you don’t want to be in config mode when you do this. The honest truth is that highly experienced engineers have a few debug commands they have memorized, but remember: the question-mark is your friend!
The hierarchical nature of the Cisco configuration commands is fairly closely mirrored in the debugs. For example, you might debug why a static route (e.g. “ip route” command) isn’t getting installed with the “debug ip routing” command. Find a command you think will work and maybe the first time you use it, do some strategic Googling to see if there are big warnings on Cisco’s website about that causing extreme CPU load, for example. Cisco even puts out an entire debug command reference which you should be able to find for the version of IOS you are running.
When enabling debugs, Cisco has fortunately given us a couple of good ways to limit the impact and amount of data generated by what would otherwise be significantly taxing commands. These options are not available on most debugs, but are there for some of the most commonly used ones. Perhaps the two main ones are access-lists and conditions.
Access-lists are pretty straightforward: you define the specific component of the larger debug you are interested in, and the router displays only information for the debug for that specific component. For example, if you are trying to see how a router is routing packets to a specific destination, you would first define the prefix you are interested in – let’s say destination 1.2.3.4 – in an access-list. Then, you match that access-list in the debug command. It would look something like this:
access-list 1 permit 1.2.3.4
debug ip packet 1
