rfc3164.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,358 行 · 第 1/5 页

Network Working Group                                         C. Lonvick
Request for Comments: 3164                                 Cisco Systems
Category: Informational                                      August 2001


                        The BSD syslog Protocol

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document describes the observed behavior of the syslog protocol.
   This protocol has been used for the transmission of event
   notification messages across networks for many years.  While this
   protocol was originally developed on the University of California
   Berkeley Software Distribution (BSD) TCP/IP system implementations,
   its value to operations and management has led it to be ported to
   many other operating systems as well as being embedded into many
   other networked devices.

Table of Contents

   1. Introduction....................................................2
   1.1 Events and Generated Messages..................................3
   1.2 Operations of the Message Receivers............................5
   2. Transport Layer Protocol........................................5
   3. Definitions and Architecture....................................5
   4. Packet Format and Contents......................................7
   4.1 syslog Message Parts...........................................8
   4.1.1 PRI Part.....................................................8
   4.1.2 HEADER Part of a syslog Packet..............................10
   4.1.3 MSG Part of a syslog Packet.................................11
   4.2 Original syslog Packets Generated by a Device.................12
   4.3 Relayed syslog Packets........................................12
   4.3.1 Valid PRI and TIMESTAMP.....................................13
   4.3.2 Valid PRI but no TIMESTAMP or invalid TIMESTAMP.............13
   4.3.3 No PRI or Unidentifiable PRI................................14
   5. Conventions....................................................14
   5.1 Dates and Times...............................................15
   5.2 Domain Name and Address.......................................15



Lonvick                      Informational                      [Page 1]

RFC 3164                The BSD syslog Protocol              August 2001


   5.3 Originating Process Information...............................15
   5.4 Examples......................................................16
   6. Security Considerations........................................18
   6.1 Packet Parameters.............................................19
   6.2 Message Authenticity..........................................19
   6.2.1 Authentication Problems.....................................19
   6.2.2 Message Forgery.............................................20
   6.3 Sequenced Delivery............................................20
   6.3.1 Single Source to a Destination..............................20
   6.3.2 Multiple Sources to a Destination...........................21
   6.3.3 Multiple Sources to Multiple Destinations...................21
   6.3.4 Replaying...................................................22
   6.4 Reliable Delivery.............................................22
   6.5 Message Integrity.............................................22
   6.6 Message Observation...........................................22
   6.7 Message Prioritization and Differentiation....................23
   6.8 Misconfiguration..............................................24
   6.9 Forwarding Loop...............................................24
   6.10 Load Considerations..........................................25
   7. IANA Considerations............................................25
   8. Conclusion and Other Efforts...................................25
   Acknowledgements..................................................26
   References........................................................27
   Author's Address..................................................28
   Full Copyright Statement..........................................29

1. Introduction

   Since the beginning, life has relied upon the transmission of
   messages.  For the self-aware organic unit, these messages can relay
   many different things.  The messages may signal danger, the presence
   of food or the other necessities of life, and many other things.  In
   many cases, these messages are informative to other units and require
   no acknowledgement.  As people interacted and created processes, this
   same principle was applied to societal communications.  As an
   example, severe weather warnings may be delivered through any number
   of channels - a siren blowing, warnings delivered over television and
   radio stations, and even through the use of flags on ships.  The
   expectation is that people hearing or seeing these warnings would
   realize their significance and take appropriate action.  In most
   cases, no responding acknowledgement of receipt of the warning is
   required or even desired.  Along these same lines, operating systems,
   processes and applications were written to send messages of their own
   status, or messages to indicate that certain events had occurred.
   These event messages generally had local significance to the machine
   operators.  As the operating systems, processes and applications grew
   ever more complex, systems were devised to categorize and log these
   diverse messages and allow the operations staff to more quickly



Lonvick                      Informational                      [Page 2]

RFC 3164                The BSD syslog Protocol              August 2001


   differentiate the notifications of problems from simple status
   messages.  The syslog process was one such system that has been
   widely accepted in many operating systems.  Flexibility was designed
   into this process so the operations staff have the ability to
   configure the destination of messages sent from the processes running
   on the device.  In one dimension, the events that were received by
   the syslog process could be logged to different files and also
   displayed on the console of the device.  In another dimension, the
   syslog process could be configured to forward the messages across a
   network to the syslog process on another machine. The syslog process
   had to be built network-aware for some modicum of scalability since
   it was known that the operators of multiple systems would not have
   the time to access each system to review the messages logged there.
   The syslog process running on the remote devices could therefore be
   configured to either add the message to a file, or to subsequently
   forward it to another machine.

   In its most simplistic terms, the syslog protocol provides a
   transport to allow a machine to send event notification messages
   across IP networks to event message collectors - also known as syslog
   servers.  Since each process, application and operating system was
   written somewhat independently, there is little uniformity to the
   content of syslog messages.  For this reason, no assumption is made
   upon the formatting or contents of the messages.  The protocol is
   simply designed to transport these event messages.  In all cases,
   there is one device that originates the message.  The syslog process
   on that machine may send the message to a collector.  No
   acknowledgement of the receipt is made.

   One of the fundamental tenets of the syslog protocol and process is
   its simplicity.  No stringent coordination is required between the
   transmitters and the receivers.  Indeed, the transmission of syslog
   messages may be started on a device without a receiver being
   configured, or even actually physically present.  Conversely, many
   devices will most likely be able to receive messages without explicit
   configuration or definitions.  This simplicity has greatly aided the
   acceptance and deployment of syslog.

