Troubleshoot Cisco routers and switches using the debug commands

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.

Posted By David Davis