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 TodaySNMP is one of the most widely used communication protocols for remote monitoring systems. That's because it allows the real-time exchange of information between network devices - and it also allows notifications of events to be sent to technicians.
If you are already familiar with SNMP, you probably know that every version of this protocol (SNMPv1, SNMPv2c, and SNMPv3) supports three request types - Get, GetNext and Set. However, the newer versions of SNMP also support an additional request message called GetBulk.
Let's take a look at GetBulk and how it works.
SNMP defines two types of devices - agents and managers. Agents are devices that gather information about monitored equipment and send notifications to the manager. Managers are the devices that will query change-of-status information and receive notifications. In remote monitoring systems, agents are normally RTUs and managers are the central master stations.
As I've said before, every version of the SNMP protocol supports the same three different request messages. These are:
Although these messages are supported by all the SNMP versions, the v2c and v3 also support an additional requested type called GetBulk.
A GetBulk request execute multiple GetNext requests and returns it all in a single response.
In addition to requesting the OID that is in every SNMP request type, GetBulk gives you two additional capabilities. They are:
An Object Identifier (OID) is a value that uniquely identifies managed objects and their statuses in a MIB hierarchy.
In other words, imagine that you want to collect utilization information for all interfaces on an agent. One of the problems with utilization information is that you need a piece of reliable time information to be able to calculate the returned value between two retrieved utilization values. You can't simply use the clock on the management system because the delay between replies can vary request by request (network delay can be 50ms one request and then 150ms on the next and then 2 seconds), which makes the value quite unreliable.
In order to work around the unreliable clock issue, you can use sysUpTime value on the agent. This is the value representing the time since the agent was last initialized, in 1/100 of a second (10 milliseconds).
Now, your request will need to retrieve sysUpTime and utilization information for all interfaces. In the following example, let's assume that the device has 10 interfaces with consecutive instance values.
This is what the request would look like:
Request-GetBulk
non-repeaters = 1
max-repetitions = 10
sysUpTime.0
ifInOctets
The agent will respond to this request with:
Response:
sysUpTime.0 : (TimeTicks)<some value>
ifInOctets.1 : (Counter32)<some value>
ifInOctets.2 : (Counter32)<some value>
ifInOctets.3 : (Counter32)<some value>
ifInOctets.4 : (Counter32)<some value>
ifInOctets.5 : (Counter32)<some value>
ifInOctets.6 : (Counter32)<some value>
ifInOctets.7 : (Counter32)<some value>
ifInOctets.8 : (Counter32)<some value>
ifInOctets.9 : (Counter32)<some value>
ifInOctets.10: (Counter32)<some value>
As you can see from this example, non-repeaters value has instructed the agent to treat the first OID in the request (sysUpTime.0) as a Get request. Remaining OIDs in the request had GetNext operation performed max-repetitions times (in this case 10) and all values were returned in a single response.
GetBulk is significantly more efficient than other messages when multiple consecutive values need to be obtained. The industry's best practice is to use them whenever possible. In the example above, for instance, you have retrieved data that would require one Get message and ten GetNext requests to perform without GetBulk.
Also, note that if all you want to do is perform consecutive GetNext operations in a GetBulk request, you'll need to set the non-repeater value to 0.
As you might notice, GerNext and GetBulk are similar command options, but they have main differences.
With GetNext, your master station needs to keep asking for each item one-by-one until it reaches the end of the list. So, for example, if you want to get a list of all interfaces names from a device, then this means that you might end up sending 20 requests (or how many interface names this device might have - 2, 10, or even 30) might go out to the agent and 20 replies are sent back.
When using GetBulk requests, your master station will send one request only asking for an item and all following items up to a limit. Usually, the number of requests is greatly reduced through GetBulk. In some scenarios, the complete data set com potentially be returned with just one request/reply pair, but you normally won't know until you've sent the Get request.
GetBulk provides some savings in terms of bandwidth. But, even more importantly, it also reduces the effects of a long wait for responses (latency time).
For example, imagine you have a high latency time, maybe over a LAN or WAN, where the request/response exchange takes 50ms. The twenty GetNext requests required for the previous example will add up to a full second (1000ms) before all the data has been collected from the agent.
With GetBulk, the request/response exchange will take only 50ms. In theory, this means that you can monitor 20 more systems in the same given timeframe. In practice, you would see a bit of additional overhead, but not much at all.
If you can choose at all, it's better to always use GetBulk. This is because you'll have to send fewer requests and you'll have a much better information retrieval speed.
Now, let's use a simpler analogy. Imagine someone in your household just bought some groceries and asked you to bring them inside the house from the car. Instead of taking each item inside one by one (Get and GetNext), you might find that it is more efficient and less time consuming to simply use a bag to bring all the food inside (GetBulk).
GetBulk is not a popular capability of the SNMP protocol. This is mostly because it is not available in SNMPv1 and many devices still support this version.
In order to be able to have the GetBulk capability, you need equipment that works with SNMPv2c or v3. These newer versions enable you to take advantage of these feature benefits. However, if you have different devices working with different versions of SNMP, the industry's best practice is to invest in a multiprotocol master station.
A multiprotocol master station is able to support many different devices that are enabled to work with many different protocols. This means that, if you have SNMPv2c and v3-enabled equipment you'll be able to integrate them all under the same interface. You'll keep your initial investment in your older devices while also getting the benefits of your most modern gear.
The T/Mon LNX is a known example of an efficient multiprotocol master station. It provides you with scalability and robustness for your network and an intuitive web interface. The T/Mon is a feasible and cost-effective way to combine the benefits of all your devices and protocols in a single screen.
Before embarking on the development of your SNMP project, it's important to ensure that all your critical requirements are being met. You need a competent vendor that will work with you to evaluate your scenario and pinpoint all your needs while also finding some monitoring opportunities to optimize your network.
But, none of this is valuable if you can't have a perfect-fit solution. We are a US-based, vertically integrated monitoring systems manufacturer, so we are experts in what it takes to deliver a truly powerful solution.
Talk to us today, and let's protect your network.
