Users Guide

Automation and Event Processing Rules | Alarms, Events, and Automation
OMNM 6.5.3 User Guide 315
Config Changed
This action sets a flag on the device notifying that a configuration change has occurred. This also
updates the "Last Configuration Change" attribute of the managed resource that is associated with
the event that triggered the automation to execute.
Hint: You can generate the report named "Configuration Change Report" to see all configuration
changes that have occurred for each device.
Forwarding Traps
SNMPv1 and SNMPv3 traps become SNMPv2 Traps
SNMPv1 traps are converted according to the RFC 1908 specification. SNMPv3 traps are already in
the SNMPv2 format and the application simply does not use SNMPv3 security when sending these
northbound. The following is the relevant snippet from the RFC 1908 specification:
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 it as SNMPv1 protocol. The assembly of v2 OID from v1 enterprise and specific is
supposed to include an extra zero (0) as in: enterpriseOID.0.specific. However, if a v2 trap is
defined that has no '0' in it, it cannot be sent as v1 and converted back following the specifications.
Sending as Proxy
The OpenManage Network Manager (OMNM) application can forward a trap as though it came
from a device (sourceIP spoofing) or act as an agent proxy according to the SNMP-COMMUNITY-
MIB. If not sending as a proxy, the OMNM application forwards traps from an application server
cluster as an SNMPv2 notification as though it is coming directly from the originating agent
(device). This is a common and the desired behavior. Some operating systems prevent packet
spoofing as a security measure so this behavior is optional.
If sending as a proxy, the OMNM application forwards the trap from the IP address given in the
field adjacent to the Send as Proxy option when you select it. If you select the Send as Proxy option
but leave the adjacent IP address blank, the OMNM application forwards the trap from the
receiving mediation server as sourceIP.