Dell OpenManage Network Manager Web Client Guide 5.0 - Page 118
Trap Forwarding Process, SNMPv1 and SNMPv3 traps become SNMPv2 Traps, Send as Proxy
View all Dell OpenManage Network Manager manuals
Add to My Manuals
Save this manual to your list of manuals |
Page 118 highlights
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. 118 Event Processing Rules | Key Portlets