The thing with logging is that the defaults are so good that you rarely adjust them!
There are three main methods of accessing log messages, and it won’t surprise you to find out the commands for each are just a bit different:
- A direct connection via the console port.
- A remote connection through Telnet (or SSH)
- Connecting to a syslog server, a separate device used to store the log messages.
Again the defaults are so good but you might have times when you want:
- A little less information the defaults give you
- A little more information
- Less information on the screen, but more sent to a syslog server for later viewing
- A very specific level of information to the syslog server, more general info on the screen
Note: If you set up a syslog server and you were looking at messages on the screen the levels of logging do not have to be the same.
Here’s just an example of some of the log messages that we’ve seen in these console messages:
%SYS-5-CONFIG_I: Configured from console by console
%LINK-3-UPDOWN: Interface Serial0/1/0, changed state to up.
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0//1/0, changed state to up
Again we’re talking about console logging where I am connected directly to the device via the console port. These console messages were displayed on the console by default.
Let me run ‘show logging’ here:
show loggings command is not only the main logging show command, it’s almost the only show logging command, and tells you everything you need to know.
we’re really concerned with the information right in red circle. These are the three logging methods we’re really concerned with right now:
Console logging is what we’re looking at right now, which is on by default.
Monitor logging is on as well known (We haven’t logged any messages that way).
Buffer logging: we can log information to a buffer on the local device which is disabled and that’s actually a default.
If I do a ‘shut’ and a ‘no shut’ :
Let’s look at these messages in just a little bit more detail.
LINK refers to the source of the message, or the facility that created the message.
3 refers to the severity level, with 0 being the most urgent and 6 being the least vital of the non-user-created messages. Debugging messages, created due to user input, carry a severity level of 7.
UPDOWN gives you a very brief summary of the event “interface Serial 0/1/0…” gives you a description of the event.
You need to be familiar with the severity numbers. (memorize these for the exam)
One of those real world situations we talked about with people who can’t see their console messages: The command to enable our logging at this point (our console logging) is ‘logging console’.
Our options here are those severity levels.
Notice here that they give you the level and the severity number. Let’s say that I was going to put in ‘alerts’… I could put either the word “alert” or the number “1” (that’s where it is).
So what exactly am I doing there?
What I’m doing there is filtering the level of messages I’ll see at the console.
Let’s say that someone is just fooling around and put ‘no logging console’!
Well that actually disables the console messages.
Now someone could come back a week later and do the following :
No console messages !! It means someone has turned off console logging. So we just need to turn it back on again.
Note: Always go to show logging first if you’re not seeing the message you expect to see. Don’t waste time with anything else!
So we’ll turn it on
And now if we do ‘Show logging’, we’ll see this:
Your console logging is back on.
Buffer and Syslog Logging
Using A Syslog Server And Buffer Logging
We have two different ways to save messages for later analyzation here. One of them is syslog server (will talk about it soon) and buffer logging
It’s a lot easier to read syslog messages when they’re saved to a syslog server. To make that happen, use logging host to define the location of the syslog server. Adjust the level of messages to be sent to the server with logging trap (There is no requirement that the console logging level and the server logging level have to be the same.)
buffer logging is disabled by default (you see it in the picture above)
where’s the syslog information? that’s going to be at the very bottom and occasionally with this command you’re going to have to hit the “enter key” or the “spacebar” to get that last bit of info.
We see information here for trap logging (we’re trapping it to the syslog server )
The thing is it’s really not enabled because we haven’t told this router where this syslog device even is.
So we will take a look at that in just a moment but first let’s go ahead and get buffer logging up and running and I’ll show you how to access that info because first off it’s disabled.
We need to enable it and the proper command is ‘logging buffer’
The vast majority of these options look a little familiar(the exam is not as nice as ios help to show you the list of severity numbers), but we also have something a little bit different here, and that’s the “logging buffer size” (the second line) and really you don’t want to set it to the maximum because of course whatever buffer space you assign here you’re taking buffer space away from other things, so you don’t want to make the log as large as possible.
We want to be selective (especially in real world networking) about what we’re logging and what we’re not, and how large we make buffers.
So let’s go ahead and just accept the default…
… and see what those defaults are… (with ‘show logging’)
You can see here in the center that buffer longing is now enabled and we already logged the message (not concerned about XML filtering right now) and there is the size of your buffer next to “exception logging” (4096 bytes)
Again you can change the logging buffer size with the “logging buffer size” command.
At the bottom:
… now that I have information that I didn’t have 30 seconds ago! and that is the log buffer (it’s under trap logging) and again the screen is nice enough to tell us the size of the log buffer right now… and there is the latest message that we got and it wrote that to the buffer (If you just have a few commands you think you need to log and you want to read them back to back, this is a great way to go. Nothing wrong with that at all again.
(Just be careful about making the log as large as you possibly can).
Now when it comes to the syslog server, that’s where we’re sending the information to another device we can access that later. But what we have to do here on the router, is set a couple of commands and actually there are a couple involved here.
Let’s go ahead and do logging.
The first option we need here is “host” and maybe “trap”
So if you go with logging host here you’re going to be able to put either version 4 or version 6 address here… if we go with v6:
But if we wanted to go with a classic version 4, you could just put 172.12.123.2 . Don’t worry about the options. we’ll go ahead and just set that
and then we’re on show logging
Look at the white part, (and you also see that down here in the buffer) so our buffer is starting to add up as well. Also notice now that there was trap logging level informational. That’s a little bit different as a default. We see console and monitor and buffer logging all have debugging as their default. But here with trap logging, the informational level is the default level… so if you want to change that, you can sue ‘logging trap’ and then you’re going to have your severity levels (we set that three)
Now if we do ‘show logging’, at the end od it you’ll see this:
We changed the levels successfully to errors (here it’s going to give you the word and not the number).
You can also see here where fine tuning with a numeric level can come in handy because your logged buffer is going to fill up pretty fast if you’re logging everything at levels five and six (specially five) and if you’re doing a lot of config, you’re going to fill it up with configure from console by console. That’s going to get a little hard to read after a while.
Where Are My Log Messages
Definitely a real world scenario for you (important for exam) here. It is going to start with a nice simple Telnet connection.
So let’s go ahead and make this telnet connection happen.
I did test it I admit and I’m going to enter the password I configured.
pop quiz: I put in a password (so I obviously did not use the username password database bit). So you know I put log in on the vty lines on R3 and you know I configured a password.
What other command can you tell right now that I put on the vty lines?
Answer: privilege level 15… because I was put immediately into enable mode as soon as I authenticated otherwise I would have been dropped off at user exec and I would have had to put in an enable password if one had been set.
Now let’s say that I shut an interface down here on R3 (fast ethernet 0/0).
I didn’t check to see if it was open or not because I’m not really getting any log messages here. So maybe it was already shut. Well let’s do ‘no shut’ and see if we see anything.
Nothing appeared!! So what’s going on here? First off let’s check out see what the status of the interface is right now:
and it’s up and up. So everything’s fine with the interface.
But why didn’t I get any log messages? Because sure you know I ran ‘show interface’ and I was able to see whether the interface was up or down. But if you’re troubleshooting something the log messages on the screen really come in handy. I mean you can see when line protocols come up, or see when they go down… and I really want my log messages when I’m telnetting into another device. So why aren’t I getting them here?
Well what commands should we run first to even begin to see everything that’s going on with a logging? show logging…
What is going on here? why aren’t I getting my log messages?
Well the good news is the kind of logging that needs to be enabled, is enabled by default for remote connections, and that is monitor logging. This is the one that we’re concerned with right now. Monitor logging is when you’re telnetting in (remotely connecting) and you want to see the log messages. So that looks good. I do want to show you though what it looks like if that is off.
The command is ‘logging monitor’ to turn it on, so just put the “no” in front of it to disable it
and you can see now monitor logging is disabled.
This is the first thing you want to check… and notice that I am on the device I am telnetting to… I’m telnetting from 1 to 3. So monitor logging has to be “on” on R3… so we’ll turn it back on with ‘logging monitor’ and then we’re going to verify with ^z and ‘show logging’
Anyway on “monitor logging line” we can see some messages logged but we don’t seem to be seeing them on our screen. And this is the other command you’ve got to watch out for
quick visual reminder: You do need logging monitor enabled on the router you are telnetting to. So we checked that. We saw it was on. I showed you how to turn it off and turn it back on. We verified that. So everything is fantastic.
Now the other thing you’ve got to have is the terminal monitor command, and you’ve got to have that running during your session.
notice where the carrot (the arrowhead) is. It’s at the beginning of the word “monitor”… so “terminal” would seem to be a legal command and the only option I have here is entry retry interval.
That’s not what we want. It’s not what we need right now.
The reason I bring that up is you have to run terminal monitor at the “Enable prompt”
and now let’s try to go back to the interface and we’ll do a ‘Shut’ here. And let’s see what we get now.
And now we’re getting our log messages. And let’s go ahead and do a quick ‘No shut’ there as well and we’ll just make sure we get our messages opening up
and we do… Everything looks fantastic.
So I’m still telnetted in…
You see now I’m even getting log message saying where is this being configured from… And we’re so used to in this course when you’re connected directly, to see ‘configured from console by console’ but we’re not seeing that here! we’re seeing ‘configured from console by vty0’ and it even shows the source IP address of the telnet connection.
It looks so simple but it can get very frustrating if you forget the terminal monitor command. Because it’s just not going to work and you’re not getting your messages…
So a quick review: When you’re telnetting in, you’ve got to have logging monitor enabled (monitor logging) on the router you are telnetting to. Then you need to use the terminal monitor command during that telnet session, and then you will start seeing your logging messages.
Nothing to it when you know exactly what to do. So that will definitely help you in the real world at least one time in your career guaranteed and hopefully on the exam as well.