Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages
Extracted elements (23)
MIB-aware implementations may suppress the 'xN=' hex parameter and include only the 'aN=' alternate textual representation for OCTET STRING objects with a DISPLAY-HINT of the form 'Ma' or 'Mt', saving space for textual objects while remaining unambiguously decodable by receivers.
RFC 5424 structured data elements were chosen as the mapping vehicle because they allow carrying SNMP notification information without information loss, unlike earlier SYSLOG formats. The SYSLOG MSG field carries only a free-form human-readable description while the structured data carries the machine-parseable PDU content.
The SNMP-to-SYSLOG translator is not transparent to a SYSLOG collector: the SYSLOG message header is filled with parameters specific to the translator system (hostname, timestamp, etc.), not the original SNMP notification originator.
When SNMP notifications are tunneled through SYSLOG messages and then back to SNMP (via SYSLOG-MSG-MIB), truncation may occur due to SYSLOG transport size restrictions and the more verbose textual encoding, resulting in incomplete reconstructed SNMP notifications.
Additional structured data elements beyond SNMP-SD-ELEMENT in the SYSLOG message MUST comply with the specification in RFC 5424.
Implementations MUST drop invalid SNMP messages before they are passed to the SNMP-to-SYSLOG translator.
Implementations SHOULD provide a configuration mechanism to enable/disable generation of OID label parameters ('lN') and alternate value representation parameters ('aN'), since including them increases message size and may cause SYSLOG message truncation.
SNMPv1 notifications MUST be translated to the SNMPv2 notification format as described in Section 3.1 of RFC 3584 before applying the SNMP-to-SYSLOG mapping.
The character set used in the SYSLOG message HEADER MUST be seven-bit ASCII in an eight-bit field, as described in RFC 5424.
The 'ctxEngine' and 'ctxName' parameters MUST be present in a SYSLOG message generated from an SNMPv3 notification, since the context is always present in SNMPv3 notifications.
The default facility level for SYSLOG messages containing SNMP notifications SHOULD be 3 (system daemons) and the default severity level SHOULD be 5 (Notice: normal but significant condition).
The MSG part of the SYSLOG message SHOULD use Unicode encoded as UTF-8 (RFC 3629); if the originator cannot encode in Unicode it MAY use any other encoding.
The 'origin' SD-ID parameters SHOULD identify the originator of the SNMP notification; the 'ip' parameter MAY be taken from the snmpTrapAddress varbind and 'enterpriseId' MAY be extracted from the snmpTrapOID varbind.
When a syslogMsgNotification is missing structured data element parameters, a forwarding application MUST retrieve the missing parameters from the SYSLOG-MSG-MIB.
The SNMP-SD-ELEMENT is a new SYSLOG structured data element with SD-ID 'snmp' that carries the scopedPDU (or PDU) portion of an SNMP notification. It begins with optional 'ctxEngine' and 'ctxName' parameters followed by varbind parameters.
The SNMP-to-SYSLOG translator receives SNMP notifications and generates SYSLOG messages, containing an SNMP notification receiver application and a SYSLOG originator. Every SNMP notification maps to exactly one SYSLOG message.
The SNMPv2-Trap-PDU and InformRequest-PDU share the same structure: request-id, error-status (ignored), error-index (ignored), and a VarBindList. The first two varbinds are always sysUpTime.0 and snmpTrapOID.0.
The SNMPv3 scopedPDU carries contextEngineID (OCTET STRING), contextName (OCTET STRING), and data (SNMPv2-Trap-PDU or InformRequest-PDU). SNMPv1/v2c notifications lack contextEngineID and contextName.
IANA registered the SD-ID value 'snmp' and its associated PARAM-NAME values (ctxEngine, ctxName, v<N>, l<N>, o<N>, x<N>, c<N>, C<N>, u<N>, d<N>, i<N>, n<N>, p<N>, t<N>, a<N>) in the SYSLOG Structured Data ID Values registry per RFC 5424 Section 9.
Network operators using this SNMP-to-SYSLOG mapping must enforce consistent access control policies to prevent unauthorized parties from accessing SNMP notification content via the SYSLOG path that they would not be permitted to receive directly via SNMP's access control mechanism.
SNMP type-to-SD-parameter mapping: OBJECT IDENTIFIER uses 'oN=' with dotted-decimal notation; OCTET STRING uses 'xN=' with hexadecimal; Counter32 uses 'cN='; Counter64 uses 'CN='; Unsigned32 uses 'uN='; INTEGER/Integer32 uses 'dN='; IpAddress uses 'iN=' with dotted-quad; Opaque uses 'pN=' with hex BER; TimeTicks uses 'tN='; NULL uses 'nN=' with empty string.
The contextEngineID is encoded as a hexadecimal string in the 'ctxEngine' SD parameter, while contextName is encoded as a UTF-8 string in the 'ctxName' SD parameter within the 'snmp' SD-ID.
The SNMP-SD-ELEMENT ABNF defines varbind encoding: varbind names use 'vN=' (OID in dotted notation), optional labels use 'lN=', and values use type-specific prefixes (oN=OID, xN=hex OCTET STRING, cN=Counter32, CN=Counter64, uN=Unsigned32, dN=INTEGER, iN=IpAddress, pN=Opaque, tN=TimeTicks, nN=NULL). N is the 1-based position in the varbind list.