When major events take place, these Cisco devices attempt to notify administrators with detailed system messages. These messages vary from the very mundane to those that are incredibly important. Thankfully, administrators have a large variety of options for storing these messages and being alerted to those that could have the largest impact on the network infrastructure. When an event happens that the device’s OS thinks is interesting, how does the OS notify us humans? Cisco IOS can send the messages to anyone currently logged in to the device. It can also store the message so that a user can later look at the messages.
Syslog is a way for network devices to send event messages to a logging server – usually known as a Syslog server. Most network equipment, like routers and switches, can send Syslog messages. Windows-based servers don’t support Syslog natively, but a large number of third-party tools make it easy to collect Windows Event Log or IIS data and forward it to a Syslog server. Unlike SNMP, Syslog can’t be used to “poll” devices to gather information.
Syslog Servers
Syslog is a great way to consolidate logs from multiple sources into a single location. Typically, most Syslog servers have a couple of components that make this possible.
A Syslog Listener:
A Syslog server needs to receive messages sent over the network. A listener process gathers syslog data sent over UDP port 514. UDP messages aren’t acknowledged or guaranteed to arrive, so be aware that some network devices will send Syslog data via TCP 1468 to ensure message delivery.
A Database:
Large networks can generate a huge amount of Syslog data. Good Syslog servers will use a database to store syslog data for quick retrieval.
Management and Filtering Software:
Because of the potential for large amounts of data, it can be cumbersome to find specific log entries when needed. The solution is to use a syslog server that both automates part of the work, and makes it easy to filter and view important log messages. Syslog servers should be able to generate alerts, notifications, and alarms in response to select messages – so that administrators know as soon as a problem occurs and can take swift action! Sending Messages in Real Time to Current Users
Cisco IOS running on a device at least tries to allow current users to see log messages when they happen. Not every router or switch may have users connected, but if some user is logged in, the router or switch benefits by making the network engineer aware of any issues. By default, IOS shows log messages to console users for all severity levels of messages. That default happens because of the default logging console global configuration command. n fact, if you have been using a console port throughout, you likely have already noticed many syslog messages, like messages about interfaces coming up or going down.
For other users (that is, Telnet and SSH users), the device requires a two-step process before the user sees the messages. First, IOS has another global configuration setting— logging monitor —that tells IOS to enable the sending of log messages to all logged users. However, that default configuration is not enough to allow the user to see the log messages. The user must also issue the terminal monitor EXEC command during the login session, which tells IOS that this terminal session would like to receive log messages.
Figure summarizes these key points about how IOS on a Cisco router or switch processes log messages for currently connected users. In the figure, user A sits at the console and always receives log messages. On the right, the fact that user B sees messages (because user B issued the terminal monitor command after login), and user C does not, shows that each user can control whether or not she receives log messages.
Storing Log Messages for Later Review
With logging to the console and to terminals, an event happens, IOS sends the messages to the console and terminal sessions, and then IOS can discard the message. However, clearly, it would be useful to keep a copy of the log messages for later review, so IOS provides two primary means to keep a copy. IOS can store copies of the log messages in RAM by virtue of the logging buffered global configuration command. Then any user can come back later and see the old log messages by using the show logging EXEC command.
As a second option— an option used frequently in production networks— all devices store their log messages centrally to a syslog server. r. RFC 5424 defines the syslog protocol, which provides the means by which a device like a switch or router can use a UDP protocol to send messages to a syslog server for storage. All devices can send their log messages to the server. Later, a user can connect to the server (typically with a graphical user interface) and browse the log messages from various devices. To configure a router or switch to send log messages to a syslog server, add the logging host {address | hostname} global command, referencing the IP address or host name of the syslog server.
Log Message Format
IOS defines the format of log messages. The message begins with some data fields about the message, followed by some text more easily read by humans. For example, take a close look at this sample message:
Notice that by default on this particular device, we see the following:
A timestamp: *Dec 18 17:10:15.079
The facility on the router that generated the message: %LINEPROTO
The severity level: 5
A mnemonic for the message: UPDOWN
The description of the message: Line protocol on Interface FastEthernet0/0, changed state to down
IOS dictates most of the contents of the messages, but you can at least toggle on and off the use of the timestamp (which is included by default) and a log message sequence number (which is not enabled by default).R1(config)# no service timestamps
R1(config)# service sequence-numbers
R1(config)# end
R1#
000011: %SYS-5-CONFIG_I: Configured from console by console
To see the change in format, look at the log message at the end of the command. As usual, when you exit configuration mode, the device issues yet another log message. Comparing this message to the previous example, you can see it now no longer lists the time of day but does list a sequence number.
Log Message Severity Levels
Log messages may just tell you about some mundane event, or they may tell you of some critical event. To help you make sense of the importance of each message, IOS assigns each message a severity level. Table shows the severity levels: the lower the number, the more severe the event that caused the message.
| Keywork | Numerical | Description | Status |
|---|---|---|---|
| Emergency | 0 | Syatem unusanable | Severe |
| Alert | 1 | Immediate action required | Severe |
| Critical | 2 | Critical Event (Highest of 3) | Impactful |
| Error | 3 | Error Event (Middle of 3) | Impactful |
| Warning | 4 | Warning Event (Lowest of 3) | Impactful |
| Notification | 5 | Normal, More Important | Normal |
| Notification | 6 | Normal, Less Important | Normal |
| Debug | 7 | Requested by User Debug | Debug |
Table breaks the eight severity levels into four sections just to make a little more sense of the meaning. The two top levels in the figure are the most severe. Messages from this level mean a serious and immediate issue exists. The next three levels, called Critical, Error, and Warning, also tell about events that impact the device, but they are not as immediate and severe. For instance, one common log message about an interface failing to a physically down state shows as a severity level 3 message. Continuing down the table, IOS uses the next two levels (5 and 6) for messages that are more about notifying the user rather than identifying errors. Finally, the last level in the table is used for messages requested by the debug command.
Below table summarizes the configuration commands used to enable logging and to set the severity level for each type. When the severity level is set, IOS will send messages of that severity level and more severe ones (lower severity numbers) to the service identified in the command. For example, the command logging console 4 causes IOS to send severity level 0–4 messages to the console. Also, note that the command to disable each service is the no version of the command, with no in front of the command ( no logging console, no logging monitor, and so on).
| Service | To Enable logging | To set Message level |
|---|---|---|
| console | logging console | logging console level-name | level-number |
| Monitor | logging monitor | logging monitor level-name | level-number |
| Buffered | logging buffered | logging buffered level-name | level-number |
| Syslog | logging host address/hostname | logging trap level-name | level-number |
Configuring and Verifying System Logging
With the information in, configuring syslog in a Cisco IOS router or switch should be relatively straightforward. Example shows a sample, based. The figure shows a syslog server at IP address 172.16.3.9.
Syslog Configuration on R1logging console 7
R1#logging monitor debug
R1#logging buffered 4
R1#logging host 172.16.3.9
R1#logging trap warning
Note that the example configures the same message level at the console and for terminal monitoring (level 7, or debug), and the same level for both buffered and logging to the syslog server (level 4, or warning). The levels may be set using the numeric severity level or the name.
The show logging command confirms those same configuration settings and also lists the log messages per the logging buffered configuration.
The debug Command and Log Messages
Out of the eight log message severity levels, one level, debug level (7), has a special purpose: for messages generated as a result of a user logged in to the router or switch who issues a debug command.
The debug EXEC command gives the network engineer a way to ask IOS to monitor for certain internal events, with that monitoring process continuing over time, so that IOS can issue log messages when those events occur. The engineer can log in, issue the debug command, and move on to other work. The user can even log out of the device, and the debug remains enabled. IOS continues to monitor the request in that debug command and generate log messages about any related events. The debug remains active until some user issues the no debug command with the same parameters, disabling the debug. The best way to see how the debug command works, and how it uses log messages, is to see an example.
The console user sees the log messages created on behalf of that debug command after the debug command completes. Per the earlier configuration, R1’s logging console 7 command tells us that the console user will receive severity levels 0–7, which includes level 7 debug messages. Note that with the current settings, these debug messages would not be in the local log message buffer (because of the level in the logging buffered warning command), nor would they be sent to the syslog server (because of the level in the logging trap 4 command).
