Message Template

This panel lets you view or alter MIB Text, Bindings and the Message Template for the event selected.

This contains three sections:

MIB Text -- A read-only reminder of the MIB contents for this OID.

Bindings in Event -- A read-only reminder of the MIB bindings for this event. This displays the varbind contents of the event, matching the Binding Object Name and the OID (object identifier).

Message Template -- A template for messages that accompany this event. Specifying an OID within the curly braces {} in the template acts as a tag which replaces the OID with its MIB value. For example: Interface: {1.3.6.1.2.1.2.2.1.1} left the down state.

You can also add optional messages surrounded by double brackets [[ ]]. if the event definition has the message “aindex: {1.2.3}[[, bindex: {1.2.4}]]” and {1.2.3} is defined as say “1” but {1.2.4} is not defined then this resolves to “aindex: 1". If they are both defined (say {1.2.4} is “2”) then this resolves to “aindex: 1, bindex: 2"

 If a message template exists for an existing, correlated alarm and the generated text does not match the original alarm, then Open Manage Network Manager closes the existing alarm, and generates a new one. Leaving this blank transmits the original message.

Putting an OID in curly brackets amounts to a tag replaced by the MIB text for that OID. Look for OIDs and messages in the MIB browser (as described in MIB Browser).

Fine Tuning Event Messages

When Redcell receives an SNMP trap, the trap contains variable bindings in its payload. These varbinds should match those defined in the MIB. If the trap triggers an alarm, sometimes users need additional information to provide context not received in the payload of the original trap. Redcell can retrieve that through subsequent SNMP requests to the source device.

The file bindobjectdefs.xml lets you configure the metadata so that Open Manage Network Manager knows when to retrieve additional varbinds and what varbinds to request. The following is an example of that file:

<!-- ** Notification variable binding object definitions **

 

CorrelationType:

This attribute allows for different ways of correlating notifications when the bindings are structured differently.

0 = On value, where all bindings have both an OID and a value, the value is used to correlate (this is default)

1 = On index, e.g. OID of 1.4.5.3.4389.334 where no binding object exists with this exact OID but 1.3.5.3 does exist

and is configured this way will use the remainder of the string (4389.334 in this example) to correlate

 

MineVarBindObjects

This attribute contains a list of additional variable binding objects to mine after a trap comes in. The

binding objects present in any SNMP trap is supposed to be specified in the MIB, but sometimes more binding

objects are needed to so that the resulting alarm message contains the necessary contextual information.

If more variable bindings are needed, but can only be accessed by using data from one that has already come in,

then this should be specified here where the top level OID is the one that is expected to come in the payload

of the trap and the OIDs listed within this attribute are then mined using the index of the top level binding object.

-->

 

 

<!-- mplsTunnelAdminStatus -->

<bean xsi:type="tns:NotificationObjectDefNP">

<ObjectOID>1.3.6.1.2.1.10.166.3.2.2.1.34</ObjectOID>

<CorrelationType>1</CorrelationType>

<MineVarBindObjects>

<!-- mplsTunnelName -->

<item>1.3.6.1.3.95.2.2.1.5</item>

</MineVarBindObjects>

</bean>

 

 

<!-- mplsVpnInterfaceConfIndex -->

<bean xsi:type="tns:NotificationObjectDefNP">

<ObjectOID>1.3.6.1.3.118.1.2.1.1.1</ObjectOID>

<CorrelationType>1</CorrelationType>

</bean>

 

<!-- entSensorValue -->

<bean xsi:type="tns:NotificationObjectDefNP">

<ObjectOID>1.3.6.1.4.1.9.9.91.1.1.1.1.4</ObjectOID>

<MineVarBindObjects>

<!-- entSensorType -->

<item>1.3.6.1.4.1.9.9.91.1.1.1.1.1</item>

</MineVarBindObjects>

 

</bean>