Cisco CCNA 200-301 – Network Device Management

1. Introduction

In this section, you’ll learn about the management protocols syslog and SNMP. That’s a simple network management protocol. These protocols can be used for logging and monitoring so you can see what’s happening with your Cisco devices.

2. Syslog

You’ll learn about syslog on cisco devices? Syslog is a standard format for logging messages, and Cisco iOS complies with that standard. A Syslog message is generated when something happens on the device, like if an interface comes up or goes down, or if an OSPA if neighbor adjacency comes up or goes down. There’s a set format for the Syslog messages. And this is an industry standard. All vendors comply with this standard. You see there’s quite a few parameters here, so let’s go through it one by one.

So the first thing in the Syslog message is an optional sequence number. For our example, we don’t have one set, so it’s just a star there. The next thing in the message is a timestamp. You can see from our example that this event happened on October the third at about quarter to 01:00 A. m. . The next thing that is listed is the facility. This is the thing that generated the event in our example. It’s going to be a change of state on a link. So the facility here is the link.

If it had been an OSPF adjacency coming up or going down when the facility would have been OSPF. The next thing is the severity a level. We’re going to cover this in more detail in a few slides. There’s eight different severity levels going from zero through to eight, with zero being the most severe. In our example, the severity level of this event is severity a five. Next thing is a mnemonic, which is a short description of what happened.

So here we can see that a link has changed. And then the last thing in Mrs. Log message is a more detailed description. You can see the description in our example is the interface faster changed its state to administratively down. So somebody typed shut down on that interface. Okay, so it’s a standard format. Next thing is the severity levels. So like I just said, there’s eight different levels from zero to seven, with zero being the most serious. And these are again, standard levels that are used the same by all vendors.

It’s covered in the documentation for Syslog. So the most serious event you can have would be an emergency, which is value zero. So the values go from zero to seven. And each of those values has got a standard name as well, the name for sovereignty. Level zero is emergency. And that means that the system is unusable a panic condition. It’s really bad. The next severity level is an alert, which is level one, a condition that should be corrected immediately, such as a corrupted system database. It’s still really bad. Critical is level two, such as hard device errors, and level three is an error.

So really three and above up to zero are bad things, bad errors happening on your device. Level four is a warning, so that might be serious. It’s definitely something that you want to check out. Level five is a notice which is a normal but significant condition that you should also check, for example, an interface being shut down by an administrator.

That’s not a warning or an error because somebody has to have deliberately done that. But obviously that can be impactful on the device, so that’s why it gets at a notice level. The next one, level six, is informational, which is just an informational message, nothing’s wrong, it’s a normal thing happening, but it’s telling you about it. And level seven is debug messages that contain information normally of use only when debugging a program.

So this would be quite low level verbose, like a lot of detail about something happening. Syslog messages can be logged to various locations from your router or switch. First place that we can log to is the console line. So if you are connected to the device over a console cable, you’re logged in and you’re working at the command line, then you’ll see that as you’re working in the command line, you’ll see syslog messages pop up in the command line interface as you’re working in there. The logging to the console is turned on by default and the default severity level is debugging. So everything gets logged to the console by default.

Next place that we can log to is the virtual terminal lines. So if you’re at the command line again, but this time it’s over a telnet or an SSH session, this is for logging there. This is not enabled by default, so you’ll notice if you’re working on a router or switch by default. If you’re going over a console connection, you’re going to see messages popping up as you’re working there.

But if you’re over telling it or SSH, you won’t. That’s because syslog logging is enabled by default at the console, but not in your terminal ends. The next place that we can log to is the logging buffer. This is where events are saved in Ram memory on the device. And to view the buffer, you do that with the shield logging command and you’ll see all the events that are in the buffer. Just like the console line, logging to the buffer is enabled by default as well.

And the last place that we can log to is an external syslog server, which I’ll talk about in a bit more detail later on in this lecture. So those logging locations, you can log to one of them or two of them, or all of them, you can log to as many of them as you want. It’s the same messages that will be getting logged to each of the different locations, but you can log either the same or different severity levels to each of those different locations.

When you do that, all messages of that severity level that you set for that location and higher will be logged there. For example, if you set a logging level of three for the console, then events with severity levels zero, one, two and three will be logged there. So it’s everything at that level and everything more serious as well. Remember, the lower the number, the more serious is if you set a logging level of seven to an external syslog server, events from all sovereignty levels zero to seven would be logged there.

So let’s have a look at how you would configure this. Remember logging the console is turned on by default. If you wanted to disable that, then a global config, you could use the command no logging console. Next example is for logging to the VTi lines for telnet and SSH connections. It’s logging monitor there and then we set the level. So here we’ve said logging monitor six. Six is known by the name of informational. So everything informational and higher would show up in your command line when you’re logged in using a telnet or SSH session. And the last example here is logging buffered. Debugging logging buffered is going to the Ram buffer and here it is at the debugging level. So that would be everything seven and higher. You can also log to an external syslog server. The benefit you get from this is that it centralizes event reporting. Maybe you’ve got 30 routers and switches in your campus. You could configure them all to log to the same syslog server and then you’ve got one single location that you can use for monitoring all of the logs.

