Download our free SNMP White Paper. Featuring SNMP Expert Marshall DenHartog.
This guidebook has been created to give you the information you need to successfully implement SNMP-based alarm monitoring in your network.
1-800-693-0351
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.
Reserve Your Seat TodayLet's start by learning what SNMP is.
The Simple Network Management Protocol (SNMP) is nothing more than a standard language that computers use to control each other and report important information. Its advantage today is that a very large number of network devices support SNMP, enabling them to work together.
Because of the large amount of support, the question isn't "do I need SNMP", but "how do I support it? And how do I get SNMP training?"
SNMP was created in 1988 and at the time, it was simply a short-term way to manage computers on the Internet and in private networks. It replaced the earlier "SGMP" ("G" stood for "Gateway").
SNMP architecture is, in principle, very similar to the internet technology you're using right now to read this web page. Your computer (or tablet, or smartphone) sends a standardized request to our web server. Our web server responds by sending each of you the information you want. There are many computers in various locations, and our single server sends web pages to all of them.
In SNMP, "agents" are remote devices out in the network.
What exactly the agents depend on the kind of network you have (ex. Are you a small office, a national telephone company, or a power utility?).
They can be printers, routers, switches, servers, alarm remotes, generators, and lots of other things. These agents report problems and receive commands from a central master station also called manager. This is known, oddly enough, as the "manager-agent model".
When you add a new agent to your network monitoring system, there are a few simple setup steps:
This will vary from device to device, but there will always be some way to tell your new agent where to find your master. Some masters are also able to perform auto-discovery and automatically configure new agents.
If you've ever connected a printer or a digital camera to your computer, you know about installing drivers. A "driver" is a file that tells your computer how to communicate with the other device. In SNMP, although the basic protocol is always the same, every agent has different things that it can report. Generators report fuel levels, for example, while printers report toner and paper levels.
A Management Information Base (MIB) is simply a file that tells your manager what information this particular agent can report and what commands it can accept. You'll receive a MIB from your agent manufacturer, and you load ("compile") it into your manager as part of setting up the new agent.
You may initially run into problems with the MIB, but these can generally be solved quickly with the right troubleshooting methods
Each element in the SNMP world is addressed with an Object Identifier (OID). These are long strings of dot-separated numbers. They look something like extra-long IP addresses (ex. "1.3.6.1.4.1.2682.1.2.102").
And just like an IP address, each additional number adds detail. The first several numbers are always the same for SNMP devices. In the example above, "1.3.6.1.4.1..." means only "enterprise SNMP equipment". The last few numbers mean "DPS Telecom" (the manufacturer of this agent), "Alarm Monitoring Equipment", "RTU", and (finally) "Alarm Point 2".
This OID represents a single discrete alarm input on a remote managing device. If your manager received an SNMP message with that OID, it would alert your network administrators about an equipment failure (or whatever you decided to wire into Alarm Point 2). Other OIDs can represent a generator turning on, a door opening, an empty diesel tank, or just about anything else you can imagine. OIDs are generally contained in a MIB file.
Learn more from our Library
View Our Library »
- Over 50 white papers written by Industry Veterans.
- Provides tips for an effective network management system as well as how to integrate legacy equipment.
SNMP uses five basic messages (TRAP, GET, GET-NEXT, GET-RESPONSE, and SET) to communicate between the SNMP manager and the SNMP agent.
The vast majority of messages are traps (it's a weird name, but just think "alert message" whenever you see "trap"). These are messages sent to the manager by an agent when something needs to be reported. An industrial refrigerator, for example, might send a trap to the manager when it loses power or when temperatures rise too high.
An RTU like a NetGuardian sends traps when the equipment and sensors it's monitoring and managing report a problem. Traps are the lifeblood of SNMP, giving your manager the data required to give you a "big picture" understanding of your network-wide status.
But managers don't have to sit around waiting for agents to send a message. Sometimes, they prefer to ask for data proactively. This enables managers to build reports by having all agents send a status report at regular intervals.
It also ensures that devices are still active because you don't otherwise know if a quiet device is offline or simply doesn't have anything to report.
A manager asks an agent for data with a "get" message, the agent will send back a "get-response". The manager might only need that one piece of data, or it can then send a "get-next" message (and then another, and then another) to request a full status update.
Finally, an SNMP manager sometimes has to tell an agent to take action. Some agents have control relay outputs that can be toggled. Others have beacon lights, backup systems, thermostats, and other things that can be changed with a "set" command.
A set command targets a specific OID and specifies a desired value. Translated to plain English, a set message might read something like "Set thermostat to 21 degrees Celsius" or "Activate backup generator".
When an agent sends a trap message, it can include OID and a data payload (called "variable bindings") to clarify the event. Quality agents like DPS NetGuardian RTUs send a comprehensive set of plain-English variable bindings within each trap to maintain traditional telemetry event visibility. Well-designed SNMP managers can use the bindings to correlate and manage the events. Managers will also generally display readable labels to facilitate user understanding and decision making.
Another best practice is to deploy the third version of SNMP. SNMPv3 brings many more security features than the last versions (these would depend mostly on the community string capability). With SNMPv3, your messages will totally encrypted.
This article in our series on the Simple Network Management Protocol (SNMP) examines the communication between managers and agents. Basic serial telemetry protocols, like TBOS, are byte-oriented (a single byte is exchanged to communicate). Expanded serial telemetry protocols, like TABS, are packet-oriented with packets of bytes exchanged to communicate.
The packets contain a header, data and checksum bytes. This offers vastly more detail without requiring a companion database, but bandwidth requirements are obviously many times higher for packet-oriented protocols. As time marches on, however, bandwidth availability continues to increase rapidly.
SNMP is packet-oriented with the following SNMP v1 packets (Protocol Data Units or PDUs) used to communicate:
The manager sends a Get or GetNext to read a variable or variables and the agent's response contains the requested information if managed. The manager sends a Set to change a variable or variables and the agent's response confirms the change if allowed. The agent sends a Trap when a specific event occurs.
The image below shows the packet formats. Each variable binding contains an identifier, a type and a value (if a Set or response). The agent checks each identifier against its MIB to determine whether the object is managed and changeable (if processing a Set). The manager uses its MIB to display the readable name of the variable and sometimes interpret its value.
Absolutely. Here are two specific SNMP examples you can review while learning SNMP:
We have to support lots of legacy and proprietary protocols if that's what our clients need, but it is certainly the most common.
In our environment, SNMP RTUs are a great example of SNMP agents.
These are remote boxes that sit out at remote, unmanned locations and monitor the equipment and conditions there. One NetGuardian 832A, for example, might be monitoring temperature sensors, humidity sensors, doors, motion, water leakage, fuel levels, and power voltages using external sensors. It could also be tracking contact-closure alarms from various equipment like generators, rectifiers, switches, SONET/optical ring gear, UPS batteries, and other important equipment.
Any deviation from ideal conditions would, in this example, trigger an SNMP trap from the NetGuardian 832A. The beauty of an open protocol like SNMP is that the trap could be directed at any standard SNMP manager from any manufacturer (you could also use the DPS Telecom T/Mon manager, of course). Your SNMP manager could direct a response from the NetGuardian, such as turning on a backup generator to handle a commercial power failure.
An SNMP-capable PDU will toggle outputs in response to an SNMP set command from your SNMP manager. This type of device brings remote power control under your SNMP monitoring umbrella. That's significant because it's silly to have one system for remote monitoring and a completely separate system for remote control. A large SNMP infrastructure in your network allows you to see what's happening AND react from your SNMP management interface.
All DPS Telecom products include comprehensive technical support. If you've purchased one of our products and are encountering any kind of issue, contact DPS Tech Support today at 559-454-1600.
At DPS Telecom, the representative who answers your call isn't an intern reading from a script. DPS Tech Support representatives are engineers who contribute to product development. And, if your problem requires additional expertise, the DPS Engineering Department that designed your product is right down the hall.
Help us connect you to the right engineer by filling out this quick questionnaire. Simply leave your contact information to get started, and we'll call you back. Most preliminary discussions are about 15 minutes, and afterward, we'll send you a custom application diagram of a recommended solution that'll make it easier to justify your project to management.
