Debugs on production equipment

tomsettomset Member Posts: 79 ■■□□□□□□□□
Throughout my studies, I've read many times about how one should not run debugs on production equipment as it may hinder network performance. However, debugs are a valuable troubleshooting tool. So when is it OK to use debugs in production?

Are there any good rules to follow as to when you can and can not use a debug on production gear?
Next up:
CCIP

Comments

  • networker050184networker050184 Mod Posts: 11,962 Mod
    It really depends on the debug. You obviously do not want to debug all or debug ip packet or something like that especially if it is not during a maintenance window. It also depends on the current load on the router. If its running well under capacity you probably won't have any issues with most debugs, but if the device already has high utilization then you will run into some issues. I run them all the time on smaller platforms with little load on them while troubleshooting, but wouldn't risk it on a large aggregation router running 80% utilization already.

    The safest thing is to not run them unless you have to or are in a maintenece window incase the thing siezes up.
    An expert is a man who has made all the mistakes which can be made.
  • Mrock4Mrock4 Banned Posts: 2,359 ■■■■■■■■□□
    I think the best thing you can do is carefully plan your debugs (although sometimes you don't have a choice) so that they end up at times where network traffic is low, and most importantly, target your debugs to cover only the protocol(s) you need to look at, so you don't eat up any more resources then you need to. I've never had a problem with debugging in a production environment, but I've also only used it when there was an issue that had to be resolved immediately.
  • kryollakryolla Member Posts: 785
    run debugs as specific as you can with ACL if possible

    no logging console
    logging buffered increase it if you have to
    show log

    no term mon if you telnet
    Studying for CCIE and drinking Home Brew
  • Paul BozPaul Boz Member Posts: 2,620 ■■■■■■■■□□
    If the device is hosed and you need to run debugs to diagnose the problem let them rip. If the network is experiencing slight issues run debugs after hours. At my last employer an engineer ran a debug command (I forget the specific command) that locked up a 7613. I believe he did a debug IP packet or something like that. There were over 40,000 flows through the box when he did it and it bricked.
    CCNP | CCIP | CCDP | CCNA, CCDA
    CCNA Security | GSEC |GCFW | GCIH | GCIA
    [email protected]
    http://twitter.com/paul_bosworth
    Blog: http://www.infosiege.net/
  • redwarriorredwarrior Member Posts: 285
    Continuously monitoring resources while you run debugs, trying to schedule your debugs for a less busy time (if possible), or even better being as specific as possible and running them just until you have what you need are what I do...even then I've had a device go down once or twice while debugging. icon_sad.gif In short, you have to measure the risks versus the benefits and if something is farking up...you just gotta make sure everyone's aware what you're doing and go for it.

    CCNP Progress

    ONT, ISCW, BCMSN - DONE

    BSCI - In Progress

    http://www.redwarriornet.com/ <--My Cisco Blog
Sign In or Register to comment.