Jump to: navigation, search


SNMP Traps and How it Works

SNMP traps are notifications or messages sent by a networked device to a management system like ServersCheck's Monitoring Software. The messages are sent over the UDP protocol (typically on port 162). The SNMP trap includes the IP address of the sender, the Generic ID, Specific ID, OID and corresponding value. For example a printer capable of sending SNMP traps could send out a trap to inform you that it is out of paper. The content of the trap can be of any kind and is not always an alert. Depending on what information it contains and what the importance of the information is to you, it can become an alert for you. This is done by filtering the content of a SNMP trap in the rule you create.

The SNMPTRAP is a different key of check compared to all other checks that you can create in the ServersCheck Monitoring Software. Most checks are polling based: this means that the software will try to execute the check at every specified interval.

SNMPTRAP is our first check part of our real time alerts. For PREMIUM and Monitoring Appliance users the SNMPTRAP functionality is included in the license; all other users need to purchase the SNMPTRAP add-on.

SNMP traps are sent whenever the remote device wants to send a notification that it is configured to do. This means that ServersCheck runs a daemon (UDP listener) on port 162 to listen for incoming SNMP trap messages. Once the message is received, the ServersCheck Monitoring Software will check the different SNMPTRAP rules you defined to see if the content of the trap matches one of the conditions you defined. By creating multiple SNMPTRAP rules, you can be alerted in different ways depending on who sends the trap and the content of the trap.

When a trap matching a rule is received, then the rule is set to DOWN until the trap is reset (meaning that it has been dealt with). SNMPTRAPS do not count towards SLA stats shown in the software. SNMPTRAPS does not output any graphs.


In order to use the SNMPTRAP feature you will need to have ServersCheck Monitoring Software release 7.1.0 or higher installed. The SNMPTRAP feature is included in Premium Editions of the software and is an optional add-on for all other users of the ServersCheck Monitoring Software.

By default SNMP Traps are received on port 162 over the UDP protocol. You need to make sure that the port is open on the host computer and that no other software is using that port. If you want, then the port can be set to another value (see below for instructions).

With some Windows configurations, a Windows Trap Receiver is installed and will prevent ServersCheck from using port 162. Also local firewalls on the host may block inbound UDP packets.

Alert escalation is not supported for the SNMPTRAP check type.

How to Monitor SNMP Traps

In this part we assume that you either are a trial, PREMIUM edition user of that you have the add-on.

First create a new rule like explained step by step in following help file article: Define Rules

In Step 3 you will see a message stating that the retries and interval are not required. As explained in the previous section, this is due to the fact that the SNMP trap is a real time alert.



Allowed IP range: the allowed IP range defines what IP addresses are to be considered for this rule. IP range is wildcard based. For example if you would like to have it apply to all IP's in the subnet then define 10.10.*.*

Community string: SNMP uses community string as a kind of password to send data. To further secure SNMP traps, you can for example define a different community string. Make sure to change it in the agent sending the traps too. Default value for community strings is public

Generic ID: SNMPv1 based traps always contain a Generic ID value. These values are:

A coldStart(0) trap signifies that the sending protocol entity is reinitializing itself such that the agent's configuration or the protocol entity implementation may be altered.

A warmStart(1) trap signifies that the sending protocol entity is reinitializing itself such that neither the agent configuration nor the protocol entity implementation is altered.

A linkDown(2) trap signifies that the sending protocol entity recognizes a failure in one of the communication links represented in the agent's configuration.

A linkUp(3) trap signifies that the sending protocol entity recognizes that one of the communication links represented in the agent's configuration has come up.

An authenticationFailure(4) trap signifies that the sending protocol entity is the addressee of a protocol message that is not properly authenticated. While implementations of the SNMP must be capable of generating this trap, they must also be capable of suppressing the emission of such traps via an implementation-specific mechanism. An egpNeighborLoss(5) trap signifies that an EGP neighbor for whom the sending protocol entity was an EGP peer has been marked down and the peer relationship no longer obtains. The Trap-PDU of type egpNeighborLoss contains as the first element of its variable-bindings, the name and value of the egpNeighAddr instance for the affected neighbor. A enterpriseSpecific(6) trap signifies that the sending protocol entity recognizes that some enterprise-specific event has occurred. The specific-trap field identifies the particular trap which occurred.

To accept any type of Generic ID, select All in the drop down box.

OID: The OID identifies which element of the agent generated the SNMP Trap. An OID can be found using the ServersCheck MIB Browser (Freeware) or similar. Wildcards can be used in the OID to include a specific tree of OID's. For example:*

OID type: for value matching (see below), ServersCheck only supports 2 type of values stored in an OID: text and numeric

OID value: The above options enable you to filter only specific traps for the rule you are creating. This can be filtered even more by either performing a text matching test or a numeric comparison.

When performing a text match, the text in the box next to the drop down field can contain the whole value or just a part. For example if you had a trap from a device with OID and string value "Very High Temperature", then you could set as a matching value High. In that way you are notified for all traps matching above conditions and when they contain the word High (case sensitive!)

When trap matches above conditions then set rule status to: depending on the importance of the trap received based on your defined filters, you set a different severity: WARNING or DOWN This will be the state of the rule as shown in the GUI.

Note: the SNMPTRAP check does not contain a TEST SETTINGS button as traps are real-time events and are not polling based.

Resetting Traps

When a trap is received, it is shown with either a DOWN or a WARNING status (depending what alert level was chosen in the configuration). Unlike for other rule types, the trap shows a RESET button. This reset will put the rule back in OK status until the next trap is received.

Click on the RESET button to open the new window.



The status of the rule will be update in the next refresh.

In future releases an auto-expire feature will be added.

Modifying the Trap Listening Port

By default SNMP traps are received on port 162. However for increased security or network configuration needs, you can also define a different port for the trap listener.

Download the snmptrap.port file and install it in your main ServersCheck directory. Open it with Notepad or any text editor and change the port number to the port you want to use.