The ``terminal monitor'' command directs your cisco to send debugging
output to the current session. It's necessary to turn this on each time
you telnet to your router to view debugging information. After that,
you must specify the specific types of debugging you wish to turn on;
please note that these stay on or off until changed, or until the
router reboots, so remember to turn them off when you're done.

Debugging messages are also logged to a host if you have trap logging
enabled on your cisco. You can check this like so:


        sl-panix-1>sh logging
        Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
            Console logging: level debugging, 66 messages logged
            Monitor logging: level debugging, 0 messages logged
            Trap logging: level debugging, 69 message lines logged
                Logging to 198.7.0.2, 69 message lines logged
        sl-panix-1>

If you have syslog going to a host somewhere and you then set about a
nice long debug session from a term your box is doing double work and
sending every debug message to your syslog server. Additionally, if you
turn on something that provides copious debugging output, be careful
that you don't overflow your disk (``debug ip-rip'' is notorious for
this).

One solution to this is to only log severity ``info'' and higher:

        sl-panix-1#conf t
        Enter configuration commands, one per line.  End with CNTL/Z.
        logging trap info

The other solution is to just be careful and remember to turn off
debugging. This is easy enough with:

        sl-panix-1#undebug all

If you have a heavily loaded box, you should be aware that debugging
can load your router.  The console has a higher priority than a vty so
don't debug from the console; instead, disable console logging:

        cix-west.cix.net#conf t
        Enter configuration commands, one per line.  End with CNTL/Z.
        no logging console

Then always debug from a vty.  If the box is busy and you are a little
too vigorous with debugging and the box is starting to sink, quickly
run, don't walk to your console and kill the session on the vty.  If
you are on the console your debugging has top prioority and then the
only way out is the power switch.  This of course makes remote
debugging a real sweaty palms adventure especially on a crowded box.
Caveat debugger!

Also, if you for some reason forget what the available debug commands
are and don't have a manual handy, remember that's what on-line help
is for. Under pre 9.21 versions, ``debug ?'' lists all commands. Under
9.21 and above, that gives you general categories, and you can check
for more specific options by specifying the category: ``debug ip ?''.

As a warning, the ``logging buffered'' feature causes all debug
streams to be redirected to an in-memory buffer, so be careful using
that.

Lastly, if you're not sure what debugging criteria you need, you can
try ``debug all''. BE CAREFUL!  It is way useful, but only in a very
controlled environment, where you can turn off absolutely everything
you're not interested in.  Saves a lot of thinking.  Turning it on on
a busy box can quickly cause meltdown.