Importance of debug and where to

Maybe this is my bad, but all the way through my CCNA, CCNP, and even CCIE R&S Written studies I haven't used the debug commands often or at all.  I felt most of the time I could get away with finding the information I needed to know with doing the different "show" commands.

Personally, what I think turned me off to debug is all the information that it puts out, and the stress of typing "u all" when my screen is being overrun.

There is also the problem of debugging locking you out of the console.

So now that I am studying for the CCIE R&S Lab:

1) How important is it to really know and use debug?  Is it absolutely essential for troubleshooting section?

2) Where do you think you can get away with just the "show" commands, and where is debug required?  (i.e. ... in trunking and STP "show" commands are enough, but in PPP you really need to use debug).


Thanks for your thoughts!


PS: I really did not see a high level discussion on this topic when I searched the forums ... if there is one, and I missed it, thank you for the link if you have it.


  • peetypeety ✭✭✭

    I survived the R&S lab with very little knowledge of debug as well.  However, I would say there are a few places it's useful:

    1) I'm slowly becoming a big fan of leaving 'debug spann root' enabled on switches.  Otherwise, STP root convergence is a silent event. If root is moving around "a lot", you're still only talking once a minute at most with legacy STP, and if you have root moving more often than that in RSTP, you might deserve to have a flood of console info.

    2) I think there's a hack to decrypting certain keys but I honestly can't remember what keys or how.

    3) In the CCIE lab, I was a big fan of 'debug ip routing' - it's both a great way to know that redistribution is happening, and a great way to know that redistribution is going haywire.

    I would also point out that in the lab I'd always do 'logg cons deb' just to be sure I'd see the debug output. In the real world, I'm trying to get to a level of comfort with "logg cons inf / logg buff 256000 deb / logg mon inf". If I need to see a debug, I temporarily add 'logg mon deb' and revert it to 'logg mon inf' when done. One advantage of dumping debugs to the logging buffer is the ability to do 'sh logg | include <blah>', so that could be a good alternative to huge volumes of data.

    I felt that the TSHOOT section was fully doable without debugs (except for the bug I encountered on one of the IOU switches...grrr.)

  • I agree with peety. You don't have to be an expert on debbuging but it's important that you know what to expect from an output.


    deb ip routing is fundamental because it helps you to find advertisement loops in redistribution, so if you think your topology is stable... you doesn't expect any outputs at all.


    If you expect lots of outputs, maybe debug ip packets kind of stuff, send just to the buffer to filter as peety said. To troubleshoot with BackBones debug is awesome because in the real exam (and in real life) yo doesn't have any access to remote equipment so debug it's your best friend to say you're OK (and in real life... other endpoint is wrong). 


    The lesson in this, try debugging just to familiarize with the outputs, what information can you get and the parallel or similar with show outputs and you'll find out that debbugging can save lots of time in the exam and in real life.



  • I was always wary of debugs, as I had it drummed into me as a junior engineer that you should never run debugs on production kit.

    I did find a few debugs useful during CCIE study. debug ip rip was quite handy when you're doing filtering of routes advertised to say a backbone router, and the only way to check it is by using debugs to see what is actually being advertised. There's also a few useful BGP debugs that can help with understanding what's going on.

    My advice would be to watch the ATC videos, and note the debugs that Brian uses. If you're working through an exercise, and you don't quite understand some of the behaviours, try some debugs, to see what's going on.

    But don't worry too much about it if you don't figure out every single debug option. The commands themselves are occasionally a bit weird - some things aren't where you expect them to be. 


  • Has anyone here managed to take a router out with debugs?  It seems to be conventional wisdom that "some debugs" can kill a router (or at least console session) the the router is moving a lot of packets.  Obviously it might not be wise or useful to run an un-ACLed "debug ip packet detail" on a router with a few heavily loaded 10 Gige ports on it, but I've never managed to cause any issues running most debugs, and I have to admit that I use them fairly often, though the scope of what I'm debugging is usually fairly small - PPP and DHCP come to mind right away.

  • Not so much locking up the router, as being unable to control the session, and unable to stop the debugs.

    I have not killed a production router myself, but I do know people that have. It was with some crazy amounts of debugs though, and it was 10+ years ago. You're normally fine with a bit of PPP stuff, but I know several networks where I would almost NEVER get approval to run any debug on production. (Change management, etc). Whether that still makes sense is a different question. Attitudes are hard to change.


  • I wonder if someone has ever done an "accidental" debug all on a prod router...that would really melt down the device.

  • Hi Boatman


    First off you have done a good thing by using, relying and getting used to the many show commands as verification is incredibly important.  Debug is also an important tool and you should try to use it more as it can be incredibly helpful in many situations and flat out tell you exactly what is wrong.


    If you are worried about flooding a console or even causing a distraction then use the buffer:


    logging buffer debug

    logging buffer 99999


    If you are using the console then configure logging sync on your console line or vty lines as this will cuase the debug to not overwrite anything you are typing which makes it difficult to know where you are if you are trying to use commands or do config changes.


    There are many great situation where debug is incredibly useful.  A couple that spring to mind are:


    1) debug ip routing - use this on redistribution points.  You can quickly identify route feedback and loops if you are seeing routes constantly being withdrawn, readvertised, replaced with a better AD etc

    2) debug ppp authentication and debug ppp negotiation - Without this it is very difficult to troubleshoot PPP issues.  Sure you may be able to look at the config for this.


    Others would include routing protocol adjancies that will inform you of mismatched parameters, mismatched authentication.

    Like anything and everything if you introduce these into your studies and use it as part of learning a technology you will understand the technology better and be better equipped for both the config and TS sections.


    I remember being told the importance of the DocCD.  So whenever I have a problem I ALWAYS use the Doc CD to either read up the config section or lookup the command reference rather than google.  Doing this I believe I learnt more and have become very comfortable using the DocCD which I used successfully on two occassions in a recent albeit failed lab attempt.



  • Ok,

    To recap what I have learned so far ...

    1) Watch ATC videos ... follow Brians debug commands

    2) DocCD DocCD DocCD ... Home Page set to Cisco--> Support  --> Configure

    3) #line con 0, #logging sync ... I can't imagine a world without this command ... aww, the horror


    # debug spanning-tree root

    # debug ip routing

    # debug ppp authentication

    # debug ppp negotiation


    # logging console informational

    # logging buffer [big number = 99999] debug

    # logging monitor informational


    Ok, so here is my question ... What is fundamentally the difference between logging to the console and to the buffer?  The messages still show up on the console screen both ways, right?  Does the router store them differently?  Without going to something like a TFTP/Syslog server ... can a store a debug to a file, and then read the file directly from a router?  And would I want to do that during the CCIE lab, or would it just take way to much time?

    I feel like I missed that Class / VoD labeled ... "Fundamentals of debugging".

  • Without logging buffered, the "show log" buffer output is empty.

    From cisco:

    The logging buffered global configuration command
    copies logging messages to an internal buffer. The buffer is circular,
    so newer messages overwrite older messages after the buffer is full. To
    display the messages that are logged in the buffer, use the show logging
    privileged EXEC command. The first message displayed is the oldest
    message in the buffer. To clear the contents of the buffer, use the clear logging privileged EXEC command.

    To disable logging to the console, use the no logging console global configuration command. To disable logging to a file, use the no logging file [severity-level-number | type] global configuration command.

  • What you need to remember with logging is you have control over which level of messages get logged to each output and you control these seperatly.  So you must configure them seperatly with the appropriate command, logging console, logging terminal (vty) logging buffered


    You can also log to a file but I wouldnt recommend that for the lab, for production its handy especially if you have no centralised syslog.


    There is a danger with logging to the console that you can overwhelm the console and lock yourself out so have in mind a plan if that happens:


    Either a) reload in 5 (also good if you are configuring aaa)

    b) if debuggging ppp do I have control of the other end in which case I can shutdown the link and free the console on the locked device


    Don't be too scared of loggin to the console, yes I have been burnt but only one one occasion out of thousands.


    Another +1 of why you need to use dedbug if for tasks that have you work with an external server that typically doesn't exist e.g. please configure rmon to monitor the Unicast packets on Serial 0/0/0. If the packets increase by 10000 in a minute then send an snmp trap.  To fully verify this you would include debug snmp packet so you can see it the trap being sent even though the server doesn't exist.



Sign In or Register to comment.