In my experience, 80% of the time I receive debugs from a syslog server, they contain dropped messages and render an accurate analysis impossible one can observe this behavior when sequence numbers are enabled on the IOS side. Typically only 10-20% CPU overhead is needed for even the most verbose debugs. I'd never recommend enabling ' debug all' in any real-life circumstance since the majority of the messages will be rate limited and dropped before being logged, but it demonstrates how effective disabling the console/monitor and rate/queue limiting allow for verbose debugs to run stable on a busy router. To prove the point that it is safe to run IOS debugs in production with this recommended configuration, I am able to run ' debug all' (yes, that's every debug IOS is capable of running) in my lab on a CME with 300 registered phones and only bring the CPU impact up by 40%, when default rate limiting and queuing are enabled. That being said, due diligence is recommended when turning debugs on in production, so keep an eye on ' show processor cpu history' when enabling debugs one-at-a-time to ensure there is minimal impact. If you don't want to understand the concepts and want to just know what commands to enter, just use the 'Recommended Configuration' section below.ĭebugs can be run safely in almost all environments where voice runs on an IOS router. The purpose of this document is to de-mystify and clarify these conceptions. It is quite often that someone is concerned about running debugs on a production gateway, thinking that it may cause performance impact. What do I do if the router is too busy, and I can't pull debugs for an issue before the log overwrites itself? Why can't I just log to the monitor with ' terminal monitor'? I don't think I need this I debug to a syslog server. Is running debugs safe to do on production routers? How to properly and safely collect debugs on an IOS router
0 Comments
Leave a Reply. |