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). We'll discuss both Syslog here and how it applies to Cisco devices.
A Syslog Daemon or Server is an entity that listens to the Syslog messages that are sent to it. You cannot configure a Syslog Daemon 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 two main elements: a Syslog server and a Syslog client. These components are illustrated in the following network diagram:
In the diagram above, the Syslog client (R1) sends Syslog messages to the Syslog sever using UDP as the Transport Layer protocol and specifying a destination port of 514. Syslog messages cannot exceed 1,024 bytes in size; however, there is no minimum length. All Syslog messages contain three distinct parts:
The priority of a Syslog message represents both the Facility and Severity of the message. This number is an 8-bit number. The first 3 bits are the least significant and represent the Severity of the message (with 3 bits you can represent eight different Severities) and the other 5 bits represent the Facility of the message. You can use the Facility and the Severity values to apply certain filters on the events in the Syslog Daemon.
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 values sent by Cisco IOS devices are listed and described in the following list (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.
In Cisco IOS software, the logging facility global configuration command can be used to specify the Syslog facility. The options available with this command are as follows:
R1(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
In order to specify a logging severity level in Cisco IOS software, you must first select the location to which Syslog messages will be sent. Once selected, an administrator can then select the severity of log messages that will be sent to that location. The options available are illustrated in the following output (which depicts logging to the local router buffer):
R1(config)#logging buffered ?
<0-7> Logging severity level
<4096-2147483647> Logging buffer size
alerts – Immediate action needed (severity=1)
critical – Critical conditions (severity=2)
debugging – Debugging messages (severity=7)
discriminator – Establish MD-Buffer association
emergencies – System is unusable (severity=0)
errors – Error conditions (severity=3)
informational – Informational messages (severity=6)
notifications – Normal but significant conditions (severity=5)
warnings – Warning conditions (severity=4)
xml – Enable logging in XML to XML logging buffer
Administrators can use either the Cisco IOS-provided keyword or the number to perform the same action. For example, the logging buffered 7 and the logging buffered debugging commands will both log and send debugging Syslog messages to the specified destination, which is specified by using the logging [destination] global configuration command. In addition to this, it is imperative to remember that the severity level specified includes all other severity levels below it.
For example, if an administrator configures a router with the logging buffered notifications command, the router will log notifications as well as warnings, errors, critical messages, alerts, and emergencies. Similarly, if an administrator configures a router with the logging buffered notifications command, the router will log ALL messages to the local buffer, i.e. Levels 0 through 7 will be included and logged.
The Syslog destination options available in Cisco IOS software are provided, in bold font, in the router output illustrated below:
Hostname or A.B.C.D – IP address of the logging host
buffered – Set buffered logging parameters
buginf – Enable buginf logging for debugging
cns-events – Set CNS Event logging level
console – Set console logging parameters
count – Count every log message and timestamp last occurrence
discriminator – Create or modify a message discriminator
dmvpn – DMVPN Configuration
exception – Limit size of exception flush output
facility – Facility parameter for syslog messages
history – Configure syslog history table
host – Set syslog server IP address and parameters
message-counter – Configure log message to include certain counter value
monitor – Set terminal line (monitor) logging parameters
on – Enable logging to all enabled destinations
origin-id – Add origin ID to syslog messages
persistent – Set persistent logging parameters
queue-limit – Set logger message queue size
rate-limit – Set messages per second limit
reload – Set reload logging level
server-arp – Enable sending ARP requests for syslog servers when first configured
source-interface – Specify interface for source address in logging transactions
trap – Set syslog server logging level
userinfo – Enable logging of user info on privileged mode enabling
The header of a Syslog message contains the timestamp and the hostname or IP address of the device. The timestamp 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 hh:mm:ss privileged EXEC command.
The message part will fill 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 is the name of the program or process that generated the message. The CONTENT field contains the details of the message.
The following screenshot illustrates a typical Syslog message received on a Syslog server. While the Syslog server used in this example is a Kiwi Syslog server, the message format presented will basically be the same in all Syslog servers.
Configuring Syslog on Cisco Routers
- Syslog allows a host to send event notification messages across IP networks
- A Syslog solution is comprised of a Syslog server and a Syslog client
- A Syslog server is an entity that listens to the Syslog messages that are sent to it
- A Syslog client is an entity that generates Syslog messages
- Syslog uses UDP as the underlying transport mechanism, using a destination port of 514
- Syslog messages cannot exceed 1,024 bytes in size
All Syslog messages contain three distinct parts.These parts are the:
1. Priority – this field represents both the Facility and Severity of the message
2. Header – this field contains the timestamp and the hostname or IP address of the device
3. Message – this field the text of the message and includes the TAG and CONTENT fields