+ Reply to Thread
Results 1 to 9 of 9
  1. Senior Member MrXpert's Avatar
    Join Date
    Apr 2011
    Location
    England
    Posts
    577

    Certifications
    A+, Net+, Security+,ITIL,CWTS,CWNA, CCENT,CCNA,CCNP
    #1

    Default 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
    Reply With Quote Quote  

  2. SS -->
  3. Senior Member martell1000's Avatar
    Join Date
    Apr 2011
    Posts
    386

    Certifications
    CCNA, CCENT, CCNA:SEC, CCNP
    #2
    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 ...
    Reply With Quote Quote  

  4. Senior Member Shanman's Avatar
    Join Date
    Jul 2011
    Location
    Michigan
    Posts
    223

    Certifications
    Network+, MCP (70-270), CCENT, CCNA, CCNA Security, CCNP R&S
    #3
    Quote Originally Posted by MrXpert View Post
    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.
    Reply With Quote Quote  

  5. Matrix(Config)# Roguetadhg's Avatar
    Join Date
    Jan 2012
    Location
    SC
    Posts
    2,380

    Certifications
    #Cisco: NA #CompTIA: A.N.S
    #4
    Quote Originally Posted by Shanman View Post
    Type "u all" Should work for you.
    Damn. He got there first.

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

  6. Senior Member
    Join Date
    Aug 2008
    Posts
    3,951
    #5
    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.
    Reply With Quote Quote  

  7. Matrix(Config)# Roguetadhg's Avatar
    Join Date
    Jan 2012
    Location
    SC
    Posts
    2,380

    Certifications
    #Cisco: NA #CompTIA: A.N.S
    #6
    You have exec alias for the * command?

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

  8. Senior Member
    Join Date
    Aug 2008
    Posts
    3,951
    #7
    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
    Reply With Quote Quote  

  9. Senior Member MrXpert's Avatar
    Join Date
    Apr 2011
    Location
    England
    Posts
    577

    Certifications
    A+, Net+, Security+,ITIL,CWTS,CWNA, CCENT,CCNA,CCNP
    #8
    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.
    Reply With Quote Quote  

  10. Junior Member Registered Member
    Join Date
    Jun 2017
    Posts
    1
    #9
    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
    Reply With Quote Quote  

+ Reply to Thread

Social Networking & Bookmarks