Trapd

From OpenNMS
Jump to navigation Jump to search

Trapd handles the processing of SNMP trap data.

Functionality

Trapd allows OpenNMS to receive snmp traps and turn them into events, and then into alarms and/or notifications, much as Syslogd does for syslog entries.

From an email discussion dating from 2007 (http://comments.gmane.org/gmane.network.opennms.general/20008):

Trapd supports V1 traps, V2 traps / notifications, and (I think) V3 traps / notifications. No configuration is necessary to enable any of these items. We do our best to follow the RFC (the number eludes me at this hour) laying out coexistence of V1 and V2 traps.

Trapd will accept traps with any community name (V1 / V2c), and that community name can be used in event definitions as part of a mask, though I've never seen anybody do this.

Availability

"Unknown" - Probably it's been there from the very beginning as it is a central function.

Configuration

trapd-configuration.xml

<?xml version="1.0"?>
    <trapd-configuration snmp-trap-port="162" new-suspect-on-trap="false"/>

The <configuration> element specifies global parameters that specify how Trapd will receive and process snmp traps. This element has the following attributes:

  • Port, Trapd port (udp) to listen on (Default 162)
  • New suspect on messages specifies whether Trapd will inject a newSuspect event when it receives an snmp trap originating from a host that cannot be resolved to an existing node managed by OpenNMS. This functionality is equivalent to the same option in Syslogd. New suspects will be queued for discovery by Capsd.

Technical description

The service is built around traditional UDP based snmp traps, and the service is a receiver of traps created by remote devices.

How does it work

Admiral Ackbar: SNMP Specialist

Question - What will happen as a snmp trap arrives?

Answer - The message is parsed, the sender compared to known nodes. If the sender is an unknown node and new-suspect-on-trap="true" is configured an event is sent to discover the node. Otherwise the trap is tagged to the correct node, broadcast to eventd, and from there on essentially is an openNMS event.

Question - Event how?

Answer - We convert the snmp trap to an openNMS Event, the matching event as usual is found in the etc/events directory.

I.e. for each trap received, it will get prioritized, categorized and submitted to the eventprocessor for notification or other configured actions.

More examples

  • Automating alarms and reducing amount of messages using automations -- see the related syslogd example at Syslogd_Automations
  • One can discarding certain SNMP traps that are not of interest by configuring the eventd subsystem to discard the trap using a logmsg setting of discardtraps -- see Event_Configuration_How-To

SNMPv3

Since version 1.8.13 or 1.9.90, it is possible to receive and decode V3 Traps as explained on NMS-2995.

The information stored on snmp-config.xml regarding to SNMPv3 is used for polling and data collection. The SNMPv3 credentials used to authenticate and decode V3 Traps must be specified in trapd-configuration.xml, like the following example:

<trapd-configuration snmp-trap-port="162" new-suspect-on-trap="true">
  <snmpv3-user security-name="opennms" auth-passphrase="0p3nNMSv3" auth-protocol="MD5"
      privacy-passphrase="0p3nNMSv3" privacy-protocol="DES"/>
  <snmpv3-user security-name="agalue" auth-passphrase="secret" auth-protocol="MD5"
      privacy-passphrase="super-secret" privacy-protocol="DES"/>
</trapd-configuration>

These are the users that will be used for decoding the traps, that means, they should be defined on those nodes who send V3 traps to OpenNMS.