The smart-ass answer is that Cisco do not recommend the use of the debug command in production networks.
Really! How could it be otherwise?
Some debugs are suitable for use in production but it is pretty much left up to the Network Engineer to evaluate each use of debug themselves.
Did you follow the debug guidelines?
no logg console ! or logg level < debugging at least
If I thought there was the slightest risk add: no logg monitor ! or logg level < debugging at least no logg trap ! or logg level < debugging at least
!! also don't log to snmp whatever command that is.
so we log only to the buffer, the cheapest option.
logg buffer debb logg buffer 50000 ! if we have enough memory
Then consider just how your debug may affect the router.
Use available tools to limit the number of log messages.
It the end of the day, if a router or switch has not got enough CPU to process spanning tree messages then the network may well break. Debug is designed to be as good for troubleshooting as possible, this means that it HAS to be more important for the CPU to do debug than it is to do spanning tree. We are back full circle, debug is not supported in production.
You could manually shutdown the interfaces that could cause loops.
MST will fall back to spanning tree under some conditions - usually when the
2 switch ports decide they are not both MST compatible.
"raw" spanning tree doesnt block ports with some 1 way link problems - and a
1 way loop is just as good a broadcast overload generator as the ordinary kind.
Also if you manage to build a working loop and the load makes the CPU hit
100% it may end up stuck in that state - although Cisco IOS /CatOS seems better than some other switch code for this.
My preference is to use L3 design to get rid of spanning tree.
If you have to put up with it for some reason, uni directional link detection (UDLD) can get rid of the most common 1 way faults. Note - Cisco special so not feasible if you have other manufacturers kit.
But it is worth remembering that spanning tree mostly works well, but it works by actively suppressing loops when only when all ports around the loop work in both directions, so if something goes wrong the failure is likely to cause an active loop
The cause of the CPU problem was your debug command. Please see the previous post. If you spike the CPU because of debug command flooding the console with debug messages, or because the debug command you entered requires significant CPU to process, you will still bring that device down, layer 2 or layer 3 switch/routing not withstanding.
Yes, that's clear, but the question was that is there a way to protect the rest of the network in case of one switch's CPU overload. I have now configured spanning-tree loopguard to all root- and alternative ports and debug-commands will not be used any more...