1320

Get a Live Demo

You need to see DPS gear in action. Get a live demo with our engineers.

White Paper Series

Check out our White Paper Series!

A complete library of helpful advice and survival guides for every aspect of system monitoring and control.

DPS is here to help.

1-800-693-0351

Have a specific question? Ask our team of expert engineers and get a specific answer!

Learn the Easy Way

Sign up for the next DPS Factory Training!

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

SNMP Polling Vs SNMP Traps

By Andrew Erickson

April 9, 2020

Share: 

Simple Network Management Protocol (SNMP) is a communications protocol that is standard in network monitoring systems. It allows for monitoring and control of SNMP-enabled devices in remote networks.

The SNMP architecture is based on the manager-agent format that includes two parts:

  1. SNMP manager will collect information from your multiple SNMP agents deployed at remote sites.
  2. The agents' job is to gather remote site data and send it back to the master through the SNMP protocol.
SNMP monitoring system
A generic SNMP network monitoring application looks like this.

This exchange of information can be done via polling or via standard traps. Unfortunately, many network operators seem to know only about one of these methods, missing the opportunity to have a more efficient network monitoring system.


Let's take a look at what polling and traps are and the principles of SNMP polling vs traps.

Quick Review: What is SNMP Trap?

SNMP traps are one of the most frequently used messages. They are unsolicited sent by your agents when they need to inform your manager about events.

This type of message is the only one that is initiated by your remote devices, all the other kinds of SNMP messages are initiated by the manager or are a result of a message initiated by the manager.


SNMP traps can be divided into two different systems according to how they transmit information:

  1. Granular Traps

    Granular traps have a unique object identifier (OID) that makes it possible for the SNMP manager to distinguish each trap from one another. The MIB file is where the meaning of each OID is stored, so that's why the MIB is called the codebook of SNMP messages. The manager will use the MIB to understand the trap sent by the agent.

    In this method, all the details about the issue are in the MIB, so the traps don't really need to carry any information about the alert. This significantly reduces your bandwidth usage.

  2. Variable Bindings

    Traps in this method incorporate the information about the problem within themselves. All the traps will have the same OID, so your manager will have to process the data in the trap to be able to understand the message.

    The information is embedded within a trap in a key-value pair configuration. These are called variable bindings and they bring extra information about the message. For example, a trap might have variable bindings for urgency level, notification description, and etc.

So, an SNMP trap is simply a change-of-state (COS) message. Although it is normally triggered by a new issue occurring, it can also mean an alarm clear or a status message.


What is "SNMP Polling"?

Polling in network management consists of a device asking for and receiving information. In direct contrast to standard SNMP traps, "SNMP polling" is a process that involves the master requesting and receiving data, in the form of Management Information Base (MIB) objects, from the agents deployed at remote sites.

So, for example, your SNMP management station could be polling a device, such as a router, to know the status of a network interface. You can configure your manager to perform this task every couple of seconds or minutes (depending on your urgency and network bandwidth). If your interface utilization is at 100%, then your manager will trigger an alarm and send you and your techs alarms in relation to that.

SNMP Get Vs SNMP Get-Next

A Get request and a Get-Next are SNMP messages that the manager uses in order to ask for information from the agents.

A Get request, as the name suggests, is the first message the manager sends out to ask for data. The intended device will then reply with a Response message.

The Get-Next message is the manager's reply to a Response message. This message type allows the manager to discover if more information is available from the agent. It after the first Get-Next message is sent out, the manager can continue to send requests for the more available information until it is satisfied or there's no more data.

Community Strings

When your SNMP manager requests the status of an agent, it should also send along a community string.

The community string is a security feature in the form of a password that allows devices to talk to each other in a safe way.

Many security-conscious organizations have this feature set up - as this enhances the safety of their information. If the community string is correct, then the agent responds with the requested data. But, if the community string is incorrect, the agent will simply disregard the poll and not answer at all.

Typically, most devices come from the manufacturer with a community string set to "public". So, once you receive your device, you'll want to change the community strings to strong password values.

Note that community strings are only supported in the SNMPv1 and SNMPv2c versions of the SNMP protocol. If you work with the latest version, the SNMPv3, then instead you will have a username/password authentication along with encryption as a security measure.

SNMPv3 security
Unlike earlier versions of SNMP, the v3 resists tampering by using message encryption.

What Are The Differences Between Polling and Traps?

Now, that you know what polling and traps are, you can start to see the differences between these two methods.

Where The Information Exchange Starts

The act of polling information from agents is initiated by the SNMP manager, whose main objective is to gather information about devices on the remote network.

On the other hand, the agents can independently send a trap to the manager to report a new event or change of status.

If you set up your SNMP system to only have the agents sending traps (with no polling from the manager), then the manager won't request information from the remote devices. The agents will be silent until something needs to be reported to you.

When an issue happens in your network, such as high-temperature levels, then the agent will send an alert to the manager using the trap. The SNMP manager will then forward that information to your network tech.

SNMP polling and trap
A traditional SNMP poll (left) vs an async SNMP trap (right)

The bottom line here is the difference between where the information exchange will start: at the manager or at the agent.

A few more details: SNMP Message Transfer

SNMP uses the User Datagram Protocol (UDP) to transfer messages. This means that UDP packets need to be successfully exchanged between agent and manager (and vice versa) for the monitoring to be effective.

So, another difference that you can note is that requests sent from an SNMP manager may be sent from any port - usually, it's 161 - while agents send traps via port 162. The agents receive requests on port 161 and the manager receives traps on port 162.

Community String

When your manager is polling remote devices, an SNMP community string is mandatory so it can get a response from the target agents. On the other hand, however, community string is not necessary to receive a trap message.

Polling or Traps: What is The Best Method?

Imagine that you are a parent with a school-age child.

Your child will tell you about problems at school only when something wrong happens. This compares to a trap that is sent by the agent only when a problem with the managed device needs to be reported.

However, as a parent, you will want to check with your kid's teacher to see his progress every so often, this way you can address problems in a timely manner before his tests.

The same is true for SNMP polling. The manager will spend more time and effort, but it will know the exact status of your remote network before issues happen.

You can set up your SNMP manager to ask for information from your remote equipment every couple of minutes. This makes sure that you will get a report about all the devices in your network. With this report, you're able to analyze trends and prevent possible problems. This is only be done with polling.

So, between polling and traps, which is the best method?

The answer here is... both! Polling gives you more data about monitored devices but you will spend more network and system resources. Trap messages will lack daily information but it's more efficient in terms of knowing when something is wrong in a timely manner.

When you make use of both monitoring methods, diversifying your monitoring system, you'll be getting the best of both worlds.

Learn More About SNMP

A strong network fault management system best practice to put in place is to include both polling and monitoring for SNMP traps. Polling the status of your agents is a guaranteed way of learning about outages - but not in a timely manner. Traps happen in real-time, however, there's really no guarantee that you will receive a trap during an outage. By merging these two monitoring methods together you will gain both speed and accuracy.

If you are starting to work with SNMP, you need to get on top of all important information about this protocol to be able to get the most out of your remote monitoring system.

We've worked in multiple SNMP solutions throughout our 30+ years in the market, and we've decided to share our experience with you. SNMP Monitoring Implementation White Paper gives you a solid understanding of the SNMP protocol and helps you efficiently work with SNMP alarm management systems.

Download your free copy and learn how to efficiently work with SNMP in your unique scenario.

Share: 
Andrew Erickson

Andrew Erickson

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 17 years of experience building site monitoring solutions, developing intuitive user interfaces and documentation, and opt...