The Simple Network Management Protocol (SNMP) is a widely used protocol for managing, monitoring, and maintaining network-connected devices. Its primary purpose is to allow IT administrators and outside-plant (OSP) managers to monitor various components of the network remotely and take corrective action when needed.
SNMP is a widely used protocol because it is very efficient, cost-effective, and easy to manage.
It's also an "open" protocol, meaning that all of the rules and parameters are published for use by any manufacturer. That creates a thriving ecosystem of devices that support SNMP. As its popularity increased, users became more and more interested in buying devices that use SNMP. Manufacturers adapted to meet this demand, and this reinforcing cycle continued until SNMP became a global standard.
This stands in contrast to how things used to be, with each manufacturer producing their own secret "proprietary" protocol. The goal in those days, for some equipment manufacturers at least, was to create their own protocol as a means to trap you within their "walled garden" of a product ecosystem. Once your organization built up an investment in one particular brand of equipment, it was difficult to justify throwing it all away and starting over.
DPS was an early player in unwinding this problem. Much of our business was built on engineering compatibility for proprietary and legacy protocols into our SNMP master station. Virtually all of our alarm remotes (RTUs) support SNMP to be compatible with any SNMP manager that you care to use.
There are two classes of devices in any SNMP-based system:
SNMP works by sending out "GET" requests to devices that are connected to the network. The device can then response back with an acknowledgement of the request or a "TRAP" message (an unusual name, but it simply means "message") that details what has changed on the device.
This process is done automatically ("asynchronously") when important events occur.
That's how SNMP supports management of fault detection and correction. By sending a trap message when a problem is detected on a network-connected device, administrators can quickly take corrective action before any further issues occur.
For some devices, trap messages can also be scheduled to occur at specific intervals. This can be useful for "heartbeat"/"keep-alive" functions or to, for example, allow your SNMP manager to record the reading from a temperature sensor at regular intervals.
The "community string" is another SNMP concept that supports segmentation of SNMP messaging in complex networks. The default for nearly every device is "public". If you assign
On more recent devices, SNMP also allows for the automatic configuration of devices on the network. By sending out a "SET" request, an administrator can quickly configure a device, such as setting up a port address or changing security settings. SNMP can also be used to query device information, such as the amount of memory available, or the current temperature, using a "GET" request.
SNMP is a powerful protocol that can help keep networks running smoothly. By allowing administrators to monitor, configure and manage devices remotely, SNMP allows for greater efficiency and control over the network. It is also easy to use and cost-effective, making it the ideal choice for many IT departments.
When implemented correctly, the SNMP protocol can provide tremendous value for an organization. If you are considering using SNMP to manage your network, be sure to do research and find the right solution that meets your needs. With the right implementation, SNMP can save time, save money, and help keep networks running smoothly.
In my work with DPS clients on remote monitoring projects involving SNMP, I find that sharing specific examples brings people up to speed a lot faster that just endlessly discussing concepts like a textbook.
The NetGuardian 832A is an example of an SNMP-capable RTU (remote telemetry unit). It supports the SNMP protocol for remote control, monitoring, and configuration. With up to 32 discrete alarms and 8 analog alarms, it can be used to monitor a variety of different systems.
Like a lot of modern SNMP-based devices, the SNMP protocol isn't the only way to communicate with the NetGuardian. The device also includes an embedded webserver for access to runtime data, configuration, and an event log. The G6 version includes TLS 1.2 encryption for HTTPS.
This web interface means that NetGuardian has an Ethernet connection for remote access, allowing administrators to manage the device from anywhere in the world.
The NetGuardian 832A is also compatible with SNMP management software. This includes any standard SNMP manager or DPS Telecom's "T/Mon" alarm management platform.
As I described above, SNMP protocol is (at least by default) asynchronous. That means that your SNMP manager simply waits for incoming SNMP traps from all of its connected agents.
Imagine what that means if one of those SNMP agents goes offline. It obviously won't be sending any traps, and your SNMP manager will have no choice but to happily assume that all is good. For mission-critical remote monitoring, this is clearly far from ideal.
This contrasts strongly with polled architectures. In this model, your central manager does not simply to wait to receive alarm messages form individual devices. Instead, it actively "polls" each device in an orderly loop. If no response is received, your manager knows that something is wrong. That speeds your discovery of the problem before it is allowed to grow.
That's precisely why the T/Mon alarm management platform polls its connected NetGuardian RTUs instead of simply waiting to hear from them. NetGuardians are capable of both this method and, for maximum compatibility, standard SNMP trap reporting.
Some more recent implementations of SNMP use GET messages as a method of polling for precisely the same reason that I described above.
At DPS, we're experts in remote monitoring. This necessarily includes a lot of experience with SNMP protocol.
If you've got a question, we can help you get started with your project. Just call 1-800-693-0351 or email email@example.com
Andrew Erickson is an Application Engineer at DPS Telecom, a manufacturer of semi-custom remote alarm monitoring systems based in Fresno, California. Andrew brings more than 16 years of experience building site monitoring solutions, developing intuitive user interfaces and documentation, and opt...
You need to see DPS gear in action. Get a live demo with our engineers.
Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
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 Today