Defending Your Console

Bryan Baize
In all 15 years of teaching CCNA classes we have always stressed the dangers of using production equipment debug commands. To demonstrate, we would ask students to run the debug-ip packet command. Let it run for 30 seconds and then turn it off. We would also teach the trick to turning off the debug before turning it on. This would involve adding the undebug all command into our command history buffer.
This test would normally cause a crash and a forced restart on routers of the 2500 and 2600 series. The same demonstration did not result in a router crash after we switched to the ISR 2800 series lab equipment. However, this new configuration introduced a problem: loss control over the command line.
The command line would become unusable due to the sheer volume of debug messages. The debug messages kept running for over an hour, until we finally ran out of patience and had to power cycle the router. This can cause students to take too long to complete their labs. For those studying for certifications, this can also lead to wasted time. It is necessary to find a better way of managing debugs. We would like to be able to see debug messages, as they can be very useful in troubleshooting and understanding protocols’ functions. However, we also want to keep control of the command-line.
Today’s solution involves two command line sessions. These can be either 2 vty sessions (Telnet, SSH), or 1 console and 1 session. The console processes debugging messages at the default level. These settings can be checked with the command show log:

The logging console command can be used to change the level of Syslog messages that are sent to the console. You can set the level of logging 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 want to stop debug messages so we will set console log to Informational.

Notice that the monitor logging setting is “level debugging”. If you enable debugging now no messages will be sent. In our lab scenario, a PC is running in a virtual machine. We will create a Telnet connection to the router using this PC and then send the debug messages.

To see the debug message in the Telnet sessions, type the command terminal monitor. The debug messages will now be sent to the Telnet session. They will not be visible on the Console session. The Console session can be used for command and control and the Telnet session can be used for monitoring. We can terminate the Telnet session if we lose control of it using the clear line command. To determine the line number to clear, use the show users command.

This method has been very effective in our training classes. It is hoped that others will find it useful. Before you implement this solution, please review your company’s policies. Many organizations won’t allow you to debug in production environments. I’d be interested to hear about any other solutions your organization may have. I would also like to know how many people are allowed to debug in production, and how you use it.
About me:
Bryan Baize is a Senior Technical Trainer at Boson Training, Tampa, Florida. Since 2000, I have been a Certified Cisco Systems Instructor. Follow me on Twitter @bbaize