This chapter presents an overview of the syslog protocol and shows you how to deploy an end-to-end syslog system. The chapter includes a discussion about the syslog architecture and discusses deploying syslog servers in Linux and Windows OSs with a focus on their relevance in a Cisco environment. Also included are the steps involved in configuring Cisco devices for syslog.
Overview of Syslog
The syslog protocol, defined in RFC 3164, was originally written by Eric Allman. This protocol provides a transport to allow a device to send event notification messages across IP networks to event message collectors, also known as syslog servers. The protocol is simply designed to transport these event messages from the generating device to the collector. The collector doesn't send back an acknowledgment of the receipt of the messages.
In a UNIX operating system, the kernel and other internal components generate messages and alerts. These messages are typically stored in a file system or relayed to another device in the form of syslog messages. The internal daemon, called Syslogd, handles the syslog process. This daemon is an integral part of most UNIX/Linux distributions and does not need to be downloaded or installed. Syslog provides a central point for collecting and processing system logs. These system logs are useful later for troubleshooting and auditing. For example, when a hacker breaks into a system, the trail left behind by the hacker's activity is logged in the syslog messages. These messages can then be used to understand the attack, assess the damage, and patch the system.
Various Cisco devices, including routers, switches, PIX Firewalls, VPN concentrators, and so on, generate syslog messages for system information and alerts. For example, a Cisco router can generate a syslog message when an interface goes down or the configuration is changed. Similarly, a Cisco PIX Firewall can generate a syslog message when it blocks a TCP connection. Cisco devices can be configured to send the syslog messages to an external machine that acts as a central syslog server. However, if the connectivity between the Cisco device and the syslog server is down, no syslog messages would be captured by the server. In such cases, the syslog messages stored locally by the Cisco devices are the only source of information to determine the root cause of the issue.
Syslog uses the User Datagram Protocol (UDP), port 514, for communication. Being a connectionless protocol, UDP does not provide acknowledgments. Additionally, at the application layer, syslog servers do not send acknowledgments back to the sender for receipt of syslog messages. Consequently, the sending device generates syslog messages without knowing whether the syslog server has received the messages. In fact, the sending devices send messages even if the syslog server does not exist.
The syslog packet size is limited to 1024 bytes and carries the following information:
- Facility
- Severity
- Hostname
- Timestamp
- Message
A clear understanding of each of the syslog packet parameters can help you easily deploy syslog systems across your network. Note that the first two parameters, facility and severity, are often misunderstood.
Facility
Syslog messages are broadly categorized on the basis of the sources that generate them. These sources can be the operating system, the process, or an application. These categories, called facility, are represented by integers, as shown in Table 4-1. The local use facilities are not reserved and are available for general use. Hence, the processes and applications that do not have pre-assigned facility values can choose any of the eight local use facilities. As such, Cisco devices use one of the local use facilities for sending syslog messages.
Table 4-1. Facility Values
|
Integer |
Facility |
|
0 |
Kernel messages |
|
1 |
User-level messages |
|
2 |
Mail system |
|
3 |
System daemons |
|
4 |
Security/authorization messages |
|
5 |
Messages generated internally by Syslogd |
|
6 |
Line printer subsystem |
|
7 |
Network news subsystem |
|
8 |
UUCP subsystem |
|
9 |
Clock daemon |
|
10 |
Security/authorization messages |
|
11 |
FTP daemon |
|
12 |
NTP subsystem |
|
13 |
Log audit |
|
14 |
Log alert |
|
15 |
Clock daemon |
|
16 |
Local use 0 (local0) |
|
17 |
Local use 1 (local1) |
|
18 |
Local use 2 (local2) |
|
19 |
Local use 3 (local3) |
|
20 |
Local use 4 (local4) |
|
21 |
Local use 5 (local5) |
|
22 |
Local use 6 (local6) |
|
23 |
Local use 7 (local7) |
By default, Cisco IOS devices, CatOS switches, and VPN 3000 Concentrators use facility local7 while Cisco PIX Firewalls use local4 to send syslog messages. Moreover, most Cisco devices provide options to change the facility level from their default value.
Severity
The source or facility that generates the syslog message also specifies the severity of the message using a single-digit integer, as shown in Table 4-2.
Table 4-2. Severity Values
|
Integer |
Severity |
|
0 |
Emergency: System is unusable. |
|
1 |
Alert: Action must be taken immediately. |
|
2 |
Critical: Critical conditions. |
|
3 |
Error: Error conditions. |
|
4 |
Warning: Warning conditions. |
|
5 |
Notice: Normal but significant condition. |
|
6 |
Informational: Informational messages. |
|
7 |
Debug: Debug-level messages. |
Cisco devices use severity levels of Emergency to Warning to report software or hardware issues. A system restart or interface up/down messages are sent through the Notice level. A system reload is reported through the Informational level. The output of debug commands is expressed through the Debug level.
Hostname
The hostname field consists of the host name (as configured on the host itself) or the IP address. In devices such as routers or firewalls, which use multiple interfaces, syslog uses the IP address of the interface from which the message is transmitted.
Timestamp
The timestamp is the local time, in MMM DD HH:MM:SS format, of the device when the message was generated. Although RFC 3164 does not specify the use of a time zone, Cisco IOS allows configuring the devices to send the time-zone information in the message part of the syslog packet. Such timestamps are generally prefixed with a special character, such as an asterisk (*) or colon (:), to prevent the syslog server from misinterpreting the message. The timestamp format, including the time-zone information, is MMM DD HH:MM:SS Timezone *.
Message
This is the text of the syslog message, along with some additional information about the process that generated the message. The syslog messages generated by Cisco IOS devices begin with a percent sign (%) and use the following format:
%FACILITY-SEVERITY-MNEMONIC: Message-text
Following is a description of each field:
- FACILITY— Refers to the source of the message, such as a hardware device, a protocol, or a module of the system software. Note that this FACILITY is Cisco specific and is only relevant within the message string. It is different from the facility defined in RFC 3164 for the syslog protocol.
- SEVERITY— This is similar to the severity defined in Table 4-2.
- MNEMONIC— This is a device-specific code that uniquely identifies the message.
- Message-text— This is a text string that describes the message and can contain details such as port numbers and network addresses.
Following is a sample syslog message generated by a Cisco IOS device:
*Mar 6 22:48:34.452 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0,
changed state to up
Note that the message begins with a special character (*) and that the timestamp includes the time-zone information. The message was generated by the LINEPROTO facility at severity 5 (Notice). The MNEMONIC UPDOWN along with the message-text describe the event.
The format of the syslog message generated by CatOS is slightly different from that generated by the IOS devices. Following is the format of the message generated by CatOS switches:
mm/dd/yyy:hh/mm/ss:facility-severity-MNEMONIC:Message-text
The syslog messages generated by a Cisco PIX Firewall begin with a percent sign (%) and are slightly different than the IOS syslog messages. Following is the format of syslog messages generated by a Cisco PIX Firewall:
%PIX-Level-Message_number: Message_text
For a complete list of the Message_number and Message_text and associated details, refer to the Cisco PIX Firewall System Log Messages section on the Cisco product documentation website (http://www.cisco.com/univercd/home/home.htm).
The syslog messages generated by Cisco VPN 3000 Concentrators follow the format of the IOS syslog messages, as discussed earlier in this section.