A new problem has arisen in CCNA class: We have a lab that asks the students to enable a debug command; the debug overruns the console buffer to the extent that commands cannot be entered, and this goes on for more than an hour!

In my 15 years of teaching CCNA classes, we have always taught the dangers of using debug commands on production equipment. To demonstrate this, we would have the students run thedebug ip packetcommand, let it run for 30 seconds, and then turn it off. Of course, turning off the debug is challenging, so we would teach the trick of turning the debug off before we would turn it on: adding theundebug allcommand to our command history buffer.

Running this test on the 2500 series and 2600 series routers would usually cause a crash and a forced reboot. After we changed the lab equipment to the newer ISR 2800 series, the same demonstration no longer resulted in a router crash; however, it introduced a new problem: loss of control of the command line.

The sheer amount of debug messages would cause the command line to be unusable. The debug messages continued to overrun the console buffer for over an hour before we would finally run out of patience and power cycle the router. In a lab scenario, this causes the students to take an excessive amount of time to finish their lab, and for people studying for certifications, it wastes precious study time. A better way to manage debugs is needed. We would like to see the debug messages (they can be very helpful in both troubleshooting and understanding how protocols function), but we would also like to retain control of the command line.

The solution we use today involves 2 command line sessions, either 2 vty (Telnet or SSH) sessions, or 1 console and 1 vty session. By default, the console processes logging messages at the debugging level. These settings can be verified with the commandshow logging:

We can change the level of Syslog messages sent to the console with thelogging consolecommand. The level of logging can be set to the following:

• Emergencies (level 0)
• Alerts (level 1)
• Critical (level 2)
• Errors (level 3)
• Warnings (level 4)
• Notifications (level 5)
• Informational (level 6)
• Debugging (level 7)

We only want to stop the debug messages, so we will set console logging to Informational.

Notice the monitor logging is "level debugging" If we enable debugging now, no messages will be sent to the console. In our lab scenario, we have a PC running in a virtual machine, we will establish a Telnet session to the router from this PC, and we will send the debug messages to that Telnet session.

In order to see the debug message in the Telnet session, type the commandterminal monitor.Debug messages are now sent to the Telnet session-they will not be seen on the Console session. We can use the Console session for command and control, and we can use the Telnet session for monitoring. If we lose control of the Telnet session, we can terminate the session with theclear linecommand; use theshow userscommand to determine the line number to clear:

This method has proven to be very useful in our training classes. Hopefully it will be useful to others as well. Please be careful to review the policies of your organization before implementing this solution; there are many organizations that will not allow you to debug in production environments. If your organization has other methods for solving this problem, I would be interested in hearing about them. I'm also interested in knowing how many of you are allowed to debug in production and how you use it to help you solve problems

About me:
I'm Bryan Baize, a Senior Technical Trainer at Boson Training in Tampa, Florida. I have held the Certified Cisco Systems Instructor Certification since 2000. You can connect with me on Twitter at @bbaize