Have you ever been rudely interrupted by a router or your switch? Just like that, you’re typing away, you’re minding your own business, and all of a sudden, poof, there is a message, and then another one. You continue typing, another one, what are those? These are known as syslog messages, and they’re messages that our routers and our switches generate to notify us about something that has occurred. And it could be a wide range of things that have occurred from anything related to an emergency to something that’s just a simple notification. Now that syslog message that we see, it’s appearing to us how? Well if we’re consoled in, it’s appearing to us on our console line. If we’ve Telnetted in or SSHed in, then it’s appearing on our terminal lines. But wait a second, I have a question for you. If I Telnet or SSH into a device, will I see syslog messages by default?<\/p>\n
No and that’s pretty confusing and you won’t even see debugs, okay, you won’t even see debug messages. You turn on a debug, you know it should be spitting out some output, no. And it’s because we have to use the terminal monitor<\/strong> command to enable that. And the reason why is, they didn’t want to inundate vty sessions with very chatty debugs and locking, and basically, bump someone off of a usable session because there’s so much information going that way. Basically you can configure the syslog messages to be forwarded to various destinations:<\/p>\n So by default, syslog messages go to the console line, but not to the terminal lines. We can also send those syslog messages to our buffer. What’s the buffer? Memory, folks, memory. But these three options that we see listed first, buffer, console line, terminal line… what’s going to happen if for example, we lose power or we log off of the device and come back? Are those messages still going to be there? No they’re gone, they’re gone for good. So that doesn’t help us out after the fact. If you’ve consoled in, you’ll see it, great, it’s going to help us out at that point, but if it’s being generated when we’re not logged in, we’re not going to see the information we need. So the bottom option \u2013 the syslog server, it’s a really great option. Let’s take those syslog messages and let’s send them to a syslog server. And then once they’re on that syslog server, we can filter them, we can browse through them, we can see if there is anything abnormal.<\/p>\n I’d like you folks thinking, how can I extract some usable information that I can apply to my own environment in this module that we’re in right now? Now Simple Network Management Protocol, or SNMP, is questionable right? You may not have the budget, the software, and the endurance to do an SNMP rollout. But syslog is totally different, it’s so darned easy to configure and so powerful at the same time. And there are free syslog servers that are out there. So in fact, there’s not really a good excuse to not do syslog management and we’re big fans of it in Cisco, we really are. You talk to any person who has done a lot of Cisco stuff in their career, and they’re fans of it.<\/p>\n What is the most efficient logging mechanism in terms of overhead on chassis? I want you to be able to answer this, maybe not for your associate-level majority, but if you’re ever talking about syslog in an exam environment, its that one question that is kind of common place. So what do you folks think? The answer is logging to the buffer, okay. Logging to the buffer is much more efficient than any other modality. Why? Because it’s RAM and RAM is fast. So just one little nugget to take away from this, just in case.<\/p>\n There is something called the facility of syslog messages, and when you hear this word facility, it’s hard to, in fact, know what it means just by an analysis of the word, which is unfortunate. Facility really means the formatting is done for all of that information. Think, we got a lot of information, right. How do I format that? And so, in some cases, you will want to reformat this. And the specific case that I have in mind is CiscoWorks. If we’re interfacing with CiscoWorks, we would want to change the facility for logging messages to local 7.<\/p>\n General format of syslog messages generated by the syslog process on the Cisco IOS software:<\/p>\n seq no:timestamp: %facility-severity-MNEMONIC:description<\/p><\/blockquote>\n Example of syslog message, informing the administrator that FastEthernet 0\/24 interface came up:<\/p>\n *Feb 22 11:29:55:423: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0\/24, changed state to up<\/p><\/blockquote>\n So CiscoWorks is not only a Network Management Software, or NMS, from simple network management’s perspective, but we could also send syslog messages to the CiscoWorks’ box. And that’s, in fact, how a lot of these NMS devices work is, they need information from lots of different sources to get a full picture of what’s going on?<\/p>\n So let’s say I got my facility set up as normal and usually, we don’t touch this if we’re just sending to a syslog message or a syslog server by the way. But if it’s CiscoWorks, we might say local 7 for the facility. But I see a lot of stuff going on here in terms of numbers, like a severity level. What’s the deal with the severity levels of the syslog messages?<\/p>\n These severity levels are going to indicate how important this syslog message is to us at this particular point in time. For example, look at level 6, informational; it’s giving us some information about something that has happened. Our example shows a level 5, level 5 being a notification. Notification about what? Well our interface changed state to up. But I want you to see the pattern here. We go from 0 to 7, 0 being the worst, 7 being debugging. How do we turn on a level 7 syslog message? We have to enable a debug command that’s how they’re going to appear. So by default you can’t see any level 7s.<\/span><\/p>\n But everything else from 0 to 6, that’s fair game right off the bat. It’ll be really great to know if we have an emergency and our router is unstable. But notice how we have a name associated with each of these levels as well. And at first, it’s tough to remember these, it’s tough to remember that 2 is critical, or 4 is warnings. But over time, the more you play around with syslog, the more you look at a table, the more you’ll remember that we have these levels associated with these names and what they mean.<\/p>\n Very few protocols and technologies are so straightforward to configure, and I love straightforward. I mean, I also like complex as you know, but this one is great, okay. So you go into the global configuration mode and by the way, we’re not syslog servers. I would want you to understand that, we are not a syslog server, the router, the switch, no it’s a syslog client! We’re pumping to the server. So, that would mean that, we would have to have an application running on some type of device that can collect these syslog messages. Yeah and there’s some free syslog software that’s out there, there’s also some expensive stuff that does better correlating of the data that is inside of it and reporting. But you would want IP connectivity between the client and the server, and we are the client and we point to the server with the IP address.<\/p>\n R1(config)#logging 10.1.10.100 Now in fact, that is the only command that would be necessary in order to start shooting those syslog messages over to the server. But remember the severity levels? Well, we don’t want to log everything and that’s the general rule of thumb. What was the range? 0 to 7, 7 being debugging, we usually exclude that and often, we exclude level 6 as well. I’m okay with 6 and below, but when you say the logging trap command you’re saying, how bad or how inconsequential will you go? How inconsequential will you go?<\/p>\n\n
Syslog message format<\/h2>\n
\n\n
\n Severity Level<\/th>\n Name<\/th>\n Description<\/th>\n<\/tr>\n \n 0<\/td>\n Emergencies<\/td>\n Router unusable<\/td>\n<\/tr>\n \n 1<\/td>\n Alerts<\/td>\n Immediate action required<\/td>\n<\/tr>\n \n 2<\/td>\n Critical<\/td>\n Condition critical<\/td>\n<\/tr>\n \n 3<\/td>\n Errors<\/td>\n Error condition<\/td>\n<\/tr>\n \n 4<\/td>\n Warnings<\/td>\n Warning condition<\/td>\n<\/tr>\n \n 5<\/td>\n Notifications<\/td>\n Normal but important event<\/td>\n<\/tr>\n \n 6<\/td>\n Informational<\/td>\n Informational messages<\/td>\n<\/tr>\n \n 7<\/td>\n Debugging<\/td>\n Debug message<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Syslog configuration<\/h2>\n
\nR1(config)#logging trap informational<\/p><\/blockquote>\n