- [Instructor] There are a few different
Syslog troubleshooting options we want to take a look at
from the perspective of a Cisco device.
The most basic syslog configuration is console logging using
the Debug command.
These syslog messages are presented directly
to the console port and they're visible when we connect
to the CLI.
Other than the direct console display,
there are two other main ways
that Cisco devices can store syslog information
and that's either in the internal buffer or this can be sent
to an external storage device.
Buffered logging allows us to record our messages instead
of just displaying those on the console.
We can do that by going under global configuration mode
and we can use the command logging buffered
and if we look at contextual help,
one of the top options that we see is
the logging buffer size.
So you see that we can set that
to a numerical value in bytes.
By default, the buffer size is going to be 4,096 bytes
in most devices and that's pretty small
so if you're using this buffer you'll likely want
to increase that to give you more capacity
and that's going to make sure your logs
aren't getting overwritten as quickly.
So if you're not getting the history that you expect to see
and you're using buffered logging you likely need
to increase the buffer size.
So I'm going to choose 150,000 bytes.
And by the way, the buffer,
that's just part of the internal memory
that's allocated by IOS to store those most recent messages.
You want to know that when you store these here
if we do a device reboot that's going to clear all
of those syslog messages.
So this is really not a good permanent storage solution.
And so that's another consideration
if you've rebooted the device
and you're not seeing those important messages, that's why.
If we look again at contextual help,
you can see that we're now able to select the severity level
of the syslog messages that we're going to capture,
those messages that are going to be set to the buffer.
And those are levels zero through seven.
Note that you can configure this by using
the numbers zero through seven or you can use the name
of the severity level.
So if I want to do, let's say level four, which are warnings,
I can enter either the key word warnings
or I can just enter the numerical value four which
is what I'm going to do here.
And so when I hit answer, now all of the messages
with a severity level of four and lower are going to be logged
to the buffer.
And we see a message here in our console telling us that
the buffer logging the level is set to warnings.
So that's another place you want to examine
if you're not seeing the messages that you expect,
you want to verify that the correct level is configured.
So if you're looking for let's say,
you're looking for level five notifications obviously with
the configuration that I have in place,
these are not going to appear.
So you want to make sure that that's correct
whether we're using buffered logging
as we've configured here or if we're using external logging
the first thing we may want to do is turn off console logging.
IOS is always going to send console logs unless it
is explicitly turned off.
And that doesn't matter if anyone's connected
to the console or not.
It's still going to send those messages.
So turning off console logging can save some resources
on the device.
If we're using stored logs or external logs,
we likely won't have a need for console logging at least all
of the time and we can always turn that back on later
if we do need to troubleshoot but under normal operation,
we probably won't need to do that
and we can disable that with
the command no logging console.
We can view these changes with the command show logging.
And if we do that, we can see right here at
the top we see that console logging is disabled
because we did just disable that.
Something else you see is monitor logging
so that's going to be sent out to the VTY line connections.
And we see that buffered logging is enabled.
We just enabled that and we see that that is at
the warning level just as we would want it to be at.
And if I hit my space bar to complete the output we can see
at the very bottom our log buffer size
is 150,000 bytes which we also configured.
Now, in this particular output,
we have no logs listed and that's
because we haven't received any warnings.
So let's again, run the command, logging buffered 150,000
and this time let's use the keyword debugging.
And that's going to give us all
of our messages levels seven through zero
so if we do that and then we again say, show logging,
notice that now, we have our first message found
within our log.
We have the message that
our buffer logging level has changed.
We changed that to debugging just now
so we can see where that level was changed.
If we had disabled and enabled logging,
we will be able to see that as well
so that's just something that I can quickly do
in my lab environment to show you one
of those populated syslog messages.
That's what those messages are going to look like
in the console output.
Now, if we want to send our logs
to a centralized syslog server for collection,
which by the way is a great idea and that's a best practice
in most cases for an enterprise network,
we can say logging host followed by the IP address
where our syslog collection server resides.
I'm just going to use 10.1.1.50, and hit enter.
Now, our syslog messages are going to be sent
over UDP port 514 to the collection server at 10.1.1.50.
We can similarly configure the severity levels here
with the command logging trap
and context sensitive help again shows us all
of those severity levels.
I'll choose the key word warnings here.
Again, we could use warnings or we could use
the numerical value of four if we wanted to do that.
I'll hit enter.
Once more let's say show logging and notice at the bottom
of our syslog messages we can see some of
that port 514 has started CLI initiated.
We see it tells us we're logging to host 10.1.1.50 as well.
So in this output the places of interest
for troubleshooting are going to be first the log buffer size
so you want to make sure that that's correct
if you're using buffered logging.
We can also see here that we're logging
to host 10.1.1.50, another place you want to double check.
Make sure that the log collection servers IP address
is correctly configured.
If you're sending those externally to a server
and we can see our UDP port again, UDP port 514 is
the common port that's used.
So you want to make sure that this hasn't been changed or
that it matches whatever you have set on
the syslog server itself.
Very important.
With the log messages themselves,
notice these are all timestamped.
We have a date and a time on those messages
so if you're not seeing a correlation between events
and logs that you have available,
make sure you have NTP configured properly on your device
and that the date and time settings are correct.
If you don't see any timestamps at all,
this means they've been disabled with a command
and let me actually type that command out so you can see it.
The command to completely disable those
is no service timestamps.
If this command has been ran then none
of your log messages are going to have timestamps
and that's not going to be very helpful at all.
So you can enable that very simply by taking the no off
the front of that and just running
the service timestamps command and then
the option you want to use at the end of that is datetime.
So that's the common places we would check
when troubleshooting our syslog log collection configuration
on a Cisco IOS device.