The syslog packet size is limited to 1024 bytes and carries the following information:
Syslog Port numbers:
When sending messages using UDP the destination port is usually 514
When sending messages using TCP the destination port is usually 1468
Syslog Message Format:
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:
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 facility allow administrators to logically separate messages (e.g. write them to separate files, forward them to different destinations, etc.)
Each Syslog message includes a priority value at the beginning of the text. The priority value ranges from 0 to 191 and is made up of a Facility value and a Level value.
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.
The Facility value is a way of determining which process of the machine created the message. Since the Syslog protocol was originally written on BSD Unix, the Facilities reflect the names of Unix processes and Daemons.
The priority value is calculated using the following formula:
Priority = Facility * 8 + Level
Table 4-1. Facility Values
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) 24
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.
The higher severity numbers “include” the lower severity numbers.
Table 4-2: The list of severity Levels:
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
Recommended practice is to use the Notice or Informational level for normal messages.
A detailed explanation of the severity Levels:
DEBUG: Info useful to developers for debugging the app, not useful during operations
INFORMATIONAL: Normal operational messages – may be harvested for reporting, measuring throughput, etc – no action required
NOTICE: Events that are unusual but not error conditions – might be summarized in an email to developers or admins to spot potential problems – no immediate action required
WARNING: Warning messages – not an error, but indication that an error will occur if action is not taken, e.g. file system 85% full – each item must be resolved within a given time
ERROR: Non-urgent failures – these should be relayed to developers or admins; each item must be resolved within a given time
ALERT: Should be corrected immediately – notify staff who can fix the problem – example is loss of backup ISP connection
CRITICAL: Should be corrected immediately, but indicates failure in a primary system – fix CRITICAL problems before ALERT – example is loss of primary ISP connection
EMERGENCY: A “panic” condition – notify all tech staff on call? (earthquake? tornado?) – affects multiple apps/servers/sites…
Event(All event classes) Lists:
Event List can be used to filter syslogs IDs (syslog ID or a range) sent to a logging destination.
Logging filters are used for logging destinations e.g. Syslog Servers, Email, ASDM, Internal buffers, Console, SSH, SNMP trap and attach the Event List to is as well.
Use the message class in order to send all messages associated with a class to the specified output location e.g. auth, config, ha, snmp, vpn, ssl etc.
Simply define the destination IPs to send the logs (usual port number udp/514).