What do these commands do?

Now we will run down through each of these commands and explain how they behave,
since scenarios may dictate some deviation from this template.
service timestamps debug datetime localtime msec- Ensures that local router time
is written to all debugs, with millisecond accuracy. This is useful for findin
g calls based on time. Generally speaking, millisecond times allow for you to g
roup debug lines into logical related events when two lines occur within the sam
e millisecond.
logging buffered 10000000 debug- Tells the router to send debugs to its local bu
ffer log in system memory. The buffer size is set in bytes, and is 10 MB here.
The size of the buffer which you may need depends upon call volume, duration of
time the buffer needs to store, system memory still available (leverage 'show m
emory statistic history' and 'show memory summary' for this).
no logging console- By default, the router sends debugs to the console.
the console has the highest priority out of any process. It also runs
slow speeds (commonly 9600bps). Due to this, if debugs are sent to the
aster than the console speed, it can starve console input, and/or cause
to go to 100%.

In IOS,
at very
router f
the CPU

To alleviate this behavior, when running any debugs in IOS, it is imperative tha
t sending debugs to the console is disabled by entering this command.
no logging monitor- This command prevents the router from sending debugs in real
-time to the router's VTY (telnet/SSH) session. Since we will be pulling debugs
reactively, we don't want anything to scroll in real-time. Also, the terminal
monitor has a habit of dropping messages if they arrive in bursts, like most voi
ce debugs do.
default logging rate-limit- By default, the router does rate limit messages.
is is usually recommended to be left on to ensure router stability. If a TAC
gineer suspects that the router is dropping debugs before they make it to the
uter's logging buffer, they may ask this to be increased to a larger value or
sabled. Note that changing this in environments with high traffic volume may
use CPU instability, since it will ensure every debug message makes it to the
gging buffer.

Th
en
ro
di
ca
lo

default logging queue-limit- By default, the router does queue messages, as well
. There is a finite amount of memory the router will store in queue while waiti
ng to be written to the logging buffer. This is usually recommended to be left
on to ensure router stability. If a TAC engineer suspects that the router is dr
opping debugs before they make it to the router's logging buffer, they may ask t
his to be increased to a larger value or disabled. Note that changing this in b
usy environments may cause CPU instability for the same reasons as mentioned pre
viously.
service sequence-numbers- This command writes the sequence number of the debug i
n the line. This is useful (essentially required) when sending to a syslog serv
er, to identify if any debug messages to the syslog server have been dropped i
n the network. The sequence number will be the first item in the debug, before
the timestamp and actual message. Note that this is different from the timest
amp/sequence number may write on the syslog log files, if applicable.