SNMP Trap Receiver XML Files

SNMP Trap Receiver XML Files

Example XML file

<?xml version="1.0" encoding="ISO-8859-1" ?>
<!-- IoT Server SNMP Trap Receive configuration file -->

<configuration>

<trap_recv_rules>
<rule peername="192.168.1.67" resultobj="22" trapoid="1.3.6.1.4.1.3815.1.3.1.2.0" varoid="1.3.6.1.4.1.3815.1.3.1.1.1.1.2.1.0"/>
</trap_recv_rules>

</configuration>

<trap_recv_rules> section

Rule Number is implied by order in XML, primarily used for database lookup of a specific rule. The rule number has functional significance in some applications, but not when it comes to trap receive rules.

peername=”xxxx” – Specifies the peername that the trap is expected to be received from. If an IP address is given, then the IP address of the incoming trap message is checked. If a host name is given and the incoming trap message contains a host that could be looked up (via DNS lookup), then the host name field is checked instead of IP address.

trapoid=”x.x.x.x…” – Specifies the Trap OID that is expected. Traps and Informs always contain a Trap OID identifying the trap or inform, along with additional varbinds with a data payload. The Trap OID must match the OID given here before action will be taken.

varoid=”x.x.x.x…” – Specifies the varbind OID to look for in the message if the peername and Trap OID match.

resultobj=”n” – Specifies the local object where data retrieved from the varbind called out by varOid will be placed assuming the varOid is found, and peername and trapOid match.

hint=”n” – Provides direction on how to interpret data in the event the value type is Octet String. All ASN data types are interpreted according to their type; however, Octet String will default to being interpreted as a character string unless this hint says otherwise. The exceptions are hint=”1” to interpret 4-octet Octet Strings as 32-bit floating point per RFC 6340, and hint=”2” to interpret 8-octet Octet Strings as 64-bit floating point per RFC 6340. If the hint is non-zero but the Octet String length is not 4 or 8, then it will still be treated as a character string.

fixed=”n” – When non-zero, specifies that this fixed value should be placed in the local object when this trap is received, rather than try to derive a data value from the trap message.

timeout=”n” – Integer number of seconds for trap receive timeout. Note that this is not a session timeout, it provides for an automatic reset of the local object value. If zero, then the timeout feature is disabled.

tval=”n.nn” – Specifies the fixed value that should be placed in the local object after the timeout period has expired. The typical scenario is that either the value gleaned from the trap message itself, or the fixed value, would be placed in the local object upon receiving the trap. Then ‘timeout’ period later, the timeout value is placed in the local object, replacing the trap value. Since traps sometimes indicate only when a condition is present, and not when the condition ceases to exist, this provides a means for automatic resetting of the condition. In particular, UPS systems with RFC 1628 will automatically resend traps indicating alarm conditions, but simply stop sending them when the alarm goes away. The only way to have an alarm state indicator is to use a combination of fixed value and timeout value, and have the timeout period set to just longer than the trap repeat time.