1.1 Events and Generated Messages

   The writers of the operating systems, processes and applications have
   had total control over the circumstances that would generate any
   message.  In some cases, messages are generated to give status. These
   can be either at a certain period of time, or at some other interval
   such as the invocation or exit of a program.  In other cases, the
   messages may be generated due to a set of conditions being met.  In
   those cases, either a status message or a message containing an alarm
   of some type may be generated.  It was considered that the writers of



Lonvick                      Informational                      [Page 3]

RFC 3164                The BSD syslog Protocol              August 2001


   the operating systems, processes and applications would quantify
   their messages into one of several broad categories.  These broad
   categories generally consist of the facility that generated them,
   along with an indication of the severity of the message.  This was so
   that the operations staff could selectively filter the messages and
   be presented with the more important and time sensitive notifications
   quickly, while also having the ability to place status or informative
   messages in a file for later perusal.   Other options for displaying
   or storing messages have been seen to exist as well.

   Devices MUST be configured with rules for displaying and/or
   forwarding the event messages.  The rules that have been seen are
   generally very flexible.  An administrator may want to have all
   messages stored locally as well as to have all messages of a high
   severity forwarded to another device.  They may find it appropriate
   to also have messages from a particular facility sent to some or all
   of the users of the device and displayed on the system console.
   However the administrator decides to configure the disposition of the
   event messages, the process of having them sent to a syslog collector
   generally consists of deciding which facility messages and which
   severity levels will be forwarded, and then defining the remote
   receiver.  For example, an administrator may want all messages that
   are generated by the mail facility to be forwarded to one particular
   event message collector.  Then the administrator may want to have all
   kernel generated messages sent to a different syslog receiver while,
   at the same time, having the critically severe messages from the
   kernel also sent to a third receiver.  It may also be appropriate to
   have those messages displayed on the system console as well as being
   mailed to some appropriate people, while at the same time, being sent
   to a file on the local disk of the device.  Conversely, it may be
   appropriate to have messages from a locally defined process only
   displayed on the console but not saved or forwarded from the device.
   In any event, the rules for this will have to be generated on the
   device.  Since the administrators will then know which types of
   messages will be received on the collectors, they should then make
   appropriate rules on those syslog servers as well.

   The contents of a message have also been at the discretion of its
   creator.  It has been considered to be good form to write the
   messages so that they are informative to the person who may be
   reading them.  It has also been considered good practice to include a
   timestamp and some indication of the sending device and the process
   that originated it in the messages.  However, none of those are
   stringently required.

   It should be assumed that any process on any device might generate an
   event message.  This may include processes on machines that do not
   have any local storage - e.g., printers, routers, hubs, switches, and



Lonvick                      Informational                      [Page 4]

RFC 3164                The BSD syslog Protocol              August 2001


   diskless workstations.  In that case, it may be imperative that event
   messages are transported to a collector so that they may be recorded
   and hopefully viewed by an operator.

1.2 Operations of the Message Receivers

   It is beyond the scope of this document to specify how event messages
   should be processed when they are received.  Like the operations
   described in Section 1.1, they generally may be displayed to the
   appropriate people, saved onto disk, further forwarded, or any
   combination of these.  The rules for determining the disposition of
   received messages have been seen to be identical to the rules for
   determining the disposition of locally generated messages.

   As a very general rule, there are usually many devices sending
   messages to relatively fewer collectors.  This fan-in process allows
   an administrator to aggregate messages into relatively few
   repositories.

2. Transport Layer Protocol

   syslog uses the user datagram protocol (UDP) [1] as its underlying
   transport layer mechanism.  The UDP port that has been assigned to
   syslog is 514.  It is RECOMMENDED that the source port also be 514 to
   indicate that the message is from the syslog process of the sender,
   but there have been cases seen where valid syslog messages have come
   from a sender with a source port other than 514.  If the sender uses
   a source port other than 514 then it is RECOMMENDED and has been
   considered to be good form that subsequent messages are from a single
   consistent port.

3. Definitions and Architecture

   The following definitions will be used in this document.

         A machine that can generate a message will be called a
         "device".

         A machine that can receive the message and forward it to
         another machine will be called a "relay".

         A machine that receives the message and does not relay it to