没有合适的资源?快使用搜索试试~ 我知道了~
首页syslog协议RFC文档
syslog协议RFC文档
![](https://csdnimg.cn/release/wenkucmsfe/public/img/star.98a08eaa.png)
syslogRFC文档,包含 syslog介绍、 传输协议、 体系结构、 包格式、 安全设置等
资源详情
资源推荐
![](https://csdnimg.cn/release/download_crawler_static/617495/bg1.jpg)
RFC3164 - The BSD Syslog Protocol
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
![](https://csdnimg.cn/release/download_crawler_static/617495/bg2.jpg)
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
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
![](https://csdnimg.cn/release/download_crawler_static/617495/bg3.jpg)
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
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
![](https://csdnimg.cn/release/download_crawler_static/617495/bg4.jpg)
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
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,
![](https://csdnimg.cn/release/download_crawler_static/617495/bg5.jpg)
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
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
剩余29页未读,继续阅读
![pdf](https://img-home.csdnimg.cn/images/20210720083512.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://profile-avatar.csdnimg.cn/default.jpg!1)
lrbnew
- 粉丝: 0
- 资源: 5
上传资源 快速赚钱
我的内容管理 收起
我的资源 快来上传第一个资源
我的收益
登录查看自己的收益我的积分 登录查看自己的积分
我的C币 登录后查看C币余额
我的收藏
我的下载
下载帮助
![](https://csdnimg.cn/release/wenkucmsfe/public/img/voice.245cc511.png)
会员权益专享
最新资源
- 电力电子系统建模与控制入门
- SQL数据库基础入门:发展历程与关键概念
- DC/DC变换器动态建模与控制方法解析
- 市***专有云IaaS服务:云主机与数据库解决方案
- 紫鸟数据魔方:跨境电商选品神器,助力爆款打造
- 电力电子技术:DC-DC变换器动态模型与控制
- 视觉与实用并重:跨境电商产品开发的六重价值策略
- VB.NET三层架构下的数据库应用程序开发
- 跨境电商产品开发:关键词策略与用户痛点挖掘
- VC-MFC数据库编程技巧与实现
- 亚马逊新品开发策略:选品与市场研究
- 数据库基础知识:从数据到Visual FoxPro应用
- 计算机专业实习经验与项目总结
- Sparkle家族轻量级加密与哈希:提升IoT设备数据安全性
- SQL数据库期末考试精选题与答案解析
- H3C规模数据融合:技术探讨与应用案例解析
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
![](https://img-home.csdnimg.cn/images/20220527035711.png)
![](https://img-home.csdnimg.cn/images/20220527035711.png)
![](https://img-home.csdnimg.cn/images/20220527035111.png)
安全验证
文档复制为VIP权益,开通VIP直接复制
![](https://csdnimg.cn/release/wenkucmsfe/public/img/green-success.6a4acb44.png)