draft-ietf-opsawg-syslog-snmp-00.txt   draft-ietf-opsawg-syslog-snmp-01.txt 
Network Working Group V. Marinov Network Working Group V. Marinov
Internet-Draft J. Schoenwaelder Internet-Draft J. Schoenwaelder
Intended status: Standards Track Jacobs University Bremen Intended status: Standards Track Jacobs University Bremen
Expires: August 14, 2009 February 10, 2009 Expires: September 10, 2009 March 9, 2009
Mapping Simple Network Management Protocol (SNMP) Notifications to Mapping Simple Network Management Protocol (SNMP) Notifications to
SYSLOG Messages SYSLOG Messages
draft-ietf-opsawg-syslog-snmp-00.txt draft-ietf-opsawg-syslog-snmp-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 14, 2009. This Internet-Draft will expire on September 10, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
This memo defines a mapping from Simple Network Management Protocol This memo defines a mapping from Simple Network Management Protocol
(SNMP) notifications to SYSLOG notifications. (SNMP) notifications to SYSLOG notifications.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. SNMP Notifications . . . . . . . . . . . . . . . . . . . . 3 2.1. SNMP Notifications . . . . . . . . . . . . . . . . . . . . 3
2.2. SYSLOG Notifications . . . . . . . . . . . . . . . . . . . 5 2.2. SYSLOG Notifications . . . . . . . . . . . . . . . . . . . 5
3. Mapping SNMP Notifications to SYSLOG Notifications . . . . . . 5 3. Mapping SNMP Notifications to SYSLOG Notifications . . . . . . 6
3.1. SYSLOG Header . . . . . . . . . . . . . . . . . . . . . . 7 3.1. SYSLOG Header . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Structured Data . . . . . . . . . . . . . . . . . . . . . 7 3.2. Structured Data . . . . . . . . . . . . . . . . . . . . . 7
3.3. MSG Data . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. MSG Data . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Relationship to the SYSLOG-MSG-MIB . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
SNMP and SYSLOG are two widely used protocols to communicate event SNMP and SYSLOG are two widely used protocols to communicate event
notifications. Although co-existence of several management protocols notifications. Although co-existence of several management protocols
in one operational environment is possible, certain environments in one operational environment is possible, certain environments
require that all event notifications are collected by a single system require that all event notifications are collected by a single system
daemon such as a SYSLOG collector or an SNMP notification receiver daemon such as a SYSLOG collector or an SNMP notification receiver
via a single management protocol. In such environments, it is via a single management protocol. In such environments, it is
necessary to translate event notifications between management necessary to translate event notifications between management
skipping to change at page 5, line 16 skipping to change at page 5, line 16
snmpTrapOID.0 [RFC3418] respectively. If the OBJECTS clause is snmpTrapOID.0 [RFC3418] respectively. If the OBJECTS clause is
present in the invocation of the corresponding NOTIFICATION-TYPE present in the invocation of the corresponding NOTIFICATION-TYPE
macro, then each corresponding variable, as instantiated by this macro, then each corresponding variable, as instantiated by this
notification, is copied, in order, to the variable-bindings field. notification, is copied, in order, to the variable-bindings field.
If any additional variables are being included (at the option of the If any additional variables are being included (at the option of the
generating SNMP entity), then each is copied to the variable-bindings generating SNMP entity), then each is copied to the variable-bindings
field. field.
In the case of SNMPv1 or SNMPv2c notifications, the contextEngineID In the case of SNMPv1 or SNMPv2c notifications, the contextEngineID
and the contextName parameters are not present in notification and the contextName parameters are not present in notification
messages. In general, we assume that notifications from an SNMP messages.
version preceding SNMPv3 are mapped into the notification format used
by SNMPv3 according to the coexistance rules defined in RFC 3584 This document assumes that notifications are in the format defined in
[RFC3584]. RFC 3416 [RFC3416]. Notifications in the SNMPv1 notification format
must be translated as described in Section 3.1 of RFC 3584 [RFC3584].
2.2. SYSLOG Notifications 2.2. SYSLOG Notifications
The SYSLOG protocol is defined in [I-D.ietf-syslog-protocol]. The The SYSLOG protocol is defined in [I-D.ietf-syslog-protocol]. The
message contains a global header and a number of structured data message contains a global header and a number of structured data
elements. The ABNF [RFC4234] representation of a SYSLOG message is elements. The ABNF [RFC4234] representation of a SYSLOG message is
defined in RFC XXXX [I-D.ietf-syslog-protocol]. The relevant defined in RFC XXXX [I-D.ietf-syslog-protocol]. The relevant
productions for structured data elements are: productions for structured data elements are:
STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT
skipping to change at page 6, line 15 skipping to change at page 6, line 20
translator is listening for incoming notifications. After a translator is listening for incoming notifications. After a
notification is received by the SNMP engine the data portion is notification is received by the SNMP engine the data portion is
forwarded to the notification receiver application. The data portion forwarded to the notification receiver application. The data portion
contains the scopedPDU portion of the message which is used by the contains the scopedPDU portion of the message which is used by the
SYSLOG sender on the snmp-to-syslog translator to generate a SYSLOG SYSLOG sender on the snmp-to-syslog translator to generate a SYSLOG
notification and send it to a SYSLOG receiver. A common scenario is notification and send it to a SYSLOG receiver. A common scenario is
the following: the following:
+-------------------+ snmp +------------+ +-------------------+ snmp +------------+
| |notification |snmp | | |notification |snmp |
+---------+ syslog | +-------------+ |-------------|notification| +---------+ syslog | +-------------+ |<------------|notification|
|syslog |notification| |syslog sender| | |originator | |syslog |notification| |syslog sender| | |originator |
|collector|------------| +-------------+ | +------------+ |collector|<-----------| +-------------+ | +------------+
| | | +------------+ | snmp +------------+ | | | +------------+ | snmp +------------+
| | | |snmp | |notification |snmp | | | | |snmp | |notification |snmp |
+---------+ | |notification| |-------------|notification| +---------+ | |notification| |<------------|notification|
| |receiver | | |originator | | |receiver | | |originator |
| +------------+ | +------------+ | +------------+ | +------------+
| snmp-to-syslog |snmp +------------+ | snmp-to-syslog |snmp +------------+
| translator |notification |snmp | | translator |notification |snmp |
| |-------------|notification| | |<------------|notification|
+-------------------+ |originator | +-------------------+ |originator |
+------------+
There can be many SNMP notification originators which send SNMP event There can be many SNMP notification originators which send SNMP event
notifications to a snmp-to-syslog translator. The snmp-to-syslog notifications to a snmp-to-syslog translator. The snmp-to-syslog
translator extracts the data portion of the notification, generates a translator extracts the data portion of the notification, generates a
SYSLOG message, and send the SYSLOG message to a SYSLOG collector, SYSLOG message, and send the SYSLOG message to a SYSLOG collector,
which is responsible for collecting and storing all notification which is responsible for collecting and storing all notification
messages. messages.
The snmp-to-syslog translator is not transparent for a SYSLOG The snmp-to-syslog translator is not transparent for a SYSLOG
receiver. The global header of the SYSLOG message generated by the receiver. The global header of the SYSLOG message generated by the
skipping to change at page 7, line 36 skipping to change at page 7, line 36
ScopedPDU (or PDU) portion of the SNMP notification message. For the ScopedPDU (or PDU) portion of the SNMP notification message. For the
purpose of carrying SNMP notification data, a new SD-ID element is purpose of carrying SNMP notification data, a new SD-ID element is
defined. The ABNF [RFC4234] representation of the new structured defined. The ABNF [RFC4234] representation of the new structured
element is: element is:
SNMP-SD-ELEMENT = "[" SNMP-SD-ID [CTX] *VARBIND "]" SNMP-SD-ELEMENT = "[" SNMP-SD-ID [CTX] *VARBIND "]"
SNMP-SD-ID = %x73.6E.6D.70 ; snmp SNMP-SD-ID = %x73.6E.6D.70 ; snmp
CTX = CTXENGINE CTXNAME CTX = CTXENGINE CTXNAME
CTXENGINE = SP "ctxEngine=" %d34 HEXSTRING %d34 CTXENGINE = SP "ctxEngine=" %d34 HEXSTRING %d34
CTXNAME = SP "ctxName=" %d34 PARAM-VALUE %d34 CTXNAME = SP "ctxName=" %d34 PARAM-VALUE %d34
VARBIND = SP VARNAME SP [VARLABEL SP] VARVALUE VARBIND = SP VARNAME [SP VARLABEL] SP VARVALUE [SP VALSTRING]
VARNAME = "v=" %d34 OID %d34 VARNAME = %d118 NUM "=" %d34 OID %d34 ; "vN="
VARLABEL = "l=" %d34 PARAM-VALUE %d34 VARLABEL = %d108 NUM "=" %d34 PARAM-VALUE %d34 ; "lN="
VARVALUE = VALOID / VALSTRING / VALCOUNTER32 / VALCOUNTER64 VARVALUE = VALOID / VALHEXSTRING / VALCOUNTER32 / VALCOUNTER64
/ VALUNSIGNED32 / VALINTEGER32 / VALIP / VALNULL / VALUNSIGNED32 / VALINTEGER32 / VALIP / VALNULL
/ VALOPAQUE / VALTIMETICKS / VALOPAQUE / VALTIMETICKS / VALUTF8STRING
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 NULL %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
VALOID = "o=" %d34 OID %d34
VALSTRING = "x=" %d34 HEXSTRING %d34
VALCOUNTER32 = "c=" %d34 UNSIGNED32 %d34
VALCOUNTER64 = "C=" %d34 UNSIGNED64 %d34
VALUNSIGNED32 = "u=" %d34 UNSIGNED32 %d34
VALINTEGER32 = "d=" %d34 INTEGER32 %d34
VALIP = "i=" %d34 IPV4ADDRESS %d34
VALNULL = "n=" %d34 NULL %d34
VALOPAQUE = "p=" %d34 HEXSTRING %d34
VALTIMETICKS = "t=" %d34 UNSIGNED32 %d34
OID = OIDSTART *("." OIDSUBID) OID = OIDSTART *("." OIDSUBID)
OIDSTART = (("0." / "1.")[%d49-51] DIGIT) / ("2." OIDSUBID) OIDSTART = (("0." / "1.")[%d49-51] DIGIT) / ("2." OIDSUBID)
OIDSUBID = ZERO / (NONZERODIGIT *DIGIT) OIDSUBID = ZERO / (NONZERODIGIT *DIGIT)
PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and
; ']' MUST be escaped. ; ']' MUST be escaped.
UTF-8-STRING = *OCTET ; Any VALID UTF-8 String UTF-8-STRING = *OCTET ; Any VALID UTF-8 String
; "shortest form" MUST be used ; "shortest form" MUST be used
HEXSTRING = *HEX HEXSTRING = *HEX
INTEGER32 = ["-"] NONZERODIGIT 0*DIGIT INTEGER32 = ["-"] NONZERODIGIT 0*DIGIT
skipping to change at page 8, line 31 skipping to change at page 8, line 35
/ "1" 2DIGIT ; 100-199 / "1" 2DIGIT ; 100-199
/ "2" %d48-52 DIGIT ; 200-249 / "2" %d48-52 DIGIT ; 200-249
/ "25" %d48-53 ; 250-255 / "25" %d48-53 ; 250-255
HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f
NONZERODIGIT = %d49-57 NONZERODIGIT = %d49-57
ZERO = %d48 ZERO = %d48
DIGIT = ZERO / NONZERODIGIT DIGIT = ZERO / NONZERODIGIT
SP = %d32 SP = %d32
Each SNMP-SD-ELEMENT starts with a SD-ID="snmp". The first two Each SNMP-SD-ELEMENT starts with the SD-ID "snmp". The first two
PARAM-NAME elements are "ctxEngine" and "ctxName". They must be SD-ID parameters are "ctxEngine" and "ctxName". They must be present
present in an SNMPv3 notification and therefore they must be present in an SNMPv3 notification and therefore they must be present in a
in a SYSLOG message generated by an snmp-to-syslog translator. The SYSLOG message generated by an snmp-to-syslog translator from an
contexdEngineID is encoded as as hexadecimal string and the SNMPv3 notification. The contexdEngineID is encoded as as
contextName is encoded as a hexadecimal string. hexadecimal string while the contextName is encoded as a UTF8 string.
The remaining parameters correspond to the varbind list elements. The remaining parameters in the "snmp" SD-ID correspond to the
The name of a varbind is encoded as an OID in dotted notation and the varbind list elements contained in the SNMP PDU. The name of a
values are encoded according to the rules shown in Table 1: 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.
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 a 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 allows to save space for textual
objects. A receiver receiving a "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.
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 message. Therefore, implementations should
provide a configuration mechanism to enable/disable the generation of
parameters carrying OID labels or alternate value representations.
+--------------------+------------+--------------------------+ +--------------------+------------+--------------------------+
| SNMP Type | PARAM-NAME | Value Encoding | | SNMP Type | PARAM-NAME | Value Encoding |
+--------------------+------------+--------------------------+ +--------------------+------------+--------------------------+
| OBJECT IDENTIFIER | o | dotted-decimal notation | | OBJECT IDENTIFIER | oN | dotted-decimal notation |
| OCTET STRING | x | hexadecimal string | | OCTET STRING | xN | hexadecimal string |
| Counter32 | c | unsigned decimal number | | Counter32 | cN | unsigned decimal number |
| Counter64 | C | unsigned decimal number | | Counter64 | CN | unsigned decimal number |
| Unsigned32 | u | unsigned decimal number | | Unsigned32 | uN | unsigned decimal number |
| INTEGER, Integer32 | d | signed decimal number | | INTEGER, Integer32 | dN | signed decimal number |
| IpAddress | i | dotted quad notation | | IpAddress | iN | dotted quad notation |
| Opaque | p | hexadecimal (BER) string | | Opaque | pN | hexadecimal (BER) string |
| TimeTicks | t | unsigned decimal number | | TimeTicks | tN | unsigned decimal number |
| NULL | n | zero-length string | | NULL | nN | zero-length string |
+--------------------+------------+--------------------------+ +--------------------+------------+--------------------------+
Table 1: Mapping of SNMP Types to SD Params Table 1: Mapping of SNMP Types to SD Params
The SYSLOG message generated by the snmp-to-syslog translator may The SYSLOG message generated by the snmp-to-syslog translator may
include other structured data elements in its structured part in include other structured data elements in its structured part in
addition to the SNMP-SD-ELEMENT. These structured data elements are addition to the SNMP-SD-ELEMENT. These structured data elements are
included in the SYSLOG message by the SYSLOG sender at the snmp-to- included in the SYSLOG message by the SYSLOG sender at the snmp-to-
syslog translator and must be compliant to the specification in syslog translator and must be compliant to the specification in
[I-D.ietf-syslog-protocol]. [I-D.ietf-syslog-protocol].
skipping to change at page 9, line 43 skipping to change at page 10, line 17
extracted from snmpTrapOID varbind. extracted from snmpTrapOID varbind.
3.3. MSG Data 3.3. MSG Data
The MSG part of the SYSLOG message is optional and may contain a The MSG part of the SYSLOG message is optional and may contain a
free-form message that provides a textual description of the SNMP free-form message that provides a textual description of the SNMP
event notification. The character set used in MSG SHOULD be UNICODE, event notification. The character set used in MSG SHOULD be UNICODE,
encoded using UTF-8 as specified in [RFC3629]. If the sender can not encoded using UTF-8 as specified in [RFC3629]. If the sender can not
encode the MSG in Unicode, it MAY use any other encoding. encode the MSG in Unicode, it MAY use any other encoding.
4. Usage Example 4. Relationship to the SYSLOG-MSG-MIB
A companion document defines an SNMP MIB module to represent SYSLOG
messages and to send SYSLOG messages as SNMP notifications to SNMP
notification receivers [I-D.ietf-opsawg-syslog-msg-mib]. This
section discusses the possibilities of using both specifications in
combination to create notification "tunnels".
[TODO: Add text explaining the combination of the two specifications,
similar to the text in the companion document. Discuss the
implication of message sizes.]
5. Usage Example
Here we provide an example how an SNMP linkUp trap message is mapped Here we provide an example how an SNMP linkUp trap message is mapped
into a SYSLOG message by using the mappings defined in Section 3.1 into a SYSLOG message by using the mappings defined in Section 3.1
and Section 3.2. and Section 3.2.
The linkUp notification is defined in [RFC2863]: The linkUp notification is defined in [RFC2863]:
linkUp NOTIFICATION-TYPE linkUp NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current STATUS current
skipping to change at page 11, line 4 skipping to change at page 11, line 36
06:0A:2B:06:01:02:01:02:02:01:07:03 ifAdminStatus.3 06:0A:2B:06:01:02:01:02:02:01:07:03 ifAdminStatus.3
02:01:01 up(1) } 02:01:01 up(1) }
30:0F SEQUENCE { 30:0F SEQUENCE {
06:0A:2B:06:01:02:01:02:02:01:08:03 ifOperStatus.3 06:0A:2B:06:01:02:01:02:02:01:08:03 ifOperStatus.3
02:01:01 up(1) } } } } 02:01:01 up(1) } } } }
The corresponding SYSLOG message generated by the snmp-to-syslog The corresponding SYSLOG message generated by the snmp-to-syslog
translator is shown below. (SYSLOG examples should be considered to translator is shown below. (SYSLOG examples should be considered to
be on one line. They are wrapped on multiple lines in this document be on one line. They are wrapped on multiple lines in this document
for readability purposes only.) for readability purposes only.)
<29>1 2003-10-11T22:14:15.003Z mymachine.example.com snmptrapd - ID47 <29>1 2003-10-11T22:14:15.003Z mymachine.example.com snmptrapd - ID47
[snmp ctxEngine="800002b804616263" ctxName="ctx1" [snmp ctxEngine="800002b804616263" ctxName="ctx1"
v="1.3.6.1.2.1.1.3.0" l="sysUpTime.0" d="94860" v1="1.3.6.1.2.1.1.3.0" l1="sysUpTime.0" d1="94860"
v="1.3.6.1.6.3.1.1.4.1.0" l="snmpTrapOID.0" o="1.3.6.1.6.3.1.1.5.4" v2="1.3.6.1.6.3.1.1.4.1.0" l2="snmpTrapOID.0"
v="1.3.6.1.2.1.2.2.1.1.3" d="3" o2="1.3.6.1.6.3.1.1.5.4" a2="linkUp"
v="1.3.6.1.2.1.2.2.1.7.3" d="1" v3="1.3.6.1.2.1.2.2.1.1.3" d3="3"
v="1.3.6.1.2.1.2.2.1.8.3" d="1"] 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 The corresponding SYSLOG message has a priority value of 29 which
means a facility level of 3 (system daemons) and a severity level of means a facility level of 3 (system daemons) and a severity level of
5 (Notice: Normal but significant condition) according to the 5 (Notice: Normal but significant condition) according to the
algorithm for calculation of priority value specified in section algorithm for calculation of priority value specified in Section
6.2.1 of [I-D.ietf-syslog-protocol]. The rest of the fields in the 6.2.1 of [I-D.ietf-syslog-protocol]. The rest of the fields in the
header of the SYSLOG message are parameters that are specific to the header of the SYSLOG message are parameters that are specific to the
system running the snmp-to-syslog translator. The SYSLOG version is 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 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- the host "mymachine.example.com". The application on the snmp-to-
syslog translator that generated the message was "snmptrapd", there syslog translator that generated the message was "snmptrapd", there
is no information about the process id and the message on the snmp- is no information about the process id and the message on the snmp-
to-syslog system is identified with the MSGID of ID47. to-syslog system is identified with the MSGID of ID47.
The SYSLOG message contains one structured data element with a SD-ID The SYSLOG message contains one structured data element with a SD-ID
of "snmp" which means that this is the scopedPDU portion of an SNMP of "snmp" which means that this is the scopedPDU portion of an SNMP
event notification message. The data which is contained in the event notification message. The data which is contained in the
notification is associated with the ContextEngineID "123456" and notification is associated with the ContextEngineID "123456" and
ContextName "ctx1". The request-id of the SNMP notification message ContextName "ctx1". The request-id of the SNMP notification message
was "7145575". Then follows the data portion of the scopedPDU. The was "7145575". Then follows the data portion of the scopedPDU. The
first two variables contained in the data portion are always the first two variables contained in the data portion are always the
sysUpTime.0 and snmpTrapOID.0. An snmpTrapOID.0 with a value of 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 "1.3.6.1.6.3.1.1.5.4" means that this is a linkUp trap. The
parameters v="1.3.6.1.2.1.2.2.1.1.3" d="3" mean that the SNMP 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 notification message is carrying the ifIndex object which has a type
INTEGER and has a value of 3. The parameters INTEGER and has a value of 3. The parameters
v="1.3.6.1.2.1.2.2.1.7.3" d="1" mean that the SNMP notification 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 type INTEGER message is carrying the object ifAdminStatus which has type INTEGER
and a value of 1. The parameters v="1.3.6.1.2.1.2.2.1.8.3" d="1" 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 mean that the SNMP notification message is carrying the object
ifOperStatus which has type INTEGER and a value of "1". ifOperStatus which has type INTEGER and a value of "1".
5. IANA Considerations 6. IANA Considerations
IANA is requested to register the SD-ID value "snmp" together with IANA is requested to register the SD-ID value "snmp" together with
the PARAM-NAME values specified in Section 3.2 in the registry for the PARAM-NAME values specified in Section 3.2 in the registry for
SYSLOG structured data id values according to section 9 in SYSLOG structured data id values according to Section 9 in
[I-D.ietf-syslog-protocol]. [I-D.ietf-syslog-protocol]. The notation <N> indicates a position
number.
SD-ID PARAM-NAME SD-ID PARAM-NAME
snmp OPTIONAL snmp OPTIONAL
ctxEngine OPTIONAL ctxEngine OPTIONAL
ctxName OPTIONAL ctxName OPTIONAL
v OPTIONAL v<N> OPTIONAL
l OPTIONAL l<N> OPTIONAL
o OPTIONAL o<N> OPTIONAL
x OPTIONAL x<N> OPTIONAL
c OPTIONAL c<N> OPTIONAL
C OPTIONAL C<N> OPTIONAL
u OPTIONAL u<N> OPTIONAL
d OPTIONAL d<N> OPTIONAL
i OPTIONAL i<N> OPTIONAL
n OPTIONAL n<N> OPTIONAL
p OPTIONAL p<N> OPTIONAL
t OPTIONAL t<N> OPTIONAL
a<N> OPTIONAL
6. Security Considerations 7. Security Considerations
The security considerations discussed in [I-D.ietf-syslog-protocol] The security considerations discussed in [I-D.ietf-syslog-protocol]
apply to this document. apply to this document.
The SNMP architecture supports an access control mechanism ensuring The SNMP architecture supports an access control mechanism ensuring
that SNMP notifications are only sent to receivers who are authorized that SNMP notifications are only sent to receivers who are authorized
to receive the notification. Users of this mapping of SNMP to receive the notification. Users of this mapping of SNMP
notifications to SYSLOG messages should enforce a consistent policy notifications to SYSLOG messages should enforce a consistent policy
preventing people from accessing SNMP notifications via the SYSLOG preventing people from accessing SNMP notifications via the SYSLOG
mapping that would otherwise not be accessible. mapping that would otherwise not be accessible.
7. Acknowledgments 8. Acknowledgments
The authors wish to thank Rainer Gerhards and all other people who The authors wish to thank Martin Bjorklund, Washam Fan, Rainer
commented on various versions of this proposal. Gerhards and all other people who commented on various versions of
this proposal.
8. References 9. References
8.1. Normative References 9.1. Normative References
[I-D.ietf-opsawg-syslog-msg-mib]
Schoenwaelder, J., Clemm, A., and A. Karmakar,
"Definitions of Managed Objects for Mapping SYSLOG
Messages to Simple Network Management Protocol (SNMP)
Notifications", Internet Draft (work in progress),
March 2009.
[I-D.ietf-syslog-protocol] [I-D.ietf-syslog-protocol]
Gerhards, R., "The syslog Protocol", Internet Draft (work Gerhards, R., "The syslog Protocol", Internet Draft (work
in progress), September 2007. in progress), September 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management Architecture for Describing Simple Network Management
skipping to change at page 13, line 35 skipping to change at page 14, line 43
RFC 3418, December 2002. RFC 3418, December 2002.
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version 3 "Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework.", of the Internet-standard Network Management Framework.",
BCP 74, RFC 3584, August 2003. BCP 74, RFC 3584, August 2003.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
8.2. Informative References 9.2. Informative References
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)", "Structure of Management Information Version 2 (SMIv2)",
RFC 2578, STD 58, April 1999. RFC 2578, STD 58, April 1999.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000. MIB", RFC 2863, June 2000.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet- "Introduction and Applicability Statements for Internet-
 End of changes. 34 change blocks. 
93 lines changed or deleted 151 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/