I remember cisco debug commands being a minefield...
Best thing you could do before running them is issue the commands to ensure it doesn't dump to console (and to logs only), but even then some commands would cause spikes in CPU usage and make the CLI sluggish.
"debug spanning-tree all" is another one you don't want logging to console in a switch that's part of a live/prod environment. Every STP broadcast, event, topology change, uplink change or error thrown onto the screen, and getting it to turn off once it's running is almost as bad...
Also a minefield - making sure your colleagues are aware of what debug output looks like and what it means. A former junior associate of mine was running DHCP debug on a pair of campus distribution switches (troubleshooting an IP address allocation issue), another engineer saw it and assumed it was a problem - he responded by rebooting one of them. Thankfully quicker hands managed to stop him from rebooting the other at the same time (which would have taken out the entire site whilst the switches came back up...)
Biting the hand that feeds IT
