Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
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 TodayA SNMP device is a device managed using the Simple Network Management Protocol (aka SNMP).
SNMP is an open-source protocol, meaning any manufacturer is free to utilize it. While there are many other protocols, SNMP is one of the most common due to its open source nature and ease of access. SNMP allows for managed devices to talk across different networks and manufacturers.
Your SNMP master communicates with your managed devices via different types of messages; one of which is known as the GET Request. These messages have many different applications, and this article will cover the top 3 after a brief SNMP Overview.
The communication between an RTU and master station is either polled or asynchronous.
Polled
Polled transmissions mean that the master station controls communication with an RTU, or several RTUs, over a shared line. The term "polling" refers the way the master station will continuously check RTUs to see if they are still connected and if they have anything to report. So, basically, the master will send a message to the RTUs, one at a time, asking each whether it wants to use the line.
Asynchronous
On the other hand, we have the asynchronous transmission - also known as start/stop transmission - that is when data is sent from RTUs at irregular intervals instead of at a steady stream. This means that the messages are sent only when something must be reported (with no way of knowing if silence means "all good" or "I am offline").
SNMP is asynchronous: when a relevant event happens, the agent is able to immediately communicate to the manager. Synchronous protocols, on the other hand, need to wait for a status request from the manager.
GET request
A manager can issue a GET request to an RTU - also sometimes called an SNMP agent. A GET message asks the RTU to report a value back to the manager so that it can access the status of a site or piece of gear. There are several types of these messages: GET, GET-NEXT, and GET-RESPONSE. While each requires a response from the RTU, the information it requests is slightly different.
Trap
Conversely, an SNMP device, usually an RTU, can send a message called a TRAP whenever a change-of-state (COS) event occurs. These TRAP messages are sent to a manager, which converts the TRAP into a remote alarm for management and control.
SET Message
The SET request is only issued from a manager to an RTU and is intended to change a discrete or analog input. For instance, a SET request may require the RTU to turn on a generator or set a thermostat to specific temperature.
As you can see, most of the messages - GET, Get-NEXT, and SET - are only issued by the SNMP manager. Since the Trap message is the only message capable of being initiated by an agent, it is the message that our RTUs use to report alarms. This notifies the SNMP manager as soon as an alarm condition occurs, instead of waiting for the SNMP manager to ask.
The small number of commands used is only one of the reasons SNMP is simple. The other reason is that its reliance on an unsupervised or connectionless communication link.
This simplicity has led directly to its widespread use, specifically in the Internet Network Management Framework. Within this framework, it's considered robust because of the independence of the manager from the agents - so, if an agent fails, the manager will continue to function, or vice versa.
This is the main use for the SNMP GET request and simply constitutes of the GET request meaning itself.
When a human operator needs immediate information when looking at a site, a manager-to-agent message requests the current value of a managed object. This could be "Send me your internal temperature sensor reading" or "Is the site door currently open?"
If you want instant data, you'll use GET requests to fill in any information that you don't automatically receive via traps.
Remote monitoring is an effective way to make sure that the equipment you have at your unmanned sites is in good, working, condition. It reduces truck rolls, saves you time and money, and can even extend the life of your equipment.
However, there's a piece to this puzzle that is often overlooked.
It's not enough to just have monitoring equipment at your site. Your equipment sends alarms to your RTUs or manager when something goes wrong, right? But, what happens when your equipment is down and unable to send an alarm?
To your RTU or manager, a unit that is not working and a unit with no alarms look virtually the same.
For this reason, you can't only wait for asynchronous alarms messages from your RTU. If it fails, you might just be waiting forever. You should be able to send some kind of proactive request from your manager and listen for a response.
SNMP devices in your network support a more reliable ping method based on GET requests. As I told you earlier on, an SNMP GET message is sent by the manager to a device to request a specific value. If you want to know the temperature reading at a remote site at this exact moment, your manager will send a GET request to the local SNMP RTU to demand the sensor value.
Therefore, what you need is a monitoring device that doesn't just wait for alarms, but instead requests status updates from your gear. An "SNMP ping" is a method of achieving "heartbeat" or "keep alive" functionality with SNMP communications.
A smart SNMP RTU or manager can take advantage of the call-and-response GET mechanic to send a kind of "SNMP ping." On an automated schedule (one every 3 minutes, for example), your device will send an SNMP GET to the device. If the device responds, all is well. If no response is received after a few successive requests, your manager can conclude that the device is offline and an alarm must be reported.
It may not be realistic for you if you already have an extensive collection of SNMP RTUs - but you're starting from scratch in the process of planning your monitoring system - an alternative is to choose a polled protocol like DCP. A polled protocol has keep-alive functional bake in, since RTUs don't send asynchronous messages at all, Instead, the master asks the RTU for alarms every few seconds.
An SNMP manager might also use the GET request to perform full updates on regular basis. This means that it will ask to listen to all alarm status in a particular device.
The process for the update is fairly simple. A manager asks an agent for data with a GET message, the agent then will send back a GET-RESPONSE. The manager might only need that one piece of data, or it can send a GET-NEXT message (and then another, and then another) to request a full status update.
This is a way to work around what could be considered a weakness of basic SNMP: asynchronous notifications. Your network elements only send traps when something is "wrong" according to their own unique rules.
If you regularly send GET-NEXT requests, you're overriding the device's internal trap logic and collecting values for every alarm state and sensor value. With a complete picture, your central SNMP manager - either automatically or with you overseeing - can make the best possible management decisions.
To get the most out of SNMP protocol and GET requests, it's important to choose your SNMP manager carefully. Ultimately, the quality of your master station will determine how well you're positioned in terms of SNMP.
Imagine how much easier it would be to have an SNMP manager working constantly to help you. When selecting a master station keep the following capabilities in mind in order to choose the best unit possible.
Assign severity to your alarms
The device that you're monitoring might not embed a severity in the trap, or you might not agree with the level they assigned.
Categorize the alarms by types
Also, allow access to those types to be selectively given to authorized people. Too many alarms going into one large pile is never a good thing. Differentiation and selective routing is key when multiple people and/or multiple departments are involved in alarm management.
Maintain history that can be queried by many different criteria
This is so network events can be analyzed after-the-fact.
Have a "strong" notification system
A must for those companies that don't have 24x7 NOCs, strong notifications also comes in handy if you step away from your master screen. A strong notification system must support multiple forms of media, including Alpha pagers, Numeric Pagers, cell phones, PDA's, and email. It must also have scheduling that allows you to notify the right person for the right problem at the right time. And, of course, your master's notification system must provide for alarm escalation if required.
Be actively supported by your vendor
Do you remember when your last software update was?
Support non-SNMP devices
Even though we live in an SNMP world, probably there are still non-SNMP devices in your network. Wouldn't it be good if your system could look at those as well?
Filter nuisance alarms
Are there some alarms that you want to ignore between 9 and 5? Do alarms keep toggling after you already dispatched on them? Life's too short for that kind of frustration. An SNMP trap, like any other alarm, might not be relevant. In fact, even alarms you care about at times might be a "nuisance" at other times. You need to be able to turn off alarms you never want to see, either temporarily or permanently.
Forward alarms to a higher-level master
What about forwarding SNMP traps to higher-level managers at Corporate? Not many systems do this, so make sure any system that you consider can do forward alarms as SNMP traps.
Detailed text messages for every alarm
Does your system have the ability to tell you what you should do when an alarm comes in? If it did, your staff's learning curve and effectiveness would go way up.
System scalability
Is your system scalable? If you only have one screen on your master, you can't effectively distribute or route your monitoring load. Make sure that multiple people can access the system concurrently. By the way, wouldn't it be great if they could just web browse to the data (secured by SSL encryption)?
Strong security
You have critical data traveling through your network. Make sure you can control who accesses it and to what extent. Having "all or nothing" access control doesn't cut it these days.
Derived alarms and controls
It's nice to see SNMP alarms on the screen, but what about the alarms that don't directly come from SNMP devices? Make sure you have a system that is capable of continuously looking for combinations of events that indicate critical problems. Also, make sure it can notify you swiftly and automatically.
Graphical alarm presentation
SNMP alarms, by definition, are text-based. However, you must make sure your system presents those alarms in a meaningful way. Graphical screens allow you to assign geographical hierarchy to your network so you get an intuitive view of your system that allows you to manage your network more effectively. The old principle of "a picture is worth a thousand words" applies to SNMP as much as it does to anything else.
We've worked hard on our T/Mon Master stations to accomplish all that is on this list. All alarms are equal once they've been imported by T/Mon. Any alarm can appear on T/Mon's geographic maps, web interface, or mobile web (smartphone) interface. You can even setup automatic text, voice, and/or email alerts for SNMP alarms just as easily as non-SNMP alarms. Everything is in one unified system that can be monitored by a single person - although multiple users are supported for large networks where alarm counts are very high.
Taking into consideration all thirteen capabilities of an efficient SNMP manager, and assuming you found a masters tation that has all of them, what information would you need on hand before ordering?
While many people find it difficult to simply find a comprehensive system for SNMP monitoring, customizing the hardware to fit your situation is a far more challenging endeavor: you often need an experienced monitoring engineer to begin speccing out and planning your monitoring.
This is why it is critical to work one on one with an experienced, patient engineer and manufacturer who offers customization for free.
Monitoring Specialists, like DPS Telecom, go the extra mile to help determine whether you need a system that has multi-protocol support, more than 25 different protocols, as well as whether you need backend compatibility with older protocols.
And although you don't need to know the details, our experienced engineers will craft your master to exacting specs if you happen to have them.
Such flexibility is what makes our T/Mon master stations and our service so popular. They are generallly an ideal candidate when you have to monitor SNMP gear yet have lots of legacy/proprietary/SCADA gear in your network.
Besides offering the T/Mon master station, we also offer you many different SNMP RTUs that can meet any of your requirements - you can get stand-alone local visibility through any web browser, expandable alarm capacity, LAN access via dial-up connection and more.
If you want more information about SNMP, SNMP GET requests, T/Mon, or simply about remote monitoring, give us a call, we can help you on your pursue for the perfect-fit solution.
Morgana Siggins
Morgana Siggins is a marketing writer, content creator, and documentation specialist at DPS Telecom. She has created over 200 blog articles and videos sharing her years of experience in the remote monitoring industry.
