Our on-course syslog discussion, folks, is not much different than CCNA. That's why we
decided to have it as a recorded video here. So, we're going to go through a lot of the
same things you learned in CCNA and be ready for questions on the exam pertaining to syslog
at a pretty high level, meaning a pretty fundamental level when it comes to syslog configuration
and verification. So, what is syslog all about? Syslog is used for monitoring and auditing
purposes. Think of your device and the fact that there are going to be times when events happen.
What do I mean by an event? Well, an event is a change of state. So, like an interface going up,
an interface going down, that is a change of state. And when that change of state happens,
there could be other events that occur, changes of state as well. And it is imperative that we
get notified about those changes of state, about those events. So, for example, in this case,
interface gigabit ethernet 1 slash 0 has been shut down. So, that's a change of state. We've
gone from up to down. And you'll see just based on that, we've had three syslog messages generated.
We had one message generated from EIGRP that has indicated that we've lost our neighbor adjacency
because the interface to reach that neighbor is now down. And if we look at these two bottom
messages, it says that gig 1 0 has been changed to administratively down because somebody typed
the shutdown command. And then line protocol has now been changed to state down as well. So,
our interface is now down, down. And we've lost our EIGRP neighbor adjacency. So,
that's what syslog does for us. It gives us the opportunity to get notified about those changes
of states, about those events. And who deems what the events are? Well, that is Cisco on Cisco iOS.
Now, there are devices out there, some Cisco products out there where you could actually
change syslog messages. You could change severity levels about them. You can manipulate them. But
Cisco iOS doesn't allow you to do that. So, what Cisco gives you is what you get when it's all said
and done. Now, when you cover EEM and vetted event manager, you'll see that you can create some of
your own custom syslog messages for specific events. So, that is where you can actually do
that. But you can't just change the syslog messages right on the device. You would have
to use EEM for that instead and create your own custom syslog messages. So, syslog is enabled by
default on all of our Cisco products. And syslog messages by default will go to the console port
to go to the VTY lines. And they'll even be sent to RAM. Now, the problem with all three of those
options is that they are temporary in nature. That's right. So, for the console port, you have
to be connected to the console port when that message is generated to see it or you will not
see it. Likewise, with the VTY lines, you have to be connected to the VTY lines when that syslog
message is generated or you are not going to see it. With RAM, well, it's only so large. There's
only so much memory available for it. Now, you could adjust the size of the memory. But don't
forget, if you adjust the size of the memory of RAM, then what you are taking away RAM from other
resources on the device or other services that need that RAM on the device. So, the recommendation
and the best practice is to what? Have a server set up in your environment somewhere.
And that server would be what? A syslog server. And what you're going to do is you're going to
set up your device to send syslog messages to that syslog server. So, that way there,
it can amalgamate all those messages central on that particular server. So, a syslog server is
a centralized repository that will gather and collect or collect and gather all of those syslog
messages from all the different devices that you have. Also, severity levels, which you're going
to have to memorize for the certification exam. So, if you memorize them for CCNA and you forgot
what they are, you're going to have to memorize them again for Encore. So, let's talk about how
we read our syslog messages. So, when we read our syslog messages, we start off here with our date
and time. Now, if you're not seeing the date and time, it's because you don't have it turned on
for your particular device. So, for example, in R1 right now, if I type in configure terminal and we
exit out, there's a syslog message generated anytime you go back to privilege exec mode.
You'll see that there's a date and time stamp there. So, that is showing up because I have
timestamps enabled for my log messages. So, let me type in here no service dash timestamps. No
service space timestamps. Okay. Now, you'll see when we exit back out, there is nothing showing
up there. So, if that is what you got and you want to see your timestamps and your log messages,
then you would type in service timestamps and then you would specify for what. So, I want to
set it up for my log messages and I want it based on what? Based on my date, based on my time
instead of my what? My uptime. So, the last time the device rebooted, that's what uptime would be.
Right now, when we exit out, you're going to see we have our timestamp there. One thing I want you
to realize is that the timestamps on our devices are going to be based on what? Based on UTC
time. Okay. UTC time, not local time. So, if I type in show clock right now,
right, this is UTC time. So, let's go ahead and configure, like we did in our NTP discussion,
our time zone command. So, if I type in clock time zone and then we'll say minus four zero. Oops.
Let's put Atlantic Standard Time four zero. Right. And I'm not going to do the summertime option
right now. I don't care about that because I just want to show you now. If I type in show clock
and you compare the clock to the syslog messages, notice that the syslog messages are still in UTC
time. Whereas the clock is now in Atlantic Standard Time, as an example. So, what we want
to do is, if you want to, if you want to, if you want these syslog messages to show the local time,
then you need to put this command in. So, service timestamps log date time, but then type in at the
end local time. When you type in local time, you'll see that the syslog messages now use the
local clock's time, not UTC time. Just something to keep in mind. So, if you're looking at messages
and the times don't match or you're looking at a scenario and the times don't match,
why are my syslog messages, why don't they match my actual clock? Well, it's because your clock's
UTC or your clock is, I should say, set to use your local time as opposed to UTC time and your
syslog messages default to using UTC time. So, if you want local time for the syslog messages as
well, you have to add the local time command to your service timestamp. Notice how we have a star
here with these syslog messages. Notice how in my case, I have a period with these syslog messages.
What does the star mean? What does the period mean? All right. Well, the star symbol means
time is not authoritative. Time is not authoritative. It means that the software
clock is not in sync or has never been set. It's not in sync or it has never been set. So,
the star, the asterisk before the local time indicates that the time may be incorrect
because the system clock has not synchronized to a reliable time source. That's what a star means.
Okay. But what does the period mean that we see? So, the period means that the time is authoritative.
Time is authoritative, but NTP is not synchronized. That's right. The period means time is authoritative,
but NTP is not synchronized. So, the software clock was in sync, but has since lost contact
with all configured NTP servers. That's right. So, if you see the period, it means that
it's authoritative, but NTP is no longer synchronized. That's what the period means. Period.
And so, I made this happen on purpose so I could show you this because in our NTP discussion,
previously, we synchronized everything up. Well, I forced it to unsync so I could show
you this particular period. What if you don't see a period? What if you don't see a star?
What if you see nothing? What does that mean? Let's see if I have that example of that here.
No. All right. If you don't see anything, no period, no star, what does that mean?
It means that time is authoritative and the software clock is in sync.
Is in sync. Or it's been manually set with the clock set command.
Back to reading this. So, you have your time. What's next? Next, you have your facility
and there's going to be a new facility that you're going to install.
So, what information do you have, especially what's going to happen when you install a new facility?
What is located where? It's what's located on what's going to happen when you're installing
a new facility? This is a video on how to install a new facility,
your facility. So, this is our facility. This is our facility. This is our facility.
The facility is the service or the function that triggered the message. So, the source of
the message. So, dual in this case is EIGRP triggered it. Link is layer one. Line protocol
is layer two. You then have your severity levels. You then have your severity levels.
So, five is a notification. Six is informational. Seven is debug. Four is warning. Three is errors.
Two is critical. One is alert. Zero is emergency. It doesn't hurt to memorize that for the exam,
even at the CCNP level. Every awesome Cisco engineer will need ice cream daily. That helps.
Great. If not, don't worry about it. Every awesome Cisco engineer will need ice cream daily.
Zero, one, two, three, four, five, six, seven.
Next, we have what is called a mnemonic. This is our mnemonic. Mnemonic.
Mnemonic. Mnemonic. Mnemonic. And essentially, what it is, is a device-specific code that
uniquely identifies the message. So, a neighbor change or a change or up, down. It really depends
on the scenario and situation which shows up there. And then lastly, you have your description,
your message. So, in this case, it says EIGRP for IPv4 autonomous system number 100 has a neighbor
of 10.0.12.2, a gigabit Ethernet one size zero, and it is down. Why? Because the interface is down.
This particular message says interface gigabit Ethernet one size zero has changed state to
administratively down. Why does an interface go administratively down? Because somebody typed the
site down command. And then lastly, this one is lying protocol on interface gig one zero changed
state to down. So, we're down at layer two, down at layer two, down at layer one, and EIGRP is now
down as well on that interface. All right. So, when we look at our messages in our console,
I'm just going to type in right now debug IP OSPF hello, just so we can see our debug messages.
All right. This is the console. I'm connected to the console right now, folks. And by default,
those messages appear on our console. Notice I have no timestamps for debug because when I typed
in timestamp log, log does not include debugs. If I wanted debugs and my log messages, I would
have to type in service timestamps. Debug means all of them, daytime local. So, let me do that
right now just to show you. So, configure terminal. Just in case you were wondering, hey, why is there
no timestamps on the debugs? Because we did not type in debug. Instead, we just typed in log.
Debug. Let's do that again. Debug. And you'll see that the timestamps are going to start showing up
now. There you go. That's the only reason why they weren't. All right. So, with that in mind
now, this is the console port. We're seeing what's happening at the console port. Pretty
straightforward. Now, let's go to DSW1 and let's telnet over to R1. So, I'm connected to R1 right
now from DSW1 via telnet. Notice how those debugs are not showing up. They're still here
on the console of R1, but they're not showing up in my terminal telnet session, or they would not
be showing up in my SSH session. Why is that? Why is that? It's because of this right here.
You need to commit a terminal monitor to view any syslog messages if you've telneted or SSHed
into a device. Very, very important. So, over on R1, if I type in terminal now
monitor, you're going to see the syslog messages show up.
So, that's a command that you're going to need to remember. If you want to see syslog messages
or tel – when you are telneted or SSHed into a device, you are going to have to type in terminal
monitor. And how do you shut it off? The command is terminal new monitor. Terminal new monitor,
not new terminal monitor. Terminal new monitor. There we go. And now you're going to see they're
no longer appearing here. But look, they're still appearing on R1 because it's a console port.
So, there's a difference there. All right. Let's take a peek at where we can see what's
happening in RAM. I'm going to type in you all or do you all to shut off the debugs here.
All right. So, now what I want to do is I want to type in show logging. And if we scroll down,
you're going to see console logging. That means the console port. So, debugging through emergencies.
That's what that means. Debugging all the way down to emergencies, every single one.
Monitor, that's the VTY line. So, telnet and SSH connections, all of them. Buffer logging,
that means to RAM, all of them. And so, where is RAM? If I just keep hitting enter, it's all here.
It's all here. Right. The thing is, is that I ran out of space. So, I keep overwriting,
overwriting, overwriting, overwriting. So, you'll see that most of these messages are just from
our example we were just doing. And that's it. So, we scroll back up. These are all the debugs
that we just produced in our moments ago. And there's the ones without the timestamps.
And here's some additional information that was collected earlier on October 19th. So,
that's still today. And October 18th, that's yesterday. So, with that information there,
you can see it's not very big. We're just going to keep overwriting, overwriting.
So, if I go ahead and keep running my debug, then all of this would be gone within moments,
because we pretty much maxed it out already. There's 8,192 bytes. It's not big.
So, for long-term storage, this is not a great option. So, that's why a syslog server is so
important. So, if you ever want to shut off logging to the console, you just type in no
logging console, and it would shut it off. So, now if we type in do show logging, you'll see that
it's disabled. You want to turn it back on, you type in logging console. So, the same thing is
true for the VTY lines. You don't want to log it all to the VTY lines, type in no logging monitor.
You don't want to log it all to the buffer, no logging buffer.
So, now that we've turned it back on for console, you'll see it defaults to using debugging. So,
if you ever wanted to change the level, then you would type in logging console,
and then you specify your severity level. So, what is the severity level here that we want
to specify? Well, whichever one we want, let's say four, just for fun. So, if I type, oops,
logging console four, and now if we take a look at do show logging, we're going to see in our
output that we're level warnings. That means warnings, errors, critical alerts, and emergencies.
That's what that means. So, it's not just warnings, it's that and everything lower.
And so, the same thing would be true with our VTY lines. You can modify that one as well.
And your buffer. So, just by typing in logging monitor, and then the severity level,
or logging buffer, and the severity level. In addition for the buffer, you can type in logging
buffered. And then you could change even your buffer size if you want to. Again, you change
the buffer size, you take away RAM that could be used for other things. So, be mindful of that.
So, how do we go ahead and set up our
connection to a syslog server? So, I don't have a syslog server in my possession.
That's okay, but we'll fake it. So, these are the commands we would need to have. So, first of all,
the command logging host. So, if I type in logging host, that's going to allow me to specify the IP
address of my syslog service. So, it could be an IPv4 address or an IPv6 address. So, let's just
go ahead and fake it today. We're going to say 10.0.3.8 for fun. And then, if you want to set
the severity level, you can set it with the logging trap command. But what is the default
severity level? Let's check it out. We'll type in do show logging. So, the default severity level
is going to be informational. So, that's everything but debugging. So, you're not
going to send the debugs to the syslog server by default, but you'll send everything else
to the syslog server. So, you can change that if you want to. So, logging trap. So, logging.
And you can change the severity level. So, if you want debugs, then put in seven.
And there'll be seven and everything lower. If you want warnings and lower, then four,
as an example. So, whatever you want to set up is up to you in your environment or a scenario
on a certification exam. So, trap logging level warnings. You'll see the IP addresses listed there
and then the UDP port number. So, by default, it's UDP port 514. But what I want to point out to you
is that you have the ability to use something like TCP instead if you want to. That's right.
You don't have to use UDP. So, if we wanted to use TCP instead, logging host
10.0.3.8, we can change that to by typing in transport and then you can specify, for example,
TCP. And then we can hit enter. And now, if we go back and take a look at show logging,
we'll see here that we're using TCP port 601 for our logging to that particular server.
So, I've set it up twice. I'd have to delete the other config, the other one. So, every time you
type in logging whatever and you add, it's a different command, different command, different
command. So, I'd have to go and delete the other one. In addition, you can set up the source
interface you want the log messages sent from the syslog server. So, this is important. It's the
same thing with NTP. It's the same thing with NetFlow. It'd be the same thing even with SNMP.
What is the source IP address we want to use to talk to that particular device?
So, that way there, we can set up a filter, for example, on our syslog server that says
only accept syslog messages from these IP addresses. So, in this case, for example, logging.
Logging. Oh, my gosh. What is the command?
Logging. In this case, it's just source interface. All right. Source interface.
And then, let's say loopback
192 as an example. So, now if I type in do show logging, you're going to see that the
source interface is listed there. All right. Now, in addition, what I want you to realize
is that we can also do VRS as well. What do we mean by VRS? Well, virtual routing and forwarding.
So, if, for example, we had a management VRF and we wanted to ensure that the syslog messages were
being sent from that source interface in that VRF as an example, well, then our command instead would
be logging host and then put in the IP address, for example, 10.0.3.8. And then the VRF is next.
And then the VRF name. So, whatever the VRF name is, let's just call it Encore VRF. And then,
again, what is the transport? So, if it's TCP you're using, then you can put transport. You
can put TCP. You can put UDP and so on and so forth. So, whatever other options you want to add.
In this case, I don't have VRF Encore specified. So, let's just create a VRF ENC Core.
I'll just use the IP VRF in this case. Right now, we're going to go ahead and retype in that command.
All right. Do show logging. All right. It's getting messy here because I just keep adding
command after command after command, folks, right? I didn't take my command. It's not happy
with the command, is it? Nope. There it is.
All right. So, that one's been added to Encore VRF, but the source interface is not part of
that VRF. So, it's becoming a mess here because we got to add that interface to the VRF and so
on and so forth. So, we'd have to take, for example, interface loopback 192,
IP VRF forwarding, Encore VRF, and then I got to put IP address. It's going to mess
everything up now. .255.1, 255, 255, 255, 255. All right. So, let's see if that worked for us.
I got way too many commands now.
So, let's take out
.255.1. Okay. So, it destroyed it all. Let's paste that one back in.
Okay. So, logging, use its source interface, loopback, 192, VRF,
Encore VRF. There we go. Beautiful now. There we go. That's what we wanted.
So, you can see we're logging to 10.0.3.8 in the Encore VRF using TCP port 601 in this case,
and you can change the TCP port number when you're setting up that command.
Then there's our loopback 192 that's part of Encore VRF. So, just some examples of configurations,
folks, that you might need to remember or recall in your future if they ever come up.
All right. Now, one final thing I want to take a peek at, and that is
discrimination. Don't take that the wrong way. All right. So, with logging, we can discriminate,
and what does that mean? It means that we have the opportunity to control what is actually shown
to us. So, by default, if we did this, we typed in show or debug. I want to type in debug IP OSPF
hello. All right. So, debug IP OSPF hello. This is going to show me everything in regards to
debugging. So, for IP OSPF on this device for hellos. So, notice that we've got gig 00, gig 01.
We've got send hello messages, receive hello messages. We've got NV0 messages, right? So,
there's all these different options. What if I wanted to set up a filter, a discriminator,
it's called? So, that way there, it only shows me specific output. So, this is a great feature
for controlling which syslog messages are returned to you. So, instead of getting all of this,
I just want certain things with certain buzzwords, certain keywords as an example.
So, let's shut this off. And what I'm going to type now is in global configuration mode,
we're going to type in logging discriminator. And then it says, what do you want us to
match? Oh, no, the name. Sorry. This is the name of the discriminator first. Let's just call this
one send hello. Because that's what we're going to match. I only want these ones. That's what I
want. Send hello. So, logging discriminator, I'm going to call it send hello. And then these
are the options I have. I could discriminate based on a facility. I could discriminate
based on mnemonic. So, for example, there's the facility. There's the mnemonic that we have.
Right? We could do the message body. We could do the severity level.
So, I'm going to go with the message body today. So, message body. So, in my message body now,
I only want the ones that are send hellos. Send hellos. So, I also need the word here includes.
So, includes send hello. All right. Now, what we do is we type in logging
console discriminator. Yes. Discriminator. Discriminate. What am I missing here?
Am I spelling discriminator wrong? I think I was. Yes. I put D-E-S. Oh, my gosh. Silly me. D-I-S,
discriminator. And then what was the name of that discriminator we created? We created the
send hello discriminator. That's what we did. All right. So, now that I've done that,
let's go ahead and create a new one. So, I'm going to go ahead and create a new one.
So, now that I've done that, let's go ahead and type in debug IP OSPF hellos. And let's see if
they show me all those hellos or just the ones that have send hello in them. There's an example
of setting up a discriminator. So, like we said, we could discriminate based on the message body,
the facility, the mnemonic, the severity level. And this was an example of using what? Using
the message body information. So, the command was logging discriminator to create the
discriminator. And then we attached the discriminator to the logging console command.
So, you can also do this with a buffer, with the VTY lines, even to your what? Your syslog server.
So, if you need to discriminate and only send certain messages to the syslog server,
then you can do that as well. All right. So, that, folks, is our coverage of syslog to get
you ready for the – oh, no. One final thing. One final thing. Oh, my goodness.
So, I've shown you how you can use TCP for syslog, but you can also use certificates
with syslog to secure your communication. You can. So, in that case, you'd be using TLS.
So, we use TLS to secure communication between our client and our service, so our Cisco device
and our syslog server. So, the syslog server would have to support this as well. All right.
So, we're going to use SSL TLS certificates to accomplish this, number one. And the default
port is TCP port 6514. So, here's an example of setting up your device. Logging host 10.0.3.8.
Your VRF, if you've got your VRF. So, whatever. Let's say we're using a management VRF.
And then transport TCP port 6514. Now, you would have to have the certificates installed on the
device as well, but this is what you would use for the actual syslog command in order to support
using TCP port 6514 for secure syslog communication. All right. And now, that is
our coverage, the end of our coverage for syslog, folks. So, go back and review that. Make sure you
know your severity levels for the exam, as we talked about. Make sure you can read that output
of show logging and just understand what's going on. Because if you've got a simple question like,
what is the severity levels that are supported right now on the VTY lines? So, in the output of
show logging, you look at the monitor, and if it said warnings, well, it's not just warnings.
Remember, it's warnings and everything lower. So, it could be as simple as that. Or what port
number is currently being used to communicate with the syslog server or the IP address of the
syslog server? So, being able to just find that information, there might be something you have to
do. Or the question could be as simple as, what is the severity level, the number associated with
emergency or alert? So, just by memorizing that chart, you'd have the answer to those.
All right. So, syslog.
Seems like not something you'd have to review for the exam, but I encourage you to do it.