Before we get in configuration of Syslog Messages will see what are syslog messages and usage of syslog messages in day to day network management.
What are these Syslog messages?
The Syslogs, 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 [UDP based].
Each Syslog message refer to a facility (auth, authpriv, daemon, cron, ftp, lpr, kern, mail, news, syslog, user, uucp, local0, ... , local7 ). Facility here means component which is source of Syslog message generation,It is like a categorization of the event just occurred.
And each Syslog assigned a priority/Severity level (they are Emergency, Alert, Critical, Error, Warning, Notice, Info or Debug) by the sender of the message.
Every Syslog Message has information of device hostname, message text along with Severity and Facility details.
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.
These messages received at independent Syslog server or integrated as part of NMS systems, which will be used for regular trouble shoot, analyze, audit and debugging any sort of issues device specific, access related and component level failures etc. Some of System even go beyond just receiving and do some kind proactive things like generating an Alert, Notifying to Network admin via E-mail and pagers etc.
Most vendors provide more utility commands to configure Severity level of events the device needs to be tracked at each Facility or global mode and reported to a listener called Syslog Receiver (Syslog Host).
As you might know Syslog uses UDP protocol at Transport Layer and Syslog host listens at port number 514 by default. Some of the available Syslog servers (Syslog receivers) are customized to listen on specified port (UDP) also Device vendors too allowed to change the port at which syslogs can be sent at Device level.
Let me go through how we can configure Syslogs Messages at Cisco Devices (IOS based devices).
Configuration of Syslog on Cisco IOS devices:
To enable syslog messages on Cisco devices, you need to login to device via telnet (most Cisco devices enabled in this way) and go to configuration mode.
Here is the illustration of commands and their sequence:
Step 1: Logging in to Cisco Device Global configuration mode
Telnet <ip Address>
User Access Verification
Password:<enter telnet password>
CiscoDevice>en
Password:<enter Enable Password>
CiscoDevice#config terminal
Enter configuration commands, one per line. End
Step 2: Configuring Severity level
Enable the trap/Severity level you would like to watch on. There will be 8 types of Syslog messages. We call them as Severity of particular event occurred. Every event is categorized one of these Global severity levels irrespective of which facility generated. So be sure what severity level of events to be notified to your Syslog Host. Be care when you set the level to debug which may slow down your device as well as network if it is main core device of your network access.
CiscoDevice(config)#logging trap <0-7>
Step 3: Configuring Facility
This is an optional configuration; even if you don't configure this you could receive syslogs at Syslog Server. By default, Cisco IOS devices 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.
Step 4: Configuring Source interface to send Syslog messages
CiscoDevice(config)#logging source-interface <management interface>
For switched the management interface would be default Vlan 1(for most Cisco devices)
Step 5: Configuring Syslog Server IP Address
CiscoDevice(config)#logging Host <Syslog Server>
Step 6: Verifying Running Configuration
CiscoDevice#sh running-config | inc logging
Step 7: Logged Syslog messages, statistics at Device
"show logging" gives you currently logged events, statistics, hosts receiving syslogs etc.
Another command "show logging count" gives over all count, facility wise information. To have this you need to configure following commands.
CiscoDevice(config)#logging count<cr>
Step 8: Verifying Syslog messages receiving at Syslog Host
You could verify the syslog messages by having a free Syslog Receiver running at your System. One of such free tool is available at Kiwi, here is the link.
http://www.kiwisyslog.com/kiwi-syslog-server-overview/
Install this Software and start the Syslog Daemon to listening on port 514 for the Syslog messages.
You may go to one of the device you just configured for syslog traps and do some configuration changes; you will immediately see the messages floating in to Syslog Daemon just started.
In case you are not seeing any syslog messages even after following all the above steps, please make sure of these:
- Check the Management IP configured interface is the source interface for logging. This will happen in some of few Cisco Devices.
- Check the Syslog Host ip, Syslog Severity level and Source interface is the Management interface.
- Also check your Syslog server filtering IP address from which it can receive.
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 describes the event.
