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 TodayIn SNMP, messages that contains control information that are used for communicating or exchanging data is referred to as a protocol data unit (PDU). The SNMP version 1 (SNMPv1) specification lists five PDUs that can be used to accomplish specific tasks. The 5 PDUs are GetRequest, GetNext, SetRequest, GetResponse, and Trap. These 5 basic PDUs form the basis of using SNMP and can be found in all versions of SNMP.
Later updates to the SNMP specification has lead to the creation of SNMPv2 and SNMPv3 with each version adding more PDUs on top of the previous version. SNMPv2 added two more PDUs over SNMPv1. The two additional PDUs in SNMPv2 are GetBulkRequest and InformRequest. SNMPv3 added just one more PDU to the mix. The added PDU in SNMPv3 is called Report. The information on the this page is meant to be a "quick primer" and will only cover the SNMPv1 PDUs.
A manager-to-agent message requesting the current value of a managed object. This could be "Send me your internal temperature sensor reading" or "Is the site door currently open?". You'll use GetRequests to fill in any information that you don't automatically receive via traps. To maintain superior visibility, you can program any good SNMP manager to send automatic GetRequests at regular intervals. This is a "keep alive" function, because you'll quickly know that a device is offline if it doesn't respond to a GetRequest.
A manager-to-agent message requesting the current value of the managed object one number after the one named in the request. (This is a way of walking down a table of values.) GetNext is effectively a shorthand command for automatic polling by your SNMP manager. Instead of specifying every value you want to query, you only have to specify the first. After that, GetNext will loop you through all of the other values. This is another way to work around 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 GetNext 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.
A manager-to-agent message that writes a new value to a managed object. If GetRequest is a "read only" command, then SetRequest is a "write" command. You're telling your device to do something. These are like control-relay commands that predate SNMP. If you want to turn on a generator, activate a light, close an exhaust vent, or do anything else remotely, you'll send a SetRequest to do it. As a plain English example, one possible SetRequest is "Northwest Mountain Tower Site RTU, please activate your backup diesel generator now". Like everything else in SNMP, SetRequests get more powerful when you have a good SNMP manager. An SNMP manager should allow you to send that example SetRequest manually when YOU see that your site batteries are running low. A superior manager, however, will be able to understand the low-battery situation ON ITS OWN and respond with an automatic SetRequest.
An agent-to-manager message in response to a GetRequest or a SetRequest. In either case, the message reports the current value of the managed object named in the manager's request. Are you loving the self-explanatory names yet? A GetResponse is, obviously, a response sent by an SNMP element to your SNMP manager. It is the expected response after you send a GetRequest. If you asked for the temperature reading at your remote site, the GetResponse could be "78.6 F".
An agent-to-manager message reporting a change in the value of a managed object. This is the core of SNMP and the most common message type. Your SNMP elements (equipment and RTUs) will send traps whenever they determine it's appropriate. Unfortunately, traps have no delivery verification and "radio silence" could mean "all clear" or "device is dead". That's why we have other message types to fill in gaps and push back the "fog of war" holes in your situational awareness.
You can ask the vendor to extend the MIB to include this feature. DPS Telecom has extended its MIB to support client needs. But you need to understand that extending a MIB is actually a software development project. The MIB is not just a text file. It is a software interface document to the embedded firmware of your SNMP device. Making additions to the MIB requires rewriting the device firmware. This is a serious project, involving writing code, debugging it, and undergoing a thorough quality assurance process.
