- System message logging, better known as syslog,
is invaluable for any network of any design.
When any event inside of a device,
be it switch, router, AP, server, or other happens,
it can be stored locally,
which can be useful for troubleshooting,
but what can be even more useful
is when these messages
are sent to a centralized syslog server.
These messages can not only be looked at
for event correlation, as with troubleshooting,
but syslog servers can also have triggers set
that when certain matching criteria is met,
notifications can be sent.
Say, for example, many failed login attempts
for one of your routers.
This could be indicative of a break-in attempt.
I also set up syslog notifications
for STP, OSPF, and BGP events.
With BGP, I set up match for each pier
so that my notifications will tell me
which pier had issues and what the issues are.
This has saved me time and energy
when troubleshooting countless times.
By default, Cisco has the logging console
global command enabled.
This spits out various system messages to the console port.
This can be useful only when you are consoled
directly into a device, which, honestly, should be rarely.
To see these same messages remotely,
the global logging monitor command must be enabled.
Then the telnet, or SSH connected administrator,
should enter the terminal monitor exec command
each time they connect to see them.
These local logging messages are stored in RAM by default
and can be viewed by issuing the show logging command.
If I want to send these logging commands
off to a remote host, I issue a global command config t,
logging 192.168.88.12.,
where the IP address is that of the remote syslog server.
An administrator can pick and choose
which types of messages are sent to the collection server.
There are eight levels,
with alert at zero, being the most severe,
down to informational at six, which are the least important.
There is also a special debug message at seven
that is associated with the debug command.
The logging trap level command
tells the local syslog service
which command should be sent to the collection server.
Another great monitoring, troubleshooting,
and sometimes configuration protocol
is the Simple Network Management Protocol, or SNMP.
SNMP is an application-layer protocol
that is used to query devices of all kinds
and request information for long-term trending.
I use it heavily
in conjunction with network monitoring systems
to monitor the port utilization
of every switch and router I have in production.
I also watch the temperature, RAM utilization,
CPU utilization, and how much storage is in use
on each device.
This can aid in troubleshooting,
like when an Internet customer calls
and says they're having issues,
it's often a case of them trying to use more bandwidth
than their port is configured for.
Pulling up an SNMP graph of their interface
will quickly show the utilization over time
to help me diagnose it.
I also set notification thresholds
on CPU usage and temperature,
so that if anything is out of the norm,
I'll get notified often before it even becomes an issue.
Not only can SNMP query, but it can also write,
which gives it the ability to make changes
to some network equipment.
Common uses are to remotely shut a port down,
then enable it again.
Some equipment can also have a port VLAN on a switch
set remotely via SNMP.
FTP is the File Transfer Protocol,
and has been used to transfer large files and small
on networks for a long time.
Another transfer protocol used to move files
is the Trivial File Transfer Protocol.
FTP uses TCP to move packets and can use authentication
where TFTP uses UDP and no authentication.
FTP can be used on more modern and some older Cisco devices,
while TFTP can be used on both old and new.
In my experience, TFTP transfers files
more expeditiously than TFTP.
When I'm transferring large system files
to my ASR 9000 chassis,
I use FTP, as it's much faster than TFTP to the same device.
At one point, I used TFTP
to transfer system running configurations off
for long-term storage,
but I generally use automated systems for that today.
There is a lot of older Cisco kit
that only supports TFTP,
so it's still used off and on, even today.
TFTP and FTP server software is rather light these days,
so it can easily be run
from a laptop or a centralized server.
Without these tools, an administrator is flying blind.
I can't even begin to imagine
where I would start troubleshooting without them.