One document matched: draft-ietf-opsawg-syslog-snmp-05.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<rfc ipr="trust200902"
docName="draft-ietf-opsawg-syslog-snmp-05.txt"
category="std">
<!--
$Id: syslog-snmp.xml 3199 2009-08-13 19:51:32Z schoenw $
-->
<front>
<title abbrev="Mapping SNMP Notifications to SYSLOG">
Mapping Simple Network Management Protocol (SNMP) Notifications
to SYSLOG Messages
</title>
<author initials="V." surname="Marinov"
fullname="Vladislav Marinov">
<organization>Jacobs University Bremen</organization>
<address>
<postal>
<street>Campus Ring 1</street>
<city>28725 Bremen</city>
<country>Germany</country>
</postal>
<email>v.marinov@jacobs-university.de</email>
</address>
</author>
<author initials="J." surname="Schoenwaelder"
fullname="Juergen Schoenwaelder">
<organization>Jacobs University Bremen</organization>
<address>
<postal>
<street>Campus Ring 1</street>
<city>28725 Bremen</city>
<country>Germany</country>
</postal>
<email>j.schoenwaelder@jacobs-university.de</email>
</address>
</author>
<date month="August" year="2009"/>
<area>Operations and Management</area>
<keyword>Network Management</keyword>
<keyword>Simple Network Management Protocol</keyword>
<keyword>SNMP</keyword>
<keyword>Notifications</keyword>
<keyword>Syslog</keyword>
<abstract>
<t>
This memo defines a mapping from Simple Network Management
Protocol (SNMP) notifications to SYSLOG messages.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
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 are 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.
</t>
<t>
The latest version of SYSLOG, specified in
<xref target="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 <xref target="RFC3416"/> into SYSLOG
messages <xref target="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.
</t>
<section title="Conventions">
<t>
A system which 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 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".
</t>
<t>
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 <xref target="RFC2119"/>.
</t>
</section>
</section>
<section title="Background">
<section anchor="SNMP Notifications" title="SNMP Notifications">
<t>
A detailed introduction to the SNMP Management Framework can
be found in <xref target="RFC3410"/>. The SNMP Management
Architecture is described in
<xref target="RFC3411"/>. Managed objects are accessed via a
virtual information store, termed the Management Information
Base or MIB <xref target="RFC3418"/>. Objects in the MIB are
defined using the mechanisms defined in the SMI
<xref target="RFC2578"/>.
</t>
<t>
An SNMP notification message is generated and transmitted by
an SNMP entity on behalf of a Notification Originator
application <xref target="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 <xref target="RFC3416"/>:
</t>
<t>
<list style="symbols">
<t>
SNMPv2-Trap-PDU, an unconfirmed notification delivery
mechanisms
</t>
<t>
InformRequest-PDU, a confirmed notification delivery
mechanism
</t>
</list>
</t>
<t>
The scopedPDU portion of an SNMPv3 trap or inform message
has the following format <xref target="RFC3412"/>:
</t>
<figure>
<artwork>
ScopedPDU ::= SEQUENCE {
contextEngineID OCTET STRING,
contextName OCTET STRING,
data ANY -- e.g., PDUs as defined in [RFC3416]
}
</artwork>
</figure>
<t>
The data member of the SEQUENCE ScopedPDU carries a
SNMPv2-Trap-PDU or an InformRequest-PDU. They both have the
same structure:
</t>
<figure>
<artwork>
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
</artwork>
</figure>
<t>
The first two variable bindings in the variable binding list
of an SNMPv2-Trap-PDU or InformRequest-PDU are sysUpTime.0
<xref target="RFC3418"/> and snmpTrapOID.0
<xref target="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.
</t>
<t>
In the case of SNMPv1 or SNMPv2c notifications, the
contextEngineID and the contextName parameters are not
present in notification messages.
</t>
<t>
This document assumes that notifications are in the format
defined in RFC 3416 <xref target="RFC3416"/>. Notifications
in the SNMPv1 notification format MUST be translated as
described in Section 3.1 of RFC 3584
<xref target="RFC3584"/>.
</t>
</section>
<section anchor="syslog" title="SYSLOG Notifications">
<t>
The SYSLOG protocol is defined in <xref target="RFC5424"/>.
The message contains a global header and a number of
structured data elements. The ABNF <xref target="RFC5234"/>
representation of a SYSLOG message is defined in RFC 5424
<xref target="RFC5424"/>. The relevant productions for
structured data elements are:
</t>
<figure>
<artwork>
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 = "-"
</artwork>
</figure>
</section>
</section>
<section title="Mapping SNMP Notifications to SYSLOG Messages">
<t>
In this section, we define how the scopedPDU portion from a
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.
</t>
<figure anchor="deployment" title="SNMP-to-SYSLOG translator deployment">
<artwork>
+------------+ +------------------+
|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 |
+------------+ +------------------+
</artwork>
</figure>
<t>
A common deployment scenario is shown in
<xref target="deployment"/>. There can be many SNMP
notification originators which send SNMP event notifications
to a SNMP-to-SYSLOG translator. The SNMP-to-SYSLOG translator
extracts the data portion of the notification, generates a
SYSLOG message, and send the SYSLOG message to a SYSLOG
collector, which is responsible for collecting and storing all
notification messages. The arrows in <xref target="deployment"/>
indicate message flows, not individual messages.
</t>
<t>
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, time stamp, 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.
</t>
<t>
Implementations MUST drop invalid SNMP messages before they
are passed to the SNMP-to-SYSLOG translator.
</t>
<section anchor="header" title="SYSLOG Header">
<t>
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.
</t>
<t>
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 <xref target="RFC5424"/>.
</t>
</section>
<section anchor="structured data" title="Structured Data">
<t>
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
<xref target="RFC5234"/> representation of the new
structured element is:
</t>
<figure>
<artwork>
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
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
</artwork>
</figure>
<t>
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 they MUST be present in a SYSLOG message generated
by an SNMP-to-SYSLOG translator from an SNMPv3
notification. The contexdEngineID is encoded as an
hexadecimal string while the contextName is encoded as a
UTF8 string.
</t>
<t>
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.
</t>
<t>
The value of a varbind is encoded depending on its type
according to the rules shown in <xref target="mapping"/> 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.
</t>
<t>
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.
</t>
<texttable anchor="mapping" title="Mapping of SNMP Types to SD Params">
<ttcol align="left">SNMP Type</ttcol>
<ttcol align="center">PARAM-NAME</ttcol>
<ttcol align="left">Value Encoding</ttcol>
<c>OBJECT IDENTIFIER</c>
<c>oN</c>
<c>dotted-decimal notation</c>
<c>OCTET STRING</c>
<c>xN</c>
<c>hexadecimal string</c>
<c>Counter32</c>
<c>cN</c>
<c>unsigned decimal number</c>
<c>Counter64</c>
<c>CN</c>
<c>unsigned decimal number</c>
<c>Unsigned32</c>
<c>uN</c>
<c>unsigned decimal number</c>
<c>INTEGER, Integer32</c>
<c>dN</c>
<c>signed decimal number</c>
<c>IpAddress</c>
<c>iN</c>
<c>dotted quad notation</c>
<c>Opaque</c>
<c>pN</c>
<c>hexadecimal (BER) string</c>
<c>TimeTicks</c>
<c>tN</c>
<c>unsigned decimal number</c>
<c>NULL</c>
<c>nN</c>
<c>zero-length string</c>
</texttable>
<t>
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 <xref target="RFC5424"/>.
</t>
<t>
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
snmpTrapOID varbind.
</t>
</section>
<section anchor="MSG" title="MSG Data">
<t>
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
<xref target="RFC5424"/>, the character set used in MSG
SHOULD be UNICODE, encoded using UTF-8 as specified in
<xref target="RFC3629"/>. If the originator can not encode
the MSG in Unicode, it MAY use any other encoding. The
originator MAY use the "language" parameters defined in
<xref target="RFC5424"/> to convey information about the
natural language used inside MSG.
</t>
</section>
</section>
<section anchor="syslog-msg-mib" title="Relationship to the SYSLOG-MSG-MIB">
<t>
A companion document defines an SNMP MIB module to represent
SYSLOG messages and to send SYSLOG messages as SNMP
notifications to SNMP notification receivers
<xref target="I-D.ietf-opsawg-syslog-msg-mib"/>. This section
discusses the possibilities of using both specifications in
combination.
</t>
<t>
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 gets truncated while tunneled through SYSLOG and thus
the resulting SNMP notification may be incomplete.
</t>
<t>
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.
</t>
</section>
<section anchor="example" title="Usage Example">
<t>
Here we provide an example how an SNMP linkUp trap message is
mapped into a SYSLOG message by using the mappings defined in
<xref target="header"/> and <xref target="structured data"/>.
</t>
<t>
The linkUp notification is defined in <xref target="RFC2863"/>
as follows:
</t>
<figure>
<artwork>
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 }
</artwork>
</figure>
<t>
The scopedPDU portion of an SNMP linkUp trap sent using the
SNMPv3 message format is shown below (left columns shows the
BER encoding while the right column indicates the
corresponding ASN.1 definitions):
</t>
<figure>
<artwork>
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) } } } }
</artwork>
</figure>
<t>
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.)
</t>
<figure>
<artwork>
<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"]
</artwork>
</figure>
<t>
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 <xref target="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.
</t>
<t>
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 event notification message. The data which 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 has 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 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 type INTEGER and a value of "1".
</t>
</section>
<section anchor="IANA Considerations" title="IANA Considerations">
<t>
IANA is requested to register the SD-ID value "snmp" together
with the PARAM-NAME values specified in
<xref target="structured data"/> in the registry for SYSLOG
structured data id values according to Section 9 in
<xref target="RFC5424"/>. The notation <N> indicates a
position number.
</t>
<figure>
<artwork>
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
</artwork>
</figure>
</section>
<section title="Security Considerations">
<t>
The security considerations discussed in
<xref target="RFC5424"/> apply to this document.
</t>
<t>
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.
</t>
</section>
<section title="Acknowledgments">
<t>
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.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title>
Key words for use in RFCs to Indicate Requirement Levels
</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
</author>
<date month="March" year="1997"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
</reference>
<reference anchor="RFC3411">
<front>
<title>
An Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks
</title>
<author initials="D." surname="Harrington" fullname="Dave Harrington">
<organization>Enterasys Networks</organization>
</author>
<author initials="R." surname="Presuhn" fullname="Randy Presuhn">
<organization>BMC Software, Inc.</organization>
</author>
<author initials="B." surname="Wijnen" fullname="Bert Wijnen">
<organization>Lucent Technologies</organization>
</author>
<date month="December" year="2002"/>
</front>
<seriesInfo name="STD" value="62"/>
<seriesInfo name="RFC" value="3411"/>
</reference>
<reference anchor="RFC5424">
<front>
<title>
The Syslog Protocol
</title>
<author initials="R." surname="Gerhards" fullname="Rainer Gerhards">
<organization>Adiscon GmbH</organization>
</author>
<date month="March" year="2009"/>
</front>
<seriesInfo name="RFC" value="5424"/>
</reference>
<reference anchor="I-D.ietf-opsawg-syslog-msg-mib">
<front>
<title>
Definitions of Managed Objects for Mapping SYSLOG Messages
to Simple Network Management Protocol (SNMP) Notifications
</title>
<author initials="J." surname="Schoenwaelder" fullname="Juergen Schoenwaelder">
<organization>Jacobs University Bremen</organization>
</author>
<author initials="A." surname="Clemm" fullname="Alexander Clemm">
<organization>Cisco Systems</organization>
</author>
<author initials="A." surname="Karmakar" fullname="Anirban Karmakar">
<organization>Cisco Systems</organization>
</author>
<date month="March" year="2009"/>
</front>
<seriesInfo name="Internet Draft" value="(work in progress)"/>
</reference>
<reference anchor="RFC3416">
<front>
<title>
Version 2 of the Protocol Operations for the Simple
Network Management Protocol (SNMP)
</title>
<author initials="R." surname="Presuhn" fullname="R. Presuhn">
<organization>BMC Software, Inc.</organization>
</author>
<date month="December" year="2002"/>
</front>
<seriesInfo name="STD" value="62"/>
<seriesInfo name="RFC" value="3416"/>
</reference>
<reference anchor="RFC3584">
<front>
<title>
Coexistence between Version 1, Version 2, and Version 3 of the
Internet-standard Network Management Framework.
</title>
<author initials="R." surname="Frye" fullname="R. Frye">
<organization>Vibrant Solutions</organization>
</author>
<author initials="D." surname="Levi" fullname="D. Levi">
<organization>Nortel Networks</organization>
</author>
<author initials="S." surname="Routhier" fullname="S. Routhier">
<organization>Wind River Systems, Inc.</organization>
</author>
<author initials="B." surname="Wijnen" fullname="B. Wijnen">
<organization>Lucent Technologies</organization>
</author>
<date month="August" year="2003"/>
</front>
<seriesInfo name="BCP" value="74"/>
<seriesInfo name="RFC" value="3584"/>
</reference>
<reference anchor="RFC5234">
<front>
<title>
Augmented BNF for Syntax Specifications: ABNF
</title>
<author initials="D." surname="Crocker" fullname="D. Crocker">
<organization>Brandenburg InternetWorking</organization>
</author>
<author initials="P." surname="Overell" fullname="P. Overell">
<organization>THUS plc.</organization>
</author>
<date month="January" year="2008"/>
</front>
<seriesInfo name="RFC" value="5234"/>
</reference>
<reference anchor="RFC3418">
<front>
<title>
Management Information Base (MIB) for the Simple Network
Management Protocol (SNMP)
</title>
<author initials="R." surname="Presuhn" fullname="R. Presuhn">
<organization/>
</author>
<date month="December" year="2002"/>
</front>
<seriesInfo name="STD" value="62"/>
<seriesInfo name="RFC" value="3418"/>
</reference>
<reference anchor="RFC3412">
<front>
<title>
Message Processing and Dispatching for the
Simple Network Management Protocol (SNMP)
</title>
<author initials="J." surname="Case" fullname="Jeff Case">
<organization>SNMP Research, Inc.</organization>
</author>
<author initials="D." surname="Harrington" fullname="Dave Harrington">
<organization>Enterasys Networks</organization>
</author>
<author initials="R." surname="Presuhn" fullname="Randy Presuhn">
<organization>BMC Software, Inc.</organization>
</author>
<author initials="B." surname="Wijnen" fullname="Bert Wijnen">
<organization>Lucent Technologies</organization>
</author>
<date month="December" year="2002"/>
</front>
<seriesInfo name="STD" value="62"/>
<seriesInfo name="RFC" value="3412"/>
</reference>
<reference anchor="RFC3413">
<front>
<title>
Simple Network Management Protocol (SNMP) Applications
</title>
<author initials="D." surname="Levi" fullname="David Levi">
<organization>Nortel Networks</organization>
</author>
<author initials="P." surname="Meyer" fullname="Paul Meyer">
<organization>Secure Computing Corporation</organization>
</author>
<author initials="B." surname="Stewart" fullname="Bob Stewart">
<organization>Retired</organization>
</author>
<date month="December" year="2002"/>
</front>
<seriesInfo name="STD" value="62"/>
<seriesInfo name="RFC" value="3413"/>
</reference>
<reference anchor="RFC3629">
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author initials="F." surname="Yergeau" fullname="F. Yergeau">
<organization/>
</author>
<date month="November" year="2003"/>
</front>
<seriesInfo name="STD" value="63"/>
<seriesInfo name="RFC" value="3629"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC2578">
<front>
<title>
Structure of Management Information Version 2 (SMIv2)
</title>
<author initials="K." surname="McCloghrie" fullname="Keith McCloghrie">
<organization>Cisco Systems, Inc</organization>
</author>
<author initials="D." surname="Perkins" fullname="David Perkins">
<organization>SNMPinfo</organization>
</author>
<author initials="J." surname="Schoenwaelder" fullname="Juergen Schoenwaelder">
<organization>TU Braunschweig</organization>
</author>
<date month="April" year="1999"/>
</front>
<seriesInfo name="RFC" value="2578"/>
<seriesInfo name="STD" value="58"/>
</reference>
<reference anchor="RFC3410">
<front>
<title>
Introduction and Applicability Statements for
Internet-Standard Management Framework
</title>
<author initials="J." surname="Case" fullname="Jeff Case">
<organization>SNMP Research, Inc.</organization>
</author>
<author initials="R." surname="Mundy" fullname="Russ Mundy">
<organization>Network Associates Laboratories</organization>
</author>
<author initials="D." surname="Partain" fullname="David Partain">
<organization>Ericsson</organization>
</author>
<author initials="B." surname="Stewart" fullname="Bob Stewart">
<organization>Retired</organization>
</author>
<date month="December" year="2002"/>
</front>
<seriesInfo name="RFC" value="3410"/>
</reference>
<reference anchor="RFC2863">
<front>
<title>The Interfaces Group MIB</title>
<author initials="K." surname="McCloghrie" fullname="K. McCloghrie">
<organization/>
</author>
<author initials="F." surname="Kastenholz" fullname="F. Kastenholz">
<organization/>
</author>
<date month="June" year="2000"/>
</front>
<seriesInfo name="RFC" value="2863"/>
</reference>
</references>
</back>
</rfc>
<!-- Local Variables: -->
<!-- compile-command: "xml2rfc syslog-snmp.xml" -->
<!-- ispell-local-dictionary: "american" -->
<!-- sgml-declaration: "/usr/lib/sgml/declaration/xml.decl" -->
<!-- sgml-omittag:nil -->
<!-- sgml-shorttag:t -->
<!-- sgml-namecase-general:t -->
<!-- sgml-minimize-attributes:nil -->
<!-- sgml-always-quote-attributes:t -->
<!-- sgml-indent-step:2 -->
<!-- sgml-indent-data:t -->
<!-- sgml-parent-document:nil -->
<!-- sgml-exposed-tags:nil -->
<!-- sgml-local-catalogs:nil -->
<!-- sgml-local-ecat-files:nil -->
<!-- End: -->
| PAFTECH AB 2003-2026 | 2026-04-24 10:24:12 |