Loader

Syslog Overview

Description

Syslog (syslogd) is a standard for forwarding log messages to a system, often over an IP network. The term "syslog" refers to the syslog protocol, which sends a small message to a syslog daemon (syslogd) using User Datagram Protocol (UDP), Transmission Control Protocol (TCP), or Transport Layer Security (TLS) in clear text. Syslog can be used for managing computer systems and security auditing servers and applications. It is supported by a wide variety of devices and platforms.

Purpose

The most common method of providing feedback to system administrators of switches is via the Syslog mechanism. Syslog is defined in RFC3164 and updated by RFC5424. Syslog allows xNIX-type systems to emit syslog messages to a syslog server. The syslog server typically consolidates events from multiple systems and also allows for the filtering and sorting of syslog messages. Syslog messages can be used to recognize issues with equipment and to post analysis and debugging of system issues.

Service providers use "syslog" to collect, report and take action on data and events that network elements (NEs) detect. This helps service providers in a few areas. The first is proactive monitoring of user activity that affects the configuration of the element. As users make changes that affect the provisioning of data within the Optical Line Terminal (OLT) and Optical Network Terminal (ONT), events are sent to a syslog server. This allows the higher-level Operating System Service (OSS) to track user changes.

Another use of syslog is for tracking security-related events. Presently, the Panorama PON EMS supports a centralized syslog facility. This new feature consists of adding a syslog facility to the OLT. The OLT tracks security events associated with user authentication and provisioning changes. It also allows administrators to designate where and how the monitored data will be reported.

Syslog utilizes User Datagram Protocol (UDP) as its underlying transport layer mechanism. The UDP port that has been assigned to syslog is 0514. It is recommended that the source port also be 0514 to indicate that the message is from the syslog process of the sender. If the sender uses a source port other than 0514, then it is recommended, and has been considered to be good form, that subsequent messages are from a single consistent port.

A syslog command is also available through the CLI User Interface/BOLT CLI Manual (refer to the CLI User Interface Guide or the BOLT CLI Manual) to the OLT and provides, as a minimum:

  • Existing information logged in event and alarm logs
  • Security events, including login, logout etc.
  • All provisioning changes from Web, EMS, and GUI including source and user
  • All new events created going forward
     

Syslog consists of a number of components:

 

  • An “Originator” generates syslog content to be carried in a message.
  • A “Collector” gathers syslog content for further analysis.

Syslog is an unacknowledged protocol and, therefore, if some assurance of delivery is required, then TCP or TLS must be used as the transport protocol. If either Transmission Control Protocol (TCP) or Transport Layer Security (TLS) protocols are utilized for syslog, the recommended port to be used is 6514.

Refer to the following Requests for Comment (RFCs) for specific details on the syslog protocol and the transmission of syslog messages over the supported protocols:

  • RFC5424 – syslog Protocol
  • RFC5426 – Transmission of Syslog Messages over UDP
  • RFC6587 – Transmission of Syslog Messages over TCP
  • RFC5425 – Transmission of Syslog Messages over TLS

Syslog Daemon Configuration File

The syslog daemon (syslogd) processing is controlled by a configuration file called /etc/syslog.conf in which logging rules and output destinations for error messages, authorization violation messages, and trace data are defined. Logging rules are defined by using a facility name and a severity level. The facility name and severity level are passed on the logging request from an application when it wants to log a message.

Facility Name

Facility names are used to specify what type of program or software is logging the message. This lets the configuration file specify that messages from different facilities are handled differently. The list of facilities is:

 

Number

Keyword

Description

0

kern

kernel messages

1

user

user-level messages

2

mail

mail system

3

daemon

system daemons

4

auth

security/authorization messages

5

syslog

Messages generated internally by syslogd

6

lpr

line printer system

7

news

network news system

8

uucp

UUCP subsystem

9

 

clock daemon

10

authpriv

security/authorization messages

11

ftp

FTP daemon

12

NTP subsystem

13

log audit

14

log alert

15

cron

clock daemon

16

local0

local use 0 (local0)

17

local1

local use 1(local1)

18

local2

local use 2(local2)

19 local3 local use 3(local3)
20 local4 local use 4(local4)
21 local5 local use 5(local5)
22 local6 local use 6(local6)
23 local7 local use 7(local7)

The mapping between Facility Number and Keyword is not uniform over different operating systems and different syslog implementations. For cron, either 9 or 15, or both may be used. The confusion is even greater regarding auth/authpriv. 4 and 10 are most common, but 13 and 14 may also be used.

Severity Levels

There are eight security levels defined, consisting of:

Code

Severity

Keyword

Description

General Description

0

Emergency

emer

