Stopping debugs that just keeping going on and on and on

I setup a few eigrp routes and neighbor adjacencies were up, routes correctly learned but when I run the debug eigrp packet command on a specific router, it send lots of nonstop output to the console. I tried u all and undebug all but it goes so fast that it doesn't let me type. Logging synchronous is enabled.
Is there any reason why this would happen? can it be stopped?. I have tried stopping the router and restarting it but doesn't help as soon as i try that command again it screws me over.

this is in GNS3

Find more posts tagged with

Comments

martell1000

try typing undebug all elsewhere and copy and paste it over.
turning off the power should work in the real world - in gns3 i dont know.

if nothing helps just delete this router and get a new one ...

Shanman

MrXpert wrote: »

I setup a few eigrp routes and neighbor adjacencies were up, routes correctly learned but when I run the debug eigrp packet command on a specific router, it send lots of nonstop output to the console. I tried u all and undebug all but it goes so fast that it doesn't let me type. Logging synchronous is enabled.
Is there any reason why this would happen? can it be stopped?. I have tried stopping the router and restarting it but doesn't help as soon as i try that command again it screws me over.

this is in GNS3

Type "u all" Should work for you.

Roguetadhg

Shanman wrote: »

Type "u all" Should work for you.

Damn. He got there first.

Yeah. "Router# u all" will stop the debug flooding.

Forsaken_GA

Sometimes, it just doesn't work, or it'll take awhile to actually go through. Try turning on debug ip packet detail with OSPF fast hellos sometimes...

If you have a 2511 for a term server, then using the send * command to send u all will usually do it, but again, may take some time if the router is busy processing a crap load of debugs (it's receiving packets faster than it can print the debugs).

What I usually prefer to do is just kill the link on the other side of the router that's causing all the traffic. Ie, if you're getting flooded with eigrp debugs, kill the link of the neighbor that's doing the flooding on the neighbors side. When the link clears up, you'll be able to turn debug off. After that, your next step should be to learn how to debug with an ACL

Or if you're local to the hardware, just reboot the damn thing and go take a smoke break.

Roguetadhg

You have exec alias for the * command?

He's doing this in GNS3, so he's definitely local

Forsaken_GA

it doesn't matter if you have aliases or not, when the console or telnet session gets flooded, it just doesn't take any input, particularly in lower end routers with small CPU's. There's a very good reason Cisco sincerely recommends not enabling debugs on production gear. In order to actually debug, the packets have to be processed switched, so it's all hitting the CPU. Any sizeable amount of traffic can spike the CPU to the point where it doesn't care what you think anymore.

I've managed to kill my 3640's with doing ill advised full debugs, and I was remote at the time, so the only choice I had was to shut down all links going to it so that it didn't have anything left to debug hehe

MrXpert

Hey thanks for the suggestion as it made me think more about it. It turned out it was the loopback interfaces that were causing the excessive debugs. I had 9 setup and it kept sending hellos to them. So i reloaded the router and enabled the passive interface command on these. I assume that because the hello time is at the default 5 seconds, by the time the hello to the loopbacks were sent it then repeats as there's alot of them. I changed the hello and hold timers to a higher value like 20 and 60 and that too resolved it.

I learnt an important lesson! don't create too many loopbacks unless of course you either make them passive or increase the timers. I feel like a wally for missing it.

sirisranga

HI , This is a real late reply , but this may be useful for those reading this post in 2017. When I have this problem in GNS3 what i do is type u all in a notepad , copy it and paste it in the session where the debug messages are flooding . It takes one or two tries but it works