Syslog is a protocol that allows a host to send event notification messages across IP networks to event message collectors – also known as Syslog Servers or Syslog Daemons. In other words, a host or a device can be configured in such a way that it generates a Syslog message and forwards it to a specific Syslog Daemon (Server).
A Syslog Daemon or Server is an entity that listens to the Syslog messages that are sent to it. You cannot configure a Syslog Server to ask a specific device to send it Syslog messages. In other words, if a specific device has no ability to generate Syslog messages, then a Syslog Daemon cannot do anything about it. In the real world, corporations typically use Solarwinds (or similar) software for Syslog capturing. Additionally, freeware such as the Kiwi Syslog Daemon is also available for Syslog capturing.
Syslog uses User Datagram Protocol (UDP) as the underlying transport mechanism, so the data packets are unsequenced and unacknowledged. While UDP does not have the overhead included in TCP, this means that on a heavily used network, some packets may be dropped and therefore logging information will be lost. However, the Cisco IOS allows administrators to configure multiple Syslog Servers for redundancy. A Syslog solution is comprised of the following two main elements:
- Syslog Server
- Syslog Client
Syslog messages cannot exceed 1,024 bytes in size; however, there is no minimum length. These messages have a UDP destination port of 514. All Syslog messages contain three distinct parts, a follows:
- Header
- Priority
- Message
The header of a Syslog message contains the time-stamp and the hostname or IP address of the device. The time-stamp is the date and time at which the message was generated. In Cisco IOS software, routers can be configured to use Network Time Protocol (NTP) to sync their internal clocks, or administrators can manually set the clocks on the devices via the clock set privileged EXEC command.
The priority of a Syslog message includes the Facility and Severity of the message. The Facility tells the protocol, module, or process that generated the message. Common examples include OSPF for OSPF messages, SYS for system messages, and LINK for link status messages. The Severity is used to indicate how important the action is. The Facility and Severity can be used to filter events in the Syslog Daemon. Table 8-4 below lists and describes eight different Severity levels that are used in Cisco IOS software Syslog reporting.
Table 8-4: Cisco IOS Software Syslog Severity Levels
|
Level |
Name |
Description |
|---|---|---|
| 0 | Emergencies | This level is used for the most severe error conditions that render the system unusable. |
| 1 | Alerts | This level is used to indicate conditions that need immediate attention from administrators. |
| 2 | Critical | This level is used to indicate critical conditions that are less than Alerts but still require administrator intervention. |
| 3 | Errors | This level is used to indicate errors within the system; however, these errors do not render the system unusable. |
| 4 | Warnings | This level is used to indicate warning conditions about system operations that did not complete successfully. |
| 5 | Notifications | This level is used to indicate state changes within the system (e.g., a routing protocol adjacency transitioning to a down state). |
| 6 | Informational | This level is used to indicate informational messages about the normal operation of the system. |
| 7 | Debugging | This level is used to indicate real-time (debugging) information that is typically used for troubleshooting purposes. |
NOTE: It is important to know that these values are generated by the applications on which the event is generated, and not by the Syslog Server itself.
The message fills the remainder of the Syslog packet. This will usually contain some additional information of the process that generated the message and then the text of the message. This part has two fields: the TAG field and the CONTENT field. The value in the TAG field will be the name of the program or process that generated the message. The CONTENT field contains the details of the message. Cisco IOS prints Syslog messages using the following message format:
mm/dd/yyy:hh/mm/ss:facility-severity-MNEMONIC:description
The following is an example of a Syslog message:
*Mar 1 19:02:05: %SYS-5-CONFIG_I: Configured from console by console
To implement Syslog using the CLI, the following sequence of steps should be taken:
- Enable logging globally by issuing the logging on global configuration command.
- Specify the location to which the logs should be sent using the logging [destination] global configuration command. For example, to send Syslog messages to the local buffer, the logging buffered command would be used, whereas to send Syslog messages to a Syslog Server with the IP address 10.1.1.254, the logging 10.1.1.254 or logging host 10.1.1.254 global configuration commands would be used.
- Specify the level of log messages to send to the Syslog Server. For example, to send Level 7 to the local buffer, an administrator would use the logging buffered debugging global configuration command; however, to send Level 5 logs to a remote Syslog Server, you would use the logging trap notificationsglobal configuration command.
- Specify the facility for Syslog messages using the logging facility global configuration command. Example 8-100 below shows the values that are supported.
Example 8-100: Values Supported for Logging Facility
| Sw1(config)#logging facility ? auth Authorization system cron Cron/at facility daemon System daemons kern Kernel local0 Local use local1 Local use local2 Local use local3 Local use local4 Local use local5 Local use local6 Local use local7 Local use lpr Line printer system mail Mail system news USENET news sys10 System use sys11 System use sys12 System use sys13 System use sys14 System use sys9 System use syslog Syslog itself user User process uucp Unix-to-Unix copy system |