System is unusable

An emer condition usually affects multiple apps/servers/sites. At this level, it would usually notify all tech staff on call.

1

Alert

alert

Action must be taken immediately

It should be corrected immediately, therefore notify staff who can fix the problem. An example would be the loss of a primary ISP connection.

2

Critical

crit

Critical conditions

Should be corrected immediately, but indicates failure in a secondary system. An example is a loss of a backup ISP connection.

3

Error

error

Error conditions

Non-urgent failures should be relayed to developers or admins; each item must be resolved within a given time.

4

Warning

warn

Warning conditions

Warning messages, not an error, but indicate 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.

5

Notice

notice

Normal but significant condition

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.

6

Informational

info

Informational messages

Normal operational messages - may be harvested for reporting, measuring throughput, etc. - no action required.

7

Debug

debug

Debug-level messages

Info useful to delevopers for debugging the application, not useful during operations.

In the Tellabs implementation of syslog, the following mapping occurs for alarms reported to the OLT:

OLT Alarm

Reported assyslog Severity

Critical

Critical

Major

Error

Minor

Warning

Classes

There are thirteen classes defined. They are:

 

Class

Description

AUTH

Authentication-related events, i.e., login logout, etc. Certificate-related information is displayed here is not already covered by an EVNT which goes to the EMS.

ALRM

Reporting of an Alarm Set or Clear

ACL

Reporting of an ACL violation

CLI

Reporting of changes initiated by CLI commands on the OLT

DNLD

Reporting of download and commanded switch events

EVNT

Reporting of Event message equivalent to the EMS event reports

HTTP

Reporting of HTTP file transfer events

PROV

Reporting of provisioning changes from the EMS

PLATFM

Reporting of platform events, i.e., plug in, plug out, card reboots, startups, etc.

RADIUS

Reporting of events related to RADIUS

SNMP

Reporting of events related to the SNMP agent

SWITCH

Switching error/debug messages

VOIP

Reporting of significant voice events

Reporting Requirements

The reportable Syslog Events and the methodology of reporting those events is discussed in the following sections. At a minimum, the following events are logged.

  • Login / Logout Events – Security Events
  • Failed Login Attempts – Security Events
  • Port State Change Events – Network interface failures
  • Craft Provisioning Command Events – Log the content of all craft commands and the user that issued the command (Refer to the Tellabs 1100
  • Alarm Events – Show alarm set/clear events
  • Failed Processes – Kernel events where processes are going down
  • Card Reset Commands – A user-initiated card reset event
  • Restart Events – System restarts
  • Protection Events – ESU, TDU, or PON protection events
  • Exception Log Entries - Exception log entry events
  • Authentication Fail Events for 802.1x
  • Spanning Tree Topology Events
  • Spanning Tree Root Violations

Syslog Message Format

Syslog message consists of the following fields.

Field

Description

PRI

Priority – The priority value is calculated by multiplying the Facility Level  by 8 and then adding the Severity Level.

Facility

Defines what part of the system has logged the event. . Most systems allow dynamic mapping of events to local use fields. The EMS and OLT support the capability to configure the Facility that is put into reported syslog events. The default is local7.

Severity

Indicates the Severity Level  of the event to the system.

Version

Version of the syslog protocol. The version is 1, which reflects the RFC 5424 version of the protocol.

Timestamp

Timestamp of the syslog message. The timestamp reflects the time, within the local time zone of the OLT, the message was generated.

Hostname

Hostname of the syslog originator. This is the hostname of the OLT, if configured. If a hostname is not configured, the IP address of the ESU is used.

APP-NAME

Defines the device or application that originated the message. It has no semantics and is used as a filter on the collector.

PROCID

The procid is a value that is included in the messages, having no interoperable meaning except that a change in the value indicates a discontinuity in syslog reporting. Typically, it is used to give the process name of process id. Any other relevant semantics can be used to relate the event to processes or transactions on the device.

MSGID

The message IF gives the type of message, typically used by devices like firewalls to indicate protocol and direction (TCPIN/TCPOUT). The MSGID is a string without further semantics and is intended for the filtering of messages on the collector.

STRUCTURED-DATA

Provides a mechanism to express information in a well-defined, easily parseable and interpretable data format. There are multiple usage scenarios. For example, it may express meta-information about the syslog message or application-specific information such as traffic counters or IP addresses.

SD-ELEMENT

An SD-ELEMENT consists of a name and parameter name-value pairs the name-value pairs are referred to as “SD-PARAM”.

MSG

The MSG part contains a free-form message providing information about the event.

Note: The OLT supports a value of NIL for those fields where no values available are specified.

 

FEEDBACK: Are you happy with this material?