If you are using an external syslog server, you’ll typically set verbose logging there because you want to have a lot of information on that system. The whole point of the system is for logging. So you’re not going to have minimal information getting logged there. You’re going to log everything. So that way when you are troubleshooting later you’re going to have all the details that you need. You don’t have to do that, but it’s what people would normally do.

The configuration to log to an external syslog server, a global config logging and then the IP address of that external server and then logging trap and the severity level that you want to log there. So here we’re using debugging, which is what would normally be done. And this is an example of what you would see on that external syslog server. The example here is the Kiwi syslog server was a free version that you can get from this and you see the information that’s listed there. We’ve got the date of the event, the time the event happened, the priority which is the severity level, the host name. So you can see the actual device that logged this event and then a message what actually happened.

Okay, so that was really a basic log server we had a look at there. And that gives you again that benefit of centralizing all of your logs. Another thing you can use is a Seam system. Seam stands for security information and event management. That also provides a centralized location for all your logging messages. But this is normally a bit more of an expensive option than a basic Syslog server.

And it will typically provide advanced analysis, advanced reporting, nice graphs, and it can correlate events as well. Meaning for example, if somebody was launching an attack against you, you would have multiple devices logging events about it properly. And the Seam system can look at the information from those multiple devices and see that they’re related to each other and it can report on that for you. So using a SIM system gives you more advanced reporting tools and more advanced troubleshooting tools as well. Okay, so once we’ve got our logging set up to view how you have configured it, the Show Logging command will do that.

So you can see here we are logging errors of any level events to the console warning to our VTY lines, and debugging to the buffer. Also from that same command she’ll logging underneath your configuration under there, you’ll see all of the events that are in the buffer. So if you look at the example here, you can see down at the bottom there, we can see a couple of interfaces coming up. So that’s how you see your configuration and also how you see the events that are in the buffer. Okay, a couple of things I want to tell you about at the end of the lecture here. First one is logging Synchronous. So when you’re working in a command line session, by default, any Syslog messages that are getting logged there are going to be printed into the middle of any commands that you’re currently typing. So you can see an example here. I was entering the command Do Show IP Interface Brief, and in the middle of it an event was logged. And what happens is it makes it hard to see where you’re at in your command. It’s actually quite easy in the example because I’ve highlighted it in blue text.

But when you’re working at video command line, it’s not going to be highlighted in blue and it’s going to make it hard to see where you were in your command. And what you usually end up doing is just hitting back space to delete everything and then start the command again. And it’s a little bit annoying. So you can stop that from happening. And the way you do that is by using the Logging Synchronous command. This is done at the line level, so you can configure it under a console line and your VTY lines as well, and you just enter the command Logging Synchronous like you can see here. Once you do that, it’s exactly the same thing again. So I’m in the middle of a command, I’m doing a Douche IP Interface Brief, but I haven’t finished typing it yet. And while I’m in the middle of typing that command, a logging event comes up. But because I’ve enabled Logging Synchronous, it reprints the command that I was typing in exactly where I was on a new line and then I can see exactly where I am in that command and I don’t get confused.

So it’s best practice to configure logging synchronous on your lines. It just makes things more convenient. Last thing to tell you about, which is another thing that you’re going to want to know about because it’s important, it’s useful for real world is about debug and the Terminal monitor command. So short and debug commands can be used to view specific information over and above the standard syslog messages. You’ve already seen loads of show commands as we’ve been going through the course. Show output shows a static point in time state. So you enter the command and it gives you the output of the state when you hit the enter key. Debug output dynamically updates in real time. So you could, for example, debug OSPF messages and as new Ospaf events happen, they will be reported in real time in the command line. So it keeps updating, it keeps giving you new information.

Debug is very useful if you’re doing some troubleshooting, be careful with debug commands in production environments, a large amount of output can overwhelm the device. There are some debugs that will generate loads of information and it’s all getting written to the command line and it kind of locks you out of the device. So be careful, don’t run any of those commands on a production system. Debug output is logged to the console line and the buffer by default. So if you do a debug and you’re connected over a console line, you will see your output and also you can do a show logging to see the output as well.

But if you’re logged in over a telnet or SSH session, which you usually will be, and you enter a debug command, even though events are being generated, you’re not going to see them in the command line. And this is something that trips administrators that are new to Cisco devices all the time. So to actually see the debug output being reported, you have to put in the terminal monitor command and that is done at the enable prompt. Maybe isn’t making too much sense now, so I’ll show you what I mean right in the next lecture when we do a lab demo.

• Category: Uncategorized