[要約] RFC 5675は、SNMP通知をSYSLOGメッセージにマッピングする方法を提案しています。その目的は、SNMPイベントをSYSLOG形式で記録し、ネットワーク管理者が効果的にネットワークの状態を監視できるようにすることです。
Network Working Group V. Marinov
Request for Comments: 5675 J. Schoenwaelder
Category: Standards Track Jacobs University Bremen
October 2009
Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages
Syslogメッセージへのシンプルなネットワーク管理プロトコル（SNMP）通知のマッピング
Abstract
概要
This memo defines a mapping from Simple Network Management Protocol (SNMP) notifications to SYSLOG messages.
このメモは、Simple Network Management Protocol（SNMP）通知からSyslogメッセージへのマッピングを定義します。
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、BSDライセンスに記載されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. SNMP Notifications . . . . . . . . . . . . . . . . . . . . 3
2.2. SYSLOG Notifications . . . . . . . . . . . . . . . . . . . 5
3. Mapping SNMP Notifications to SYSLOG Messages . . . . . . . . 5
3.1. SYSLOG Header . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Structured Data . . . . . . . . . . . . . . . . . . . . . 7
3.3. MSG Data . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Relationship to the SYSLOG-MSG-MIB . . . . . . . . . . . . . . 10
5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
SNMP and SYSLOG are two widely used protocols to communicate event notifications. Although co-existence of several management protocols in one operational environment is possible, certain environments require that all event notifications be collected by a single system daemon, such as a SYSLOG collector or an SNMP notification receiver, via a single management protocol. In such environments, it is necessary to translate event notifications between management protocols.
SNMPとSyslogは、イベント通知を通信するために広く使用されている2つのプロトコルです。1つの運用環境におけるいくつかの管理プロトコルと共存することは可能ですが、特定の環境では、すべてのイベント通知を、SyslogコレクターやSNMP通知レシーバーなどの単一の管理プロトコルを介して、すべてのイベント通知を収集する必要があります。このような環境では、管理プロトコル間でイベント通知を翻訳する必要があります。
The latest version of SYSLOG, specified in [RFC5424], supports a structured data element format. Structured data elements allow us to map between SNMP notifications and SYSLOG messages without losing information. In this memo, we specify a concrete mapping from SNMP event notifications [RFC3416] into SYSLOG messages [RFC5424]. We specify how the SYSLOG message format should be utilized to carry the information contained in an SNMP notification message. A new SYSLOG structured data element is defined, which carries the PDU portion of an SNMP notification message.
[RFC5424]で指定されたSyslogの最新バージョンは、構造化されたデータ要素形式をサポートしています。構造化されたデータ要素を使用すると、情報を失うことなく、SNMP通知とsyslogメッセージの間でマッピングできます。このメモでは、SNMPイベント通知[RFC3416]からSyslogメッセージ[RFC5424]へのコンクリートマッピングを指定します。SNMP通知メッセージに含まれる情報を携帯するために、syslogメッセージ形式を使用する方法を指定します。新しいSyslog構造化データ要素が定義されており、SNMP通知メッセージのPDU部分を伝達します。
A system that has the capability of receiving SNMP notification messages from an SNMP notification originator and sending the SNMP data contained inside in a SYSLOG message format to a SYSLOG collector is referred to in this memo as an "SNMP-to-SYSLOG translator". By definition, such a system should have an SNMP notification receiver application and a SYSLOG originator running in order to be able to perform the functions of an "SNMP-to-SYSLOG translator".
SNMP通知オリジネーターからSNMP通知メッセージを受信し、syslogメッセージ形式に含まれるSNMPデータをSyslogコレクターに送信する機能を備えたシステムは、このメモで「SNMP-to-Syslog Translator」と呼ばれます。定義上、このようなシステムには、「SNMPからシスログ翻訳者」の関数を実行できるように、SNMP通知受信者アプリケーションと実行されるSyslogオリジネーターが必要です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
A detailed introduction to the SNMP Management Framework can be found in [RFC3410]. The SNMP Management Architecture is described in [RFC3411]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB [RFC3418]. Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI) [RFC2578].
SNMP管理フレームワークの詳細な紹介は、[RFC3410]にあります。SNMP管理アーキテクチャは[RFC3411]で説明されています。管理されたオブジェクトは、管理情報ベースまたはMIBと呼ばれる仮想情報ストアを介してアクセスされます[RFC3418]。MIBのオブジェクトは、管理情報の構造（SMI）[RFC2578]の構造で定義されたメカニズムを使用して定義されます。
An SNMP notification message is generated and transmitted by an SNMP entity on behalf of a notification originator application [RFC3413]. SNMP notifications are often used to notify a notification receiver application at a logically remote SNMP entity that an event has occurred or that a certain condition is present. There are two types of SNMP protocol operations that are associated with SNMP notification messages [RFC3416]:
SNMP通知メッセージは、通知オリジナルアプリケーション[RFC3413]に代わってSNMPエンティティによって生成および送信されます。SNMP通知は、イベントが発生した、または特定の条件が存在することを、論理的にリモートSNMPエンティティで通知レシーバーアプリケーションに通知するためによく使用されます。SNMP通知メッセージに関連付けられているSNMPプロトコル操作には2つのタイプがあります[RFC3416]：
o SNMPv2-Trap-PDU, an unconfirmed notification delivery mechanism
o SNMPV2-TRAP-PDU、未確認の通知配信メカニズム
o InformRequest-PDU, a confirmed notification delivery mechanism
o InformRequest-PDU、確認された通知配信メカニズム
The scopedPDU portion of an SNMPv3 trap or inform message has the following format [RFC3412]:
snmpv3トラップまたは情報メッセージのscopedpdu部分には、次の形式[rfc3412]があります。
ScopedPDU ::= SEQUENCE {
contextEngineID OCTET STRING,
contextName OCTET STRING,
data ANY -- e.g., PDUs as defined in [RFC3416]
}
The data member of the SEQUENCE ScopedPDU carries an SNMPv2-Trap-PDU or an InformRequest-PDU. They both have the same structure:
シーケンスSCOPEDPDUのデータメンバーは、SNMPV2-TRAP-PDUまたはInformRequest-PDUを搭載しています。どちらも同じ構造を持っています：
PDUs ::= [7] IMPLICIT SEQUENCE {
request-id INTEGER,
error-status INTEGER, -- ignored in notifications
error-index INTEGER, -- ignored in notifications
variable-bindings VarBindList
}
-- variable binding
- 可変バインディング
VarBind ::= SEQUENCE {
name ObjectName,
CHOICE {
value ObjectSyntax,
unSpecified NULL, -- in retrieval requests
-- exceptions in responses
noSuchObject [0] IMPLICIT NULL,
noSuchInstance [1] IMPLICIT NULL,
endOfMibView [2] IMPLICIT NULL
}
}
-- variable-binding list
- 可変バインディングリスト
VarBindList ::= SEQUENCE (SIZE (0..max-bindings)) OF VarBind
The first two variable bindings in the variable binding list of an SNMPv2-Trap-PDU or InformRequest-PDU are sysUpTime.0 [RFC3418] and snmpTrapOID.0 [RFC3418], respectively. If the OBJECTS clause is present in the invocation of the corresponding NOTIFICATION-TYPE macro, then each corresponding variable, as instantiated by this notification, is copied, in order, to the variable-bindings field. If any additional variables are being included (at the option of the generating SNMP entity), then each is copied to the variable-bindings field.
SNMPV2-TRAP-PDUまたはInformRequest-PDUの変数バインディングリストの最初の2つの変数バインディングは、それぞれSysuptime.0 [RFC3418]およびSnmptrapoid.0 [RFC3418]です。対応する通知型マクロの呼び出しにオブジェクト句が存在する場合、この通知によってインスタンス化された各対応する変数が、可変バインディングフィールドに順番にコピーされます。（生成SNMPエンティティのオプションで）追加の変数が含まれている場合、それぞれが可変バインディングフィールドにコピーされます。
In the case of SNMPv1 or SNMPv2c notifications, the contextEngineID and the contextName parameters are not present in notification messages.
SNMPV1またはSNMPV2C通知の場合、ContextEngineIDおよびContextNameパラメーターは通知メッセージには存在しません。
This document assumes that notifications are in the format defined in [RFC3416]. Notifications in the SNMPv1 notification format MUST be translated as described in Section 3.1 of [RFC3584].
このドキュメントは、通知が[RFC3416]で定義されている形式であると想定しています。SNMPV1通知形式の通知は、[RFC3584]のセクション3.1で説明されているように翻訳する必要があります。
The SYSLOG protocol is defined in [RFC5424]. The message contains a global header and a number of structured data elements. The ABNF [RFC5234] representation of a SYSLOG message is defined in RFC 5424 [RFC5424]. The relevant productions for structured data elements are:
Syslogプロトコルは[RFC5424]で定義されています。このメッセージには、グローバルヘッダーと多数の構造化データ要素が含まれています。syslogメッセージのABNF [RFC5234]表現は、RFC 5424 [RFC5424]で定義されています。構造化されたデータ要素の関連するプロダクションは次のとおりです。
STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT
SD-ELEMENT = "[" SD-ID *(SP SD-PARAM) "]"
SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34
SD-ID = SD-NAME
PARAM-NAME = SD-NAME
PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and
; ']' MUST be escaped.
SD-NAME = 1*32PRINTUSASCII
; except '=', SP, ']', %d34 (")
UTF-8-STRING = *OCTET ; Any VALID UTF-8 String
; "shortest form" MUST be used
OCTET = %d00-255
SP = %d32
PRINTUSASCII = %d33-126
NILVALUE = "-"
In this section, we define how the scopedPDU portion from an SNMP notification message is used to generate a message in the SYSLOG format. The notification receiver application at the SNMP-to-SYSLOG translator is listening for incoming notifications. After a notification is received by the SNMP engine, the data portion is forwarded to the notification receiver application. The data portion contains the scopedPDU of the message, which is used by the SYSLOG originator on the SNMP-to-SYSLOG translator to generate a SYSLOG message and send it to a SYSLOG collector (or proxy). Note that every SNMP notification maps to exactly one SYSLOG message.
このセクションでは、SNMP通知メッセージからScopedPDU部分を使用してSyslog形式でメッセージを生成する方法を定義します。SNMP-to-Syslog翻訳者での通知受信者アプリケーションは、着信通知を聞いています。SNMPエンジンが通知を受け取った後、データ部分は通知受信機アプリケーションに転送されます。データ部分には、メッセージのScopedPDUが含まれています。これは、SNMP-to-Syslog翻訳者のSyslog OriginatorがSyslogメッセージを生成し、Syslogコレクター（またはプロキシ）に送信するために使用されます。すべてのSNMP通知が正確に1つのSyslogメッセージにマップすることに注意してください。
+------------+ +------------------+
|snmp | snmp | | syslog +---------+
|notification| notification | +------------+ | message |syslog |
|originator |------------->| |syslog | |-------->|collector|
+------------+ | |originator | | +---------+
+------------+ | +------------+ |
|snmp | snmp | +------------+ | syslog +---------+
|notification| notification | |snmp | | message |syslog |
|originator |------------->| |notification| |-------->|collector|
+------------+ | |receiver | | +---------+
+------------+ | +------------+ |
|snmp | snmp | |
|notification| notification | SNMP-to-SYSLOG |
|originator |------------->| translator |
+------------+ +------------------+
Figure 1: SNMP-to-SYSLOG Translator Deployment
図1：SNMPからSyslogへの翻訳者の展開
A common deployment scenario is shown in Figure 1. There can be many SNMP notification originators that send SNMP event notifications to an SNMP-to-SYSLOG translator. The SNMP-to-SYSLOG translator extracts the data portion of the notification, generates a SYSLOG message, and sends the SYSLOG message to a SYSLOG collector, which is responsible for collecting and storing all notification messages. The arrows in Figure 1 indicate message flows, not individual messages.
一般的な展開シナリオを図1に示します。SNMPイベント通知をSNMP-to-Syslog翻訳者に送信する多くのSNMP通知オリジネーターがあります。SNMPからSyslogの翻訳者は、通知のデータ部分を抽出し、Syslogメッセージを生成し、すべての通知メッセージの収集と保存を担当するSyslogコレクターにSyslogメッセージを送信します。図1の矢印は、個々のメッセージではなくメッセージフローを示しています。
The SNMP-to-SYSLOG translator is not transparent for a SYSLOG collector. The global header of the SYSLOG message generated by the SNMP-to-SYSLOG translator is filled with parameters that are specific for the system running the SNMP-to-SYSLOG translator, such as its hostname, timestamp, etc. The data portion (scopedPDU for SNMPv3 or PDU for SNMPv1/SNMPv2c) of the SNMP notification message is contained in the structured data of the SYSLOG message.
SNMPからスログへの翻訳者は、Syslogコレクターの透明ではありません。SNMPからSyslogの翻訳者によって生成されたsyslogメッセージのグローバルヘッダーには、ホスト名、タイムスタンプなどのSNMPからスログへの翻訳者を実行しているシステムに固有のパラメーターが満たされています。SNMP通知メッセージのSNMPV1/SNMPV2CのSNMPV3またはPDUは、SYSLOGメッセージの構造化されたデータに含まれています。
Implementations MUST drop invalid SNMP messages before they are passed to the SNMP-to-SYSLOG translator.
実装は、SNMPからSyslogの翻訳者に渡される前に、無効なSNMPメッセージをドロップする必要があります。
The SNMP-to-SYSLOG translator fills the HEADER field of a SYSLOG message with parameters specific to the system on which it is running. The default facility level for SYSLOG messages containing SNMP notifications SHOULD be 3, which corresponds to messages generated by system daemons. The default severity level SHOULD be 5, which corresponds to "Notice: normal but significant condition". If the SNMP-to-SYSLOG translator has a notion of the type of notification that has been received, it might choose other values for facility and severity level.
SNMPからスログへの翻訳者は、Syslogメッセージのヘッダーフィールドに、実行中のシステムに固有のパラメーターを埋めます。SNMP通知を含むsyslogメッセージのデフォルトの機能レベルは3でなければなりません。これは、システムデーモンによって生成されたメッセージに対応します。デフォルトの重大度レベルは5でなければなりません。これは「通知：正常ですが重要な条件」に対応します。SNMPからSyslogの翻訳者が受信された通知のタイプの概念を持っている場合、施設と重大度レベルの他の値を選択する可能性があります。
The VERSION, TIMESTAMP, HOSTNAME, APP-NAME, PROCID, and MSGID fields in the SYSLOG message header are filled with values that are specific to the system on which the SNMP-to-SYSLOG translator is running. The character set used in the HEADER MUST be seven-bit ASCII in an eight-bit field, as described in [RFC5424].
Syslogメッセージヘッダーのバージョン、タイムスタンプ、ホスト名、アプリ名、ProCID、およびMSGIDフィールドには、SNMP-to-Syslog翻訳者が実行されているシステムに固有の値が記載されています。ヘッダーで使用される文字セットは、[RFC5424]で説明されているように、8ビットフィールドの7ビットASCIIでなければなりません。
The STRUCTURED-DATA field of a SYSLOG message carries the ScopedPDU (or PDU) portion of an SNMP notification message. For the purpose of carrying SNMP notification data, a new SD-ID element is defined. The ABNF [RFC5234] representation of the new structured element is:
syslogメッセージの構造化されたデータフィールドには、SNMP通知メッセージのScopedPDU（またはPDU）部分が含まれます。SNMP通知データを運ぶ目的で、新しいSD-ID要素が定義されています。ABNF [RFC5234]新しい構造化要素の表現は次のとおりです。
SNMP-SD-ELEMENT = "[" SNMP-SD-ID [CTX] *VARBIND "]"
SNMP-SD-ID = %x73.6E.6D.70 ; snmp
CTX = CTXENGINE CTXNAME
CTXENGINE = SP "ctxEngine=" %d34 HEXSTRING %d34
CTXNAME = SP "ctxName=" %d34 PARAM-VALUE %d34
VARBIND = SP VARNAME [SP VARLABEL] SP VARVALUE [SP VALSTRING]
VARNAME = %d118 NUM "=" %d34 OID %d34 ; "vN="
VARLABEL = %d108 NUM "=" %d34 PARAM-VALUE %d34 ; "lN="
VARVALUE = VALOID / VALHEXSTRING / VALCOUNTER32 / VALCOUNTER64
/ VALUNSIGNED32 / VALINTEGER32 / VALIP / VALNULL
/ VALOPAQUE / VALTIMETICKS / VALSTRING
VALOID = %d111 NUM "=" %d34 OID %d34 ; "oN="
VALHEXSTRING = %d120 NUM "=" %d34 HEXSTRING %d34 ; "xN="
VALCOUNTER32 = %d99 NUM "=" %d34 UNSIGNED32 %d34 ; "cN="
VALCOUNTER64 = %d67 NUM "=" %d34 UNSIGNED64 %d34 ; "CN="
VALUNSIGNED32 = %d117 NUM "=" %d34 UNSIGNED32 %d34 ; "uN="
VALINTEGER32 = %d100 NUM "=" %d34 INTEGER32 %d34 ; "dN="
VALIP = %d105 NUM "=" %d34 IPV4ADDRESS %d34 ; "iN="
VALNULL = %d110 NUM "=" %d34 %d34 ; "nN="
VALOPAQUE = %d112 NUM "=" %d34 HEXSTRING %d34 ; "pN="
VALTIMETICKS = %d116 NUM "=" %d34 UNSIGNED32 %d34 ; "tN="
VALSTRING = %d97 NUM "=" %d34 PARAM-VALUE %d34 ; "aN="
NUM = NONZERODIGIT 0*DIGIT
num = nonzerodigit 0*桁
OID = OIDSTART *("." OIDSUBID)
OIDSTART = (("0." / "1.") [%d49-51] DIGIT) / ("2." OIDSUBID)
OIDSUBID = ZERO / (NONZERODIGIT *DIGIT)
PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and
; ']' MUST be escaped.
UTF-8-STRING = *OCTET ; Any VALID UTF-8 String
; "shortest form" MUST be used
HEXSTRING = *HEX
INTEGER32 = ["-"] NONZERODIGIT 0*DIGIT
UNSIGNED32 = NONZERODIGIT 0*DIGIT
UNSIGNED64 = NONZERODIGIT 0*DIGIT
IPV4ADDRESS = d8 "." d8 "." d8 "." d8
d8 = DIGIT ; 0-9
/ %d49-57 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %d48-52 DIGIT ; 200-249
/ "25" %d48-53 ; 250-255
HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f
NONZERODIGIT = %d49-57
ZERO = %d48
DIGIT = ZERO / NONZERODIGIT
SP = %d32
Each SNMP-SD-ELEMENT starts with the SD-ID "snmp". The first two SD-ID parameters are "ctxEngine" and "ctxName". The context MUST be present in an SNMPv3 notification and therefore "ctxEngine" and "ctxName" MUST be present in a SYSLOG message generated by an SNMP-to-SYSLOG translator from an SNMPv3 notification. The contextEngineID is encoded as an hexadecimal string while the contextName is encoded as a UTF8 string.
各SNMP-SD要素は、SD-ID「SNMP」から始まります。最初の2つのSD-IDパラメーターは、「ctxengine」と「ctxname」です。コンテキストはsnmpv3通知に存在する必要があるため、snmp3通知からSNMP-to-syslog翻訳者によって生成されたsyslogメッセージに「ctxengine」と「ctxname」が存在する必要があります。ContextEngineIDは16進文字列としてエンコードされ、ContextNameはUTF8文字列としてエンコードされます。
The remaining parameters in the "snmp" SD-ID correspond to the varbind list elements contained in the SNMP PDU. The name of a varbind is encoded as an OID in dotted notation. The rendered OID is carried in a "vN" parameter, where N identifies the position of the varbind in the varbind list of the SNMP message (the first varbind having the position 1). A MIB-aware implementation may in addition generate a parameter "lN" carrying the descriptor of the associated MIB object plus the instance identifier suffix (also called an OID label). The number N again identifies the position of the varbind in the varbind list of the SNMP message.
「SNMP」SD-IDの残りのパラメーターは、SNMP PDUに含まれるVarbindリスト要素に対応しています。Varbindの名前は、点線表記のOIDとしてエンコードされています。レンダリングされたOIDは「VN」パラメーターで運ばれ、nはSNMPメッセージのVarbindリスト（位置1を持つ最初のVarbind）のVarbindの位置を識別します。さらに、MIBを認識している実装は、関連するMIBオブジェクトの記述子とインスタンス識別子接尾辞（OIDラベルとも呼ばれる）を運ぶパラメーター「LN」を生成する場合があります。Number Nは、SNMPメッセージのVarbindリストのVarbindの位置を再び識別します。
The value of a varbind is encoded depending on its type according to the rules shown in Table 1, and type-specific parameter names are used to convey the type information. The number N again identifies the position of the varbind in the varbind list of the SNMP message. A MIB-aware implementation may in addition generate a parameter "aN" carrying an alternate textual representation of the value, which is obtained by applying DISPLAY-HINTs and translating named numbers into corresponding labels or OBJECT IDENTIFIER values to descriptors. For SNMP object types that have a DISPLAY-HINT of the form 'Ma' or 'Mt', where M is some number, a MIB-aware implementation can choose to include the "aN" parameter and to suppress the corresponding "xN" parameter. This special case saves space for textual objects. A receiver receiving an "aN" parameter without a matching value at position N can unambiguously convert the value carried in the "aN" parameter back to an OCTET STRING value.
Varbindの値は、表1に示すルールに従ってそのタイプに応じてエンコードされ、タイプ固有のパラメーター名はタイプ情報を伝えるために使用されます。Number Nは、SNMPメッセージのVarbindリストのVarbindの位置を再び識別します。さらに、MIBを認識している実装は、値の代替テキスト表現を運ぶパラメーター「an」を生成する場合があります。これは、ディスプレイヒントを適用し、対応するラベルまたはオブジェクト識別子値に記述子に翻訳することによって取得されます。「MA」または「MT」という形式の表示ヒントを持つSNMPオブジェクトタイプの場合、Mはある程度であるため、MIBに認識される実装は「A」パラメーターを含め、対応する「XN」パラメーターを抑制することを選択できます。。この特別なケースは、テキストオブジェクトのスペースを節約します。位置nで一致する値なしで「an」パラメーターを受信するレシーバーは、「an」パラメーターにある値をオクテット文字列値に明確に変換できます。
While the inclusion of additional parameters carrying OID labels or alternate value representations increases human readability, this comes at the cost of increased message size, which may cause truncation of SYSLOG messages. Therefore, implementations SHOULD provide a configuration mechanism to enable/disable the generation of parameters carrying OID labels or alternate value representations.
OIDラベルまたは代替値表現を運ぶ追加のパラメーターを含めると、人間の読みやすさが向上しますが、これはメッセージサイズが増加するため、Syslogメッセージの切り捨てを引き起こす可能性があります。したがって、実装は、OIDラベルまたは代替値表現を運ぶパラメーターの生成を有効/無効にするための構成メカニズムを提供する必要があります。
+--------------------+------------+--------------------------+
| SNMP Type | PARAM-NAME | Value Encoding |
+--------------------+------------+--------------------------+
| OBJECT IDENTIFIER | oN | dotted-decimal notation |
| OCTET STRING | xN | hexadecimal string |
| Counter32 | cN | unsigned decimal number |
| Counter64 | CN | unsigned decimal number |
| Unsigned32 | uN | unsigned decimal number |
| INTEGER, Integer32 | dN | signed decimal number |
| IpAddress | iN | dotted quad notation |
| Opaque | pN | hexadecimal (BER) string |
| TimeTicks | tN | unsigned decimal number |
| NULL | nN | zero-length string |
+--------------------+------------+--------------------------+
Table 1: Mapping of SNMP Types to SD Params
表1：SNMPタイプのSDパラメーションへのマッピング
The SYSLOG message generated by the SNMP-to-SYSLOG translator may, in addition to the SNMP-SD-ELEMENT, include other structured data elements in its structured data part. These additional structured data elements MUST comply with the specification in [RFC5424].
SNMPからスログへの翻訳者によって生成されたsyslogメッセージには、SNMP-SD要素に加えて、構造化データパーツに他の構造化データ要素を含めることができます。これらの追加の構造化データ要素は、[RFC5424]の仕様に準拠する必要があります。
In particular, the parameters in the "origin" SD-ID SHOULD identify the originator of the SNMP notification. A suitable value for the "ip" parameter MAY be taken from the snmpTrapAddress varbind if present, and a suitable value for the "enterpriseId" parameter MAY be extracted from the snmpTrapOID varbind.
特に、「Origin」SD-IDのパラメーターは、SNMP通知のオリジネーターを特定する必要があります。存在する場合は、「IP」パラメーターの適切な値をSNMPTRAPADDRESS VARBINDから取得でき、「EnterpriseID」パラメーターの適切な値をSNMPTRAPOID VARBINDから抽出できます。
The MSG part of the SYSLOG message is optional and may contain a free-form message that provides a textual description of the SNMP event notification. According to [RFC5424], the character set used in MSG SHOULD be Unicode, encoded using UTF-8 as specified in [RFC3629]. If the originator cannot encode the MSG in Unicode, it MAY use any other encoding. The originator MAY use the "language" parameters defined in [RFC5424] to convey information about the natural language used inside MSG.
SyslogメッセージのMSG部分はオプションであり、SNMPイベント通知のテキスト説明を提供するフリーフォームメッセージが含まれる場合があります。[RFC5424]によれば、MSGで使用される文字セットは、[RFC3629]で指定されているUTF-8を使用してエンコードされ、ユニコードである必要があります。OriginatorがUnicodeでMSGをエンコードできない場合、他のエンコードを使用できます。オリジネーターは、[RFC5424]で定義されている「言語」パラメーターを使用して、MSG内で使用される自然言語に関する情報を伝えることができます。
A companion document [RFC5676] defines an SNMP MIB module to represent SYSLOG messages and to send SYSLOG messages as SNMP notifications to SNMP notification receivers. This section discusses the possibilities of using both specifications in combination.
コンパニオンドキュメント[RFC5676]は、SNMP MIBモジュールを定義して、SYSLOGメッセージを表現し、SNMP通知としてSNMP通知をSNMP通知として送信します。このセクションでは、両方の仕様を組み合わせて使用する可能性について説明します。
A SYSLOG collector implementing the SYSLOG-MSG-MIB module and the mapping of SNMP notifications to SYSLOG messages may be configured to translate received SYSLOG messages containing SNMP notifications back into the original SNMP notification. In this case, the relevant tables of the SYSLOG-MSG-MIB will not be populated for SYSLOG messages carrying SNMP notifications. This configuration allows operators to build a forwarding chain where SNMP notifications are "tunneled" through SYSLOG messages. Due to size restrictions of the SYSLOG transports and the more verbose textual encoding used by SYSLOG, there is a possibility that SNMP notification content will get truncated when tunneled through SYSLOG, and thus the resulting SNMP notification may be incomplete.
syslog-msg-mibモジュールを実装するsyslogコレクターとsnmp通知のマッピングをsyslogメッセージへのマッピングは、SNMP通知を含む受信したsyslogメッセージを元のSNMP通知に変換するように構成できます。この場合、SYSLOG-MSG-MIBの関連するテーブルは、SNMP通知を運ぶSYSLOGメッセージには入力されません。この構成により、オペレーターはSNMP通知がSyslogメッセージを介して「トンネル化」される転送チェーンを構築できます。Syslogトランスポートの規模の制限と、Syslogが使用するより冗長なテキストエンコードにより、SNMP通知コンテンツがSyslogを通じてトンネリングすると切り捨てられる可能性があり、結果として生じるSNMP通知が不完全である可能性があります。
An SNMP management application supporting the SYSLOG-MSG-MIB and the mapping of SNMP notifications to SYSLOG messages may process information from the SYSLOG-MSG-MIB in order to emit a SYSLOG message representing the SYSLOG message recorded in the SYSLOG-MSG-MIB module. This configuration allows operators to build a forwarding chain where SYSLOG messages are "tunneled" through SNMP messages. A notification receiver can determine whether a syslogMsgNotification contained all structured data element parameters of a SYSLOG message. In case parameters are missing, a forwarding application MUST retrieve the missing parameters from the SYSLOG-MSG-MIB. Regular polling of the SYSLOG-MSG-MIB can be used to take care of any lost SNMP notifications.
Syslog-MSG-MIBをサポートするSNMP管理アプリケーションとSNMP通知のSyslogメッセージへのマッピングは、Syslog-MSG-MIBモジュールに記録されたSYSLOGメッセージを表すsyslogメッセージを放出するために、syslog-msg-mibから情報を処理することができます。。この構成により、オペレーターはSNMPメッセージを介してSyslogメッセージが「トンネル化」される転送チェーンを構築できます。通知レシーバーは、syslogmsgnotificationにsyslogメッセージのすべての構造化されたデータ要素パラメーターが含まれているかどうかを判断できます。パラメーターが欠落している場合、転送アプリケーションはSyslog-MSG-MIBから欠落しているパラメーターを取得する必要があります。Syslog-MSG-MIBの定期的なポーリングを使用して、失われたSNMP通知の世話をすることができます。
Here we provide an example of how an SNMP linkUp trap message is mapped into a SYSLOG message by using the mappings defined in Section 3.1 and Section 3.2.
ここでは、セクション3.1およびセクション3.2で定義されているマッピングを使用して、SNMPリンクアップトラップメッセージがsyslogメッセージにマッピングされる方法の例を示します。
The linkUp notification is defined in [RFC2863] as follows:
Linkup通知は、次のように[RFC2863]で定義されています。
linkUp NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current
DESCRIPTION
"A linkUp trap signifies that the SNMP entity, acting in an
agent role, has detected that the ifOperStatus object for
one of its communication links left the down state and
transitioned into some other state (but not into the
notPresent state). This other state is indicated by the
included value of ifOperStatus."
::= { snmpTraps 4 }
The scopedPDU portion of an SNMP linkUp trap sent using the SNMPv3 message format is shown below (the left column shows the Basic Encoding Rules (BER) encoding, while the right column indicates the corresponding ASN.1 definitions):
snmpv3メッセージ形式を使用して送信されたSNMPリンクアップトラップのscopedpdu部分を以下に示します（左列は基本エンコードルール（BER）エンコードを示し、右列は対応するASN.1定義を示します）：
30:7C SEQUENCE {
04:08:80:00:02:B8:04:61:62:63 800002b804616263
04:04:63:74:78:31 "ctx1"
A7:6A SNMPv2-Trap-PDU {
02:03:6D:08:67 INTEGER 7145575
02:01:00 INTEGER 0
02:01:00 INTEGER 0
30:5D SEQUENCE OF {
30:0F SEQUENCE {
06:08:2B:06:01:02:01:01:03:00 sysUpTime.0
43:03:01:72:8C 94860 }
30:17 SEQUENCE {
06:0A:2B:06:01:06:03:01:01:04:01:00 snmpTrapOID.0
06:09:2B:06:01:06:03:01:01:05:04 linkUp }
30:0F SEQUENCE {
06:0A:2B:06:01:02:01:02:02:01:01:03 ifIndex.3
02:01:03 3 }
30:0F SEQUENCE {
06:0A:2B:06:01:02:01:02:02:01:07:03 ifAdminStatus.3
02:01:01 up(1) }
30:0F SEQUENCE {
06:0A:2B:06:01:02:01:02:02:01:08:03 ifOperStatus.3
02:01:01 up(1) } } } }
The corresponding SYSLOG message generated by the SNMP-to-SYSLOG translator is shown below. (SYSLOG examples should be considered to be on one line. They are wrapped on multiple lines in this document for readability purposes only.)
SNMPからスログへの翻訳者によって生成された対応するsyslogメッセージを以下に示します。（Syslogの例は、1つの行にあると見なされる必要があります。読みやすさのためにのみ、このドキュメントの複数の行に包まれています。）
<29>1 2003-10-11T22:14:15.003Z mymachine.example.com snmptrapd - ID47
[snmp ctxEngine="800002b804616263" ctxName="ctx1"
v1="1.3.6.1.2.1.1.3.0" l1="sysUpTime.0" d1="94860"
v2="1.3.6.1.6.3.1.1.4.1.0" l2="snmpTrapOID.0"
o2="1.3.6.1.6.3.1.1.5.4" a2="linkUp"
v3="1.3.6.1.2.1.2.2.1.1.3" d3="3"
v4="1.3.6.1.2.1.2.2.1.7.3" d4="1" a4="up"
v5="1.3.6.1.2.1.2.2.1.8.3" d5="1" a5="up"]
The corresponding SYSLOG message has a priority value of 29, which means a facility level of 3 (system daemons) and a severity level of 5 (Notice: normal but significant condition) according to the algorithm for calculation of priority value specified in Section 6.2.1 of [RFC5424]. The rest of the fields in the header of the SYSLOG message are parameters that are specific to the system running the SNMP-to-SYSLOG translator. The SYSLOG version is 1 and the message was generated at 22:14:15.003Z on 2003-10-11T by the host "mymachine.example.com". The application on the SNMP-to-SYSLOG translator that generated the message was "snmptrapd"; there is no information about the process id, and the message on the SNMP-to-SYSLOG system is identified with the MSGID of ID47.
対応するsyslogメッセージの優先値は29です。これは、セクション6.2で指定された優先値の計算のためのアルゴリズムに従って、施設レベル3（システムデーモン）と5の重大度レベル（通知：正常である）を意味します。[RFC5424]の1。Syslogメッセージのヘッダーにある残りのフィールドは、SNMPからSyslogの翻訳者を実行しているシステムに固有のパラメーターです。syslogバージョンは1で、メッセージはホスト「mymachine.example.com」によって2003-10-11Tの22：14：15.003zに生成されました。メッセージを生成したSNMPからSyslogの翻訳者のアプリケーションは「snmptrapd」でした。プロセスIDに関する情報はなく、SNMPからSyslogシステムのメッセージはID47のMSGIDで識別されます。
The SYSLOG message contains one structured data element with an SD-ID of "snmp", which means that this is the scopedPDU portion of an SNMP event notification message. The data that is contained in the notification is associated with the ContextEngineID "123456" and ContextName "ctx1". The request-id of the SNMP notification message was "7145575". Then follows the data portion of the scopedPDU. The first two variables contained in the data portion are always the sysUpTime.0 and snmpTrapOID.0. An snmpTrapOID.0 with a value of "1.3.6.1.6.3.1.1.5.4" means that this is a linkUp trap. The parameters v3="1.3.6.1.2.1.2.2.1.1.3" d3="3" mean that the SNMP notification message is carrying the ifIndex object, which has a type INTEGER and a value of 3. The parameters v4="1.3.6.1.2.1.2.2.1.7.3" d4="1" mean that the SNMP notification message is carrying the object ifAdminStatus, which has a type INTEGER and a value of 1. The parameters v5="1.3.6.1.2.1.2.2.1.8.3" d5="1" mean that the SNMP notification message is carrying the object ifOperStatus, which has a type INTEGER and a value of "1".
Syslogメッセージには、「SNMP」のSD-IDを備えた1つの構造化データ要素が含まれています。これは、これがSNMPイベント通知メッセージのScopedPDU部分であることを意味します。通知に含まれるデータは、ContextEngineID「123456」およびコンテキスト名「CTX1」に関連付けられています。SNMP通知メッセージのリクエストIDは「7145575」でした。次に、ScopedPDUのデータ部分に従います。データ部分に含まれる最初の2つの変数は、常にsysuptime.0およびsnmptrapoid.0です。「1.3.6.1.6.3.1.1.1.5.4」の値を持つSnmptrapoid.0は、これがリンクアップトラップであることを意味します。パラメーターv3 = "1.3.6.1.2.1.2.2.2.1.1.3" d3 = "3"は、snmp通知メッセージがifindexオブジェクトを運ぶことを意味します。1.3.6.1.2.1.2.2.2.1.7.3 "d4 =" 1 "は、SNMP通知メッセージがオブジェクトを運ぶことを意味します。.2.2.1.8.3 "d5 =" 1 "は、snmp通知メッセージがオブジェクトを運ぶことを意味します。
IANA registered the SD-ID value "snmp" together with the PARAM-NAME values specified in Section 3.2 in the registry for SYSLOG Structured Data ID Values according to Section 9 in [RFC5424]. The notation <N> indicates a position number.
IANAは、[RFC5424]のセクション9に従って、SYSLOG構造化データID値のレジストリのセクション3.2で指定されたパラマネーム値とともに、SD-ID値「SNMP」を登録しました。表記<n>は、位置番号を示します。
SD-ID PARAM-NAME
snmp OPTIONAL
ctxEngine OPTIONAL
ctxName OPTIONAL
v<N> OPTIONAL
l<N> OPTIONAL
o<N> OPTIONAL
x<N> OPTIONAL
c<N> OPTIONAL
C<N> OPTIONAL
u<N> OPTIONAL
d<N> OPTIONAL
i<N> OPTIONAL
n<N> OPTIONAL
p<N> OPTIONAL
t<N> OPTIONAL
a<N> OPTIONAL
The security considerations discussed in [RFC5424] apply to this document.
[RFC5424]で説明されているセキュリティ上の考慮事項は、このドキュメントに適用されます。
The SNMP architecture supports an access control mechanism, ensuring that SNMP notifications are only sent to receivers who are authorized to receive the notification. Network operators using this mapping of SNMP notifications to SYSLOG messages should enforce a consistent policy, preventing people from accessing SNMP notifications via the SYSLOG mapping that would otherwise not be accessible.
SNMPアーキテクチャは、アクセス制御メカニズムをサポートし、SNMP通知が通知を受け取ることを許可されている受信者にのみ送信するようにします。SNMP通知のこのマッピングをSYSLOGメッセージに使用するネットワークオペレーターは、一貫したポリシーを実施し、それ以外の場合はアクセスできないSYSLOGマッピングを介してSNMP通知にアクセスできないようにする必要があります。
The editors wish to thank the following individuals for providing helpful comments on various versions of this document: Martin Bjorklund, Washam Fan, Rainer Gerhards, Tom Petch, and Dan Romascanu.
編集者は、このドキュメントのさまざまなバージョンについて有益なコメントを提供してくれた以下の個人に感謝したいと考えています：Martin Bjorklund、Washam Fan、Rainer Gerhards、Tom Petch、Dan Romascanu。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411] Harrington、D.、Presuhn、R。、およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMP）管理フレームワークを説明するためのアーキテクチャ」、STD 62、RFC 3411、2002年12月。
[RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002.
[RFC3412] Case、J.、Harrington、D.、Presuhn、R。、およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMP）のメッセージ処理とディスパッチ」、STD 62、RFC 3412、2002年12月。
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
[RFC3413] Levi、D.、Meyer、P。、およびB. Stewart、「Simple Network Management Protocol（SNMP）アプリケーション」、STD 62、RFC 3413、2002年12月。
[RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
[RFC3416] Presuhn、R。、「Simple Network Management Protocol（SNMP）のプロトコル操作のバージョン2」、STD 62、RFC 3416、2002年12月。
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
[RFC3418] Presuhn、R。、「単純なネットワーク管理プロトコル（SNMP）の管理情報ベース（MIB）」、STD 62、RFC 3418、2002年12月。
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003.
[RFC3584] Frye、R.、Levi、D.、Routhier、S。、およびB. Wijnen、「インターネット標準ネットワーク管理フレームワークのバージョン1、バージョン2、およびバージョン3の共存」、BCP 74、RFC 3584、2003年8月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 5234、2008年1月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424] Gerhards、R。、「Syslog Protocol」、RFC 5424、2009年3月。
[RFC5676] Schoenwaelder, J., Clemm, A., and A. Karmakar, "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications", RFC 5676, October 2009.
[RFC5676] Schoenwaelder、J.、Clemm、A。、およびA. Karmakar、「Syslogメッセージを単純なネットワーク管理プロトコル（SNMP）通知にマッピングするための管理オブジェクトの定義」、RFC 5676、2009年10月。
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", RFC 2578, STD 58, April 1999.
[RFC2578] McCloghrie、K.、Perkins、D。、およびJ. Schoenwaelder、「管理情報の構造バージョン2（SMIV2）」、RFC 2578、STD 58、1999年4月。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC2863] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB」、RFC 2863、2000年6月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410] Case、J.、Mundy、R.、Partain、D。、およびB. Stewart、「インターネット標準管理フレームワークの紹介と適用声明」、RFC 3410、2002年12月。
Authors' Addresses
著者のアドレス
Vladislav Marinov Jacobs University Bremen Campus Ring 1 28725 Bremen Germany
Vladislav Marinov Jacobs University Bremen Campus Ring 1 28725ブレーメンドイツ
EMail: v.marinov@jacobs-university.de
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725ブレーメンドイツ
EMail: j.schoenwaelder@jacobs-university.de