How to (more) safely run debugs on Cisco routers

Contributed by abanks

December 15, 2006

Tagged: Cisco router

Running debug commands can bring a busy router to a crawl. Not sending the output to the console can help. This tech-recipe describes turning off console debugging output and techniques for viewing debug information in a router-friendly way.

Some debug commands, like debug ip packet detail
can cause a router to stop responding while it attempts to display all the data you’ve requested. Frequently, it’s trying to force a lot of data down a 9600 baud (slow) console port.

So, we can turn this off!

config t no logging console

But, now debugs are not very useful, since they won’t display. We can telnet to the router, then

terminal monitor

to send all the debug output down the pipe to the telnet client. Better, but this can still backfire.

We can just push all the messages to a buffer:

logging buffered

then view them with

show log

Another option which will make some debug commands, like

debug ip packet

safer is to specify an access-list for just the traffic you want. For example:

access-list 100 permit ip any host 1.1.1.1 access-list 100 permit ip host 1.1.1.1 any

debug ip packet detail

Will give you IP packet detail for any packets coming from or going to a host with ip address 1.1.1.1.

Previous recipe | Next recipe |

Viewing 1 Comment

AWfki 6 months ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

The last command in this example is incorrect as it doesn't use the access-list that's been defined. The last example should be:

access-list 100 permit ip any host 1.1.1.1 access-list 100 permit ip host 1.1.1.1 any debug ip packet detail 100

Note the 100 at the end of the debug line. That applies ACL 100 to the debug. Without that you risk choking the router if it's at all busy.

reply edit reblog flag