- [Instructor] On a Cisco device,
we have a few different options for syslog Configuration.
The most basic of those is using Console Logging,
which we've examined when we're using the debug command.
The syslog messages are presented directly
to the console port and those are visible
when we're connected to the COI in that manner.
Other than direct console display,
there are two main ways that Cisco devices
can store syslog information.
They can do those either in the internal buffer,
or they can send those to an external storage device.
If we use buffered logging,
that's going to allow us to record our messages,
instead of simply displaying those in the console.
And 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,
you'll see that we can enter a buffer size
in a numerical value,
which is going to be listed in bytes.
Now by default, the buffer size
is going to be 4,096 bytes, which is pretty small.
So, if you're using the buffer,
you'll likely want to increase that
to give you more capacity
in order to make sure that those logs aren't getting
overwritten quite as quickly.
I'll choose 150,000 bytes in this example.
And if we look at contextual help again,
I want to point out that now we're able to select
the severity level of our syslog messages
that are going to be recorded to the buffer.
And the buffer, by the way,
that's a part of the internal memory
that's allocated by iOS in order to store
the most recent messages.
You'll want to know that when we store these here,
if we reboot our device,
that's going to clear all of those syslog messages out.
So, this is not a good permanent storage solution.
Also, the buffer size is limited
so those older messages can be quickly overwritten
if we're not careful.
So in this output, again,
we can see that we're able to configure
those severity levels
that we mentioned in our syslog theory video
levels zero through seven,
you can use the name of the severity level,
or you can use the number.
So in this case, in this example,
I'm going to choose level four, which are warnings.
So I can enter either the number four or I could say,
"Warnings" as the key word.
I'm going to choose warnings and I'll hit enter.
Now, all of the messages
with a severity level of four and lower
are going to be logged into the buffer.
Now remember, these numbers are a bit counter intuitive,
lower numbers are more critical.
So when I say that,
I mean that all of the messages with a severity level
of level four warnings,
and those messages which are more severe.
So levels, zero through four,
those are all going to be logged into the buffer.
If we're looking at using buffered or external logging,
the first thing we might want to do
is to turn off console logging.
The thing about console logging
is that iOS doesn't check to make sure
whether or not anyone's actually connected to the console
before it outputs console logs.
So it's just always going to send console logs by default,
unless we explicitly turn that off.
So that could use up some of our system resources,
especially on older devices.
So if we're storing our logs,
we likely won't have a need for console logging.
Now, we can always turn that back on
if we need to watch troubleshooting.
But under normal operation,
if we're using this sort of centralized logging,
we probably don't need console logging.
So, we can just simply say, "No logging console,"
to turn console logging off.
We can view our changes by saying, "Show logging."
By the way, I use the Do keyword here
to allow me to do that under global configuration mode,
just simply so I don't have to go back to Exec mode.
So if I hit Enter,
and we let that command finish,
you can see that we also have something called
monitor logging, which we haven't mentioned yet.
Monitor logging is simply going to send out
information to the vty line connection.
So that's what that is.
We see console logging is disabled,
because we did in fact, disable that.
We can see down here that our log buffer size
is listed as 150,000 bytes.
So that's exactly what we configured.
We see that buffer logging is listed here.
And that the syslog severity level that we're logging
are from the warning level.
So, everything that we configured,
it looks like that's in place,
just like we would expect.
Now notice, out here in the log buffer,
we have the colon at the end of that,
if we had log messages in that buffer,
those would be displayed here.
But our buffer has no messages currently,
because we haven't received anything
from the warning level or higher.
Let's go back and let's change that.
Let's again run the command,
logging, buffered 150,000.
And this time instead of warnings,
I'm going to say, "Debugging."
So this is going to give us all levels of logging,
everything that we do should be logged
into our log buffer now.
So, I'm actually going to turn console logging back on
by saying, "Logging console."
Then again, I'll turn it right back off by saying,
"No logging console."
Notice that we did get a console message in here
when I turn that back on.
Now, what's going to happen if we say, "Show logging?"
Now you can see that again, we see our log buffer,
the level has changed to the debugging level.
So we're going to capture everything.
The log buffer size we see is still 150,000 bytes.
But this time, we do have some messages in that log buffer.
And that's because we turned on lower levels of logging.
Our buffer now has messages stating that,
we can see where we changed the level to debugging.
We can see where we turned console logging on.
And where we turned it right back off when we disable that.
So, that's what it will look like
with that log buffer populated.
If we want to send our logs
to a centralized server for collection,
which by the way, is a great idea,
and it's a best practice, in most cases,
for an enterprise network,
we can use the command logging host.
And we can follow that up with an IP address
for our syslog collection server.
In my case, I'm just going to put in 10 dot one
dot one dot five,
and I'm going to hit Enter.
And now our syslog messages will be sent
over UDP port 514 to our collection server
at 10 dot one dot one dot five.
Now we can similarly configure
which severity level we want captured here
with the logging trap command.
And if we look at contextual help, again,
we see those same options,
those same severity levels.
We can use the numerical format or we can use the key word.
This time I'll just choose the numeric format of four,
which is going to set us at the warning condition level.
I'll hit Enter.
Once again, I'll say "Do show logging,"
to take a look at that.
And now at the bottom of our output again,
we do see some messages in our log buffer,
just because that's still set to the debug level.
But notice here that we do see trap logging is now enabled.
And we have that set at the warning level, level four,
just as we want.
We see that the logging is going to be logging
to 10 dot one dot one dot five,
which is the external server that we configured.
And we see that that's also happening over UDP port 514.
So, we can very easily point this to an external server.
And we can also very easily do this
for multiple collection servers.
If we want to do that.
Maybe you want to have multiple servers set up
to collect different levels.
So maybe you have a server collecting
only debug information.
While you have another server dedicated
only to critical messages.
So, lots of ways that you can sort your data,
lots of possibilities there.
So, that's a look at how we can use syslog
to gather information for managing
and troubleshooting our networks.