Request Info
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). What makes an SNMP trap unique from all other message types is the fact that it is the only method that can be directly initiated by an SNMP agent in the field. All other core SNMP message types are either initiated 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 different device types. Some devices, especially those built more recently, are capable of sending SNMP traps on their own to alert an SNMP manager when they experience a problem. For older devices that do not support SNMP natively, an SNMP RTU may be used to collect alarms from multiple legacy devices simultaneously, 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 confirmation 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.
There are two main ways to transmit useful information using SNMP traps. One is to use what are known as "granular traps". Granular traps may be distinguished from each other because they each have a unique identification number (known as an OID or "object identifier" in the SNMP world). The SNMP manager receiving 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 identification numbers to support this lookup method, no actual alarm data necessarily 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 that the SNMP manager could easily look up on its own.
When granular traps are not used, SNMP traps may be configured to contain alarm data within themselves. In this case, it's very common for all SNMP traps from the device to use just a single OID. To understand these types of traps, an SNMP manager needs to analyze the data contained within them. 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".
It's generally preferable to use granular traps for network monitoring scenarios because it reduces the load on your network that 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 to store alarm data instead. Imagine the headache from realizing your SMP manager will not be capable of collecting SNMP traps from 100% of your networked devices.
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. Convenient software and good build quality have led it to be a deployed at many telecommunications, utility, and transit companies.
Dual T/Mon masters and NetGuardian remotes providing regional monitoring ability and forwarding alarms via SNMP traps to an SNMP manager of managers (MOM), indicated by the red box.
This RTU sends SNMP traps based on a variety of inputs. Most commonly, the 832A will send SNMP traps to your SNMP 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 tripping.
This particular NetGuardian model also can send SNMP traps based on the current status of its eight analog current or voltage inputs. Since analog inputs are never absolutely on or off, but rather a value on a continuous range, the firmware and user configuration are used to determine 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 SNMP 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 detected that temperature had crossed one of these thresholds, you would receive an SNMP trap informing you of 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 a gradual reduction in your monitoring effectiveness, 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) that were not anticipated to be necessary in v1 of SNMP. 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.
A few SNMP project examples: At DPS, we've dealt with many SNMP applications, but here are a few that illustrate the practical implementation of SNMP traps in real environments:
One client, Edward, was looking for a system that could receive 22 ports of 202 and convert the alarms recevied by "TBOS or TABS" protocols and send SNMP to his NetBoss SNMP Manager. Ed was certain that it was an analog circuit that needed to be mediated.
Each of the 22 ports had 2 RTU's that monitor Contact closures and send outgoing data over analog circuit. Ed wanted us to quote RTU's w/ 202 modems. He was used to working with the NetGuardian 832A. This is a great product when it comes to transitioning in the future to LAN because it can be ordered with 202. Ed helped us to design the right system by putting together a spreadsheet that described all of his sites' discrete & analog alarm and relay output requirements. We would be replacing his older remotes because he could no longer find replacements for these.
We sent Edward a topology drawing showing how the T/Mon can accept 22 ports of 202 devices, and be able to communicate with the 44 devices on those ports, as well as a total of 80 devices all-together, and then covert the alarm data to SNMP traps which we would forward to their SNMP Manager.
Another client, Mitch, called us because he needed a T/Mon to monitor 2 SONET Rings via TL1 and some SNMP. This was in addition to about 20 RTU's to monitor battery voltage with analog inputs for monitoring pressure of copper wires.
Mitch had 45 nodes on his SONET Network, also has channel banks that output SNMP traps. All-together he was looking at monitoring approximately 150 devices. At the time, they reported into Lucent Navus EMS as well as Adtran EMS. He wanted us to work in parallel to these systems and Telnet to them, log in as a different user, and retrieve TL1 alarms. In the future, it was expected that T/Mon might be forwarding alarms to Air Force program called NetPlus (by AceCom).
Mitch was also interested in Battery Voltage Monitoring at approximately 20 different sites. He wasn't looking to monitor individual cells. He just needed to know thresholds of overall battery voltage. Mitch also had pressurized lines that held copper for his phone lines. He wanted to be able to monitor the pressure sensors to be sure that the lines had not been cut. We let him know as long as the sensor outputs 4-20mA or +92 to -92VDC then the NetGuardian could monitor it.
Related Topics:
SNMP Trap
Using SNMP Traps in a Network Management System
SNMP MIB
In-Depth Look at SNMP MIBs
SNMP OID
Key Equipment that sends SNMP traps:
T/Mon (SNMP Manager)
NetGuardian 832A G5 (SNMP Remote/Agent)
|
Request More Info
(simple online form) |
|
Next Page >> most related to this one |
Give Us a Call!
To find out more about this and other DPS applications, give us a call at our toll-free number and talk to one of our network specialists. They'll help you put together a perfect fit solution for your network!
RSS
