The most common method of accessing system messages that networking devices provide is to use a protocol called syslog.
Syslog is a term used to describe a standard. It is also used to describe the protocol developed for that standard. The syslog protocol was developed for UNIX systems in the 1980s, but was first documented as RFC 3164 by IETF in 2001.
Syslog uses UDP port 514 to send event notification messages across IP networks to event message collectors.
Many networking devices support syslog, including: routers, switches, application servers, firewalls, and other network appliances. The syslog protocol allows networking devices to send their system messages across the network to syslog servers.
There are several different syslog server software packages for Windows and UNIX. Many of them are freeware.
The syslog logging service provides three primary functions:
- The ability to gather logging information for monitoring and troubleshooting
- The ability to select the type of logging information that is captured
- The ability to specify the destinations of captured syslog messages
On Cisco network devices, the syslog protocol starts by sending system messages and debug output to a local logging process internal to the device.
These messages can be retrieved without the need of accessing the actual device. Log messages and outputs stored on the external server can be pulled into various reports for easier reading.
Alternatively, syslog messages may be sent to an internal buffer. Messages sent to the internal buffer are only viewable through the CLI of the device.
Finally, the network administrator may specify that only certain types of system messages are sent to various destinations. For example, the device may be configured to forward all system messages to an external syslog server. However, debug-level messages are forwarded to the internal buffer and are only accessible by the administrator from the CLI.
- Logging buffer (RAM inside a router or switch)
- Console line
- Terminal line
- Syslog server
Syslog message format
The smaller numerical levels are the more critical syslog alarms. The severity level of the messages can be set to control where each type of message is displayed (i.e. on the console or the other destinations). The complete list of syslog levels:
|Severity Name||Severity Level||Explanation|
|Emergency||Level 0||System Unusable|
|Alert||Level 1||Immediate Action Needed|
|Notification||5||Normal, but significant Condition|
Note: You can remember the order above with the sentence: “Eventually All Critical Errors Will Not Involve Damage”.
Each syslog level has its own meaning:
- Warning Level – Emergency Level – These messages are error messages about software or hardware malfunctions; these types of messages mean that the functionality of the device is affected. The severity of the issue determines the actual syslog level applied.
- Debugging Level – This level indicates that the messages are output generated from issuing various debug commands.
- Notification Level – The notifications level is only for information, device functionality is not affected. Interface up or down transitions, and system restart messages are displayed at the notifications level.
In addition to specifying the severity, syslog messages also contain information on the facility. Syslog facilities are service identifiers that identify and categorize system state data for error and event message reporting. The logging facility options that are available are specific to the networking device. For example, Cisco 2960 Series switches running Cisco IOS Release 15.0(2) and Cisco 1941 routers running Cisco IOS Release 15.2(4) support 24 facility options that are categorized into 12 facility types.
Some common syslog message facilities reported on Cisco IOS routers include:
- OSPF protocol
- SYS operating system
- IP security (IPsec)
- Interface IP (IF)
By default, the format of syslog messages on the Cisco IOS Software is as follows:
seq no: timestamp: %facility-severity-MNEMONIC: description
|seq no||Stamps log messages with a sequence number only if the
|timestamp||Date and time of the message or event, which appears only if the
|facillity||the facillity to which the message refers|
|severity||Single-digit code from 0 to 7 that is the severity of the message|
|MNEMONIC||text string that uniquely describes the message|
|description||Text string containing detailed information about the event being reported|
Log messages can be time-stamped and the source address of syslog messages can be set. This enhances real-time debugging and management.
service timestamps log uptime global configuration mode command is entered, the amount of time since the switch last booted is displayed on logged events.
A more useful version of this command applies the datetime keyword in place of the uptime keyword;
service timestamps log datetime , this forces each logged event to display the date and time associated with the event.
When using the datetime keyword, the clock on the networking device must be set. This can be accomplished in one of two ways:
- Manually set, using the
- Automatically set, using the Network Time Protocol (NTP)
Enable millisecond (msec) timestamps using the service timestamps command:
router(config)#service timestamps debug datetime msec router(config)#service timestamps log datetime msec
These commands add time stamps to debugs in the format MMM DD HH:MM:SS, indicating the date and time according to the system clock. If the system clock has not been set, the date and time are preceded by an asterisk (*) to indicate that the date and time are probably not correct.
It is generally advisable to configure millisecond timestamps as this provides high level of clarity when looking at debug outputs. Millisecond timestamps provide a better indication of the timing of the various debugs events relative to each other. However, note that, when the console port outputs a lot of messages, they might not correlate with the actual timing of the event. For example, if you enable debug x25 all on a box that has 200 VCs, and the output is logged to the buffer (using the no logging console and logging buffered commands), the timestamp displayed in the debug output (within the buffer) might not be the exact time when the packet passes through the interface. Therefore, do not use msec timestamps to prove performance issues, but to obtain relative information on when events occur.
Recall that NTP is a protocol that is used to allow network devices to synchronize their time settings with an NTP server.
To allow the software clock to be synchronized by an NTP time server, use the
ntp server ip-address command in global configuration mode.
ntp master number to set a router as NTP server.
To view syslog messages, a syslog server must be installed on a workstation in the network. Eg. kiwi syslog server.
The syslog server provides a relatively user-friendly interface for viewing syslog output. The server parses the output and places the messages into pre-defined columns for easy interpretation. If timestamps are configured on the networking device sourcing the syslog messages, then the date and time of each message displays in the syslog server output.
By default, Cisco routers and switches send log messages for all severity levels to the console.
On some IOS versions, the device also buffers log messages by default. To enable these two settings, use the
logging console and
logging buffered global configuration commands, respectively.
show logging command displays the default logging service settings on a Cisco router.
On most Cisco IOS routers, the default severity level is 7, debugging.
The output also notes that 32 such messages have been logged.
The second highlighted line states that this router logs to an internal buffer. Because this router has enabled logging to an internal buffer, the show logging command also lists the messages in that buffer.
configure syslog client
There are three steps to configuring the router to send system messages to a syslog server where they can be stored, filtered, and analyzed:
Step 1. Configure the destination hostname or IP address of the syslog server in global configuration mode:
R1(config)# logging 192.168.1.3
Step 2. Control the messages that will be sent to the syslog server with the
level global configuration mode command. For example, to limit the messages to levels 4 and lower (0 to 4), use one of the two equivalent commands:
R1(config)# logging trap 4 R1(config)# logging trap warning
Step 3. Optionally, configure the source interface with the logging source-interface interface-type interface number global configuration mode command. This specifies that syslog packets contain the IPv4 or IPv6 address of a specific interface, regardless of which interface the packet uses to exit the router. For example, to set the source interface to g0/0, use the following command:
R1(config)# logging source-interface g0/0
show logging command, some pipe options:
show logging | include changed state
show logging | begin June 12
if you want to create a syslog message entry without shutting down a interface or other action, simply use the syntax:
send log [severity] [text to send]
send log 4 Warning!!Warning!!!
timestamp showing the UTC time instead of local time:
service timestamps log datetime localtime show-timezone
Cisco routers can log information regarding configuration changes, ACL violations, interface status, CPU utilization, and many other types of events.
For example, use the
memory free low-watermark threshold io and
memory free low-watermark processor commands to set memory thresholds. The router will send notifications, specified in kilobytes to the syslog server when available free memory falls below the threshold. The router will send notifications again when the available free memory rises to five percent above the threshold.
- Network Flow and Flexible netflow
- SNMP (CCNA4, security)
- Graylog 2
- Monitor Linux Service with PRTG SSH script