Trap Forwarding Process

SNMPv1 and SNMPv3 traps become SNMPv2 Traps

SNMPv1 traps are converted according to RFC 1908. SNMPv3 traps are already in SNMPv2 format and the application simply does not use SNMPv3 security when sending these northbound. The following is the relevant snippet from RFC 1908:

3.1.2. SNMPv1 -> SNMPv2

When converting responses received from a SNMPv1 entity acting in an agent role into responses sent to a SNMPv2 entity acting in a manager role:

(1) ...

(2) If a Trap-PDU is received, then it is mapped into a SNMPv2-Trap-PDU. This is done by prepending onto the variable-bindings field two new bindings: sysUpTime.0 [6], which takes its value from the timestamp field of the Trap-PDU; and, snmpTrapOID.0 [6], which is calculated as follows: if the value of generic-trap field is enterpriseSpecific, then the value used is the concatenation of the enterprise field from the Trap-PDU with two additional sub- identifiers, ‘0', and the value of the specific-trap field; otherwise, the value of the corresponding trap defined in [6] is used. (For example, if the value of the generic-trap field is coldStart, then the application uses the coldStart trap [6]) Then, one new binding is appended onto the variable-bindings field: snmpTrapEnterprise.0 [6], which takes its value from the enterprise field of the Trap-PDU. The destinations for the SNMPv2-Trap-PDU are determined in an implementation-dependent fashion by the proxy agent.

Despite this description, many vendors defined a trap for SNMPv2 and then had to support sending as SNMPv1 protocol. The assembly of v2 OID from v1 enterprise and specific is supposed to include an extra ‘0'; enterpriseOID.0.specific. However, if a v2 trap is defined that has no '0' in it, so it cannot be sent as v1 and converted back following the specifications

Send as Proxy

This application can forward a trap as though it came from device (sourceIP spoofing) or act as an agent proxy according to the SNMP-COMMUNITY-MIB.

If not sending as proxy, we forward trap from application server cluster as an SNMPv2 notification as though it is coming directly from the originating agent (device). This is a common and desired behavior. Some operating systems prevent packet spoofing as a security measure so this behavior is necessarily optional.

If sending as proxy, the trap is forwarded from application server using the application server IP as sourceIP. The relevant snippet from SNMP-COMMUNITY-MIB is the following:

--

-- The snmpTrapAddress and snmpTrapCommunity objects are included

-- in notifications that are forwarded by a proxy, which were

-- originally received as SNMPv1 Trap messages.

--

 

snmpTrapAddress OBJECT-TYPE

SYNTAX IpAddress

MAX-ACCESS accessible-for-notify

STATUS current

DESCRIPTION

"The value of the agent-addr field of a Trap PDU which

is forwarded by a proxy forwarder application using

an SNMP version other than SNMPv1. The value of this

object SHOULD contain the value of the agent-addr field

from the original Trap PDU as generated by an SNMPv1

agent."

-- 1.3.6.1.6.3.18.1.3 -- ::= { snmpCommunityMIBObjects 3 }

 

snmpTrapCommunity OBJECT-TYPE

SYNTAX OCTET STRING

MAX-ACCESS accessible-for-notify

STATUS current

DESCRIPTION

"The value of the community string field of an SNMPv1

message containing a Trap PDU which is forwarded by a

a proxy forwarder application using an SNMP version

other than SNMPv1. The value of this object SHOULD

contain the value of the community string field from

the original SNMPv1 message containing a Trap PDU as

generated by an SNMPv1 agent."

-- 1.3.6.1.6.3.18.1.4 -- ::= { snmpCommunityMIBObjects 4 }

 

Open Manage Network Manager always adds snmpTrapAddress to every trap forwarded as proxy, (never adding snmpTrapCommunity). It does not keep track of the community string on the traps received.