Basics Of The SNMP Trap Message Type For Asynchronous Remote Monitoring

SNMP Trap Basics.

SNMP Trap is one of the 5 basic message types used in SNMP protocol, although more types have been added since version 1 of SNMP. An SNMP Trap is unique because it is the only message that can be sent from an agent without a get request. All other core SNMP message types are either asked for by the SNMP manager or issued in response to an SNMP manager's message. This is what makes a trap so important and the most common SNMP message in most networks. A trap is an SNMP agent's way of notifying the manager that "something is wrong".

SNMP traps are most commonly issued by one of two device types. Newer devices are able to send traps on their own to alert an SNMP trap manager when they experience a problem. For older devices that do not support SNMP, an SNMP RTU may be used to collect alarms from multiple legacy devices, convert them to SNMP traps, and transmit them (most commonly over LAN) back to your SNMP manager.

Unlike other protocols, an SNMP trap provides no proof that the message is received by the SNMP manager. Newer versions of SNMP include a new type of message called an "inform" message. An SNMP inform message is confirmed by the SNMP manager. If SNMP agent does not see confirmation from the SNMP manager that its SNMP inform message has been received, it will resend the inform message.

Each SNMP trap carries an identifier (called an OID) that determines its placement within the logical "tree" of all SNMP traps.

Ways to Transmit SNMP Traps

There are two main ways to transmit useful information using SNMP traps. One is to use what are known as "granular traps". Granular traps each have a unique OID so that you can tell them apart from one another. The SNMP manager getting the SNMP traps from the device will look up the OID in a translation file called a management information base or MIB. Because granular traps use unique numbers to support this lookup method, no actual alarm data needs to be contained within the SNMP trap. This reduces bandwidth consumed by SNMP traps, because they are not sending redundant information through the network.

When granular traps are not used, SNMP traps may be configured to contain alarm data as payloads. In this case, it's very common for all SNMP traps from the device to use a single OID. To understand these types of traps, an SNMP manager needs to analyze the data in each trap. Data is stored within an SNMP trap in a simple key-value pair configuration. Each pair is known as a "variable binding". As an example, a single SNMP trap might contain variable bindings for "site name", "severity", and "alarm description".

Granular traps are preferred for network monitoring scenarios because it reduces the load on your network. The bandwidth saved could otherwise be used for revenue-generating activities. Still, it's important to purchase a versatile SNMP manager that is capable of handling both types of SNMP traps. Even if all of your alarm remotes (RTU's) send granular traps only, it's highly likely that at least one of your other devices that is SNMP-native will use variable bindings. Imagine the headache from realizing your SMP manager will not be capable of collecting SNMP traps from 100% of your networked devices.

The NetGuardian 832A

To make it easier to understand how SNMP traps work, it's useful to look at an example. One SNMP RTU commonly used in networks around the world is the NetGuardian 832A. Helpful software and good build quality are reasons it has been used at many telecommunications, utility, and transit companies.

Dual T/Mon masters and NetGuardian remotes provide regional monitoring ability and forward alarms via SNMP traps to an SNMP manager of managers (MOM), as shown by the red box.

This RTU sends SNMP traps based on many inputs. Typically, the 832A will send traps to your manager when one of its 32 discrete alarm inputs is triggered by a contact closure output from one of your devices. This could indicate anything from a generator failure, to a door open, to a motion sensor.

This 832A can also send SNMP traps based on the current status of its eight analog current or voltage inputs. Since analog inputs are never completely on or off, but rather a value in a range, the firmware and user configuration are used to decide when to send traps. On each of the eight analog inputs of a NetGuardian 832A, you are able to define four thresholds that will trigger the sending of an trap when they are crossed. One very common application for using these thresholds involves the monitoring of temperature at your remote site. Since you have four thresholds available, you'd need to determine what temperature values constituted "way too low", "a little too low", "a little too high", and "way too high". Then, whenever the NetGuardian's analog input detect that temperature has crossed one of these thresholds, you will receive an SNMP trap with the current temperature.

The NetGuardian 832A will also send SNMP traps to you to inform you about its own internal alarms. Although there are over a dozen such alarms, one of the most common is a LAN failure. Right now, you're probably wondering, "How can I receive an SNMP trap from the NetGuardian if its LAN connection has failed?" Unlike similar alarm remotes, this NetGuardian has twin independent LAN connections. If one fails, you can receive alarms on the other to alert you that you're "running on the spare." These and similar system alerts in the form of SNMP traps help protect you against network outages, in much the same way that your car may activate a "maintenance required" or "service engine soon" light.

If you done much research on SNMP, you have certainly come across the concept that there are multiple versions that have been released. The major SNMP releases to date include v1, v2c, and v3. SNMPv1 was the initial implementation. V2c was an evolutionary change that incorporated a handful of important new features and fixes, especially new message types (like the "inform" discussed above). SNMPv3 was released in response to the needs of security-conscious organizations to encrypt their SNMP management traffic. V3 actually includes two different methods to virtually eliminate the chance of anyone "spying" on your SNMP traps.