SNMP Tutorial Part 1: An Introduction To SNMP

What is SNMP?

MIB object identifier tree
The MIB tree is a visual representation
of how OIDs are formed.

SNMP ("Simple Network Management Protocol") is nothing more than a standard language that computers use to control each other and report important information. Its advantage today is that a very large number of devices support it, enabling them to work together.

How long has it been around?

SNMP was created in 1988. At the time, it was simply a short-term way to manage computers on the Internet and in private networks. It replaced the earlier "SGMP" ("G" stood for for "Gateway").

Now, of course, SNMP is just about everywhere. You'll find it in corporate office buildings, remote industrial telecom sites, and even home offices.

How do the pieces fit together?

SNMP architecture is, in principal, very similar to the internet technology you're using right now to read this web page. Your computer (or tablet, or smartphone) sends a standardized request to our web server. So do other computers around the world. Our web server responds by sending each of you the information you want. There are many computers in various locations, and our single server sends web pages to all of them.

In SNMP, "agents" are remote devices out in the network. What exactly the agents are depend on the kind of network you have (ex. Are you a small office, a national telephone company, or a power utility?). They can be printers, managed switches, alarm remotes, generators, servers, and lots of other things. These agents report problems and receive commands from a central "manager". This is known, oddly enough, as the "manager-agent model".

Can managers and agents instantly communicate with each other? Do I need to set something up first?

When you add a new agent to your network, there are a few simple setup steps:

Step 1: Configure the agent with the IP address of your SNMP manager.

This will vary from device to device, but there will always be some way to tell your new agent where to find your master. Some masters are also able to perform auto-discovery and automatically configure new agents.

Step 2: Compile the agent's MIB into your manager.

If you've ever connected a printer or a digital camera to your computer, you know about installing drivers. A "driver" is a file that tells you computer how to communicate with the other device. In SNMP, although the basic protocol is always the same, every agent has different things that it can report. Generators report fuel levels, for example, while printers report toner and paper levels. A "MIB" (Management Information Base) is simply a file that tells your manager what information this particular agent can report and what commands it can accept. You'll receive a MIB from your agent manufacturer, and you load ("compile") it into your manager as part of setting up the new agent. You many initially run into problems with the MIB, but these can generally be solved quickly with the right troubleshooting methods.

How are SNMP messages structured?

Each element in the SNMP world is addressed with an Object Identifier (OID). These are long strings of dot-separated numbers. They look something like extra-long IP addresses (ex. ""). And just like an IP address, each additional number adds detail. The first several numbers are always the same for SNMP devices. In the example above, "" means only "enterprise SNMP equipment". That's going to be the same for every agent you use. The last few numbers mean "DPS Telecom" (the manufacturer of this agent), "Alarm Monitoring Equipment", "RTU", and (finally) "Alarm Point 2". This OID represents a single discrete alarm input on a remote monitoring device. If your manager received an SNMP message with that OID, it would alert you about an equipment failure (or whatever you decided to wire into Alarm Point 2). Other OIDs can represent a generator turning on, a door opening, an empty diesel tank, or just about anything else you can imagine.

SNMP uses five basic messages (TRAP, GET, GET-NEXT, GET-RESPONSE, and SET) to communicate between the SNMP manager and the SNMP agent.

The vast majority of messages are traps (it's a weird name, but just think "alert message" whenever you see "trap"). These are messages sent to the manager by an agent when something needs to be reported. An industrial refrigerator, for example, might send a trap to the manager when it loses power or when temperatures rise too high. A RTU like a NetGuardian sends traps when the equipment and sensors it's monitoring report a problem. Traps are the lifeblood of SNMP, giving your manager the data required to give you a "big picture" understanding of your network-wide status.

But managers don't have to sit around waiting for agents to send a message. Sometimes, they prefer to ask for data proactively. This enables managers to build reports by having all agents send a status report at regular intervals. It also ensures that devices are still active, because you don't otherwise know if a quiet device is offline or simply doesn't have anything to report.

A manager asks an agent for data with a "get" message, the agent will send back a "get-response". The manager might only need that one piece of data, or it can then send a "get-next" message (and then another, and then another) to request a full status update.

Finally, an SNMP manager sometimes has to tell an agent to take action. Some agents have control relay outputs that can be toggled. Others have beacon lights, backup systems, thermostats, and other things that can be changed with a "set" command. A set command targets a specific OID and specifies a desired value. Translated to plain English, a set message might read something like "Set thermostat to 21 degrees Celsius" or "Activate backup generator".

SNMP is based on the manager/agent model
SNMP is based on the manager/agent
model of a network management architecture.

What are some SNMP best practices?

When an agent sends a trap message, it can include OID and a data payload (called "variable bindings") to clarify the event. Quality agents like DPS NetGuardian RTUs send a comprehensive set of plain-English variable bindings within each trap to maintain traditional telemetry event visibility. Well-designed SNMP managers can use the bindings to correlate and manage the events. Managers will also generally display the readable labels to facilitate user understanding and decision making.

Is SNMP byte-oriented or packet-oriented? What's the difference?

This article in our series on the Simple Network Management Protocol (SNMP) examines the communication between managers and agents. Basic serial telemetry protocols, like TBOS, are byte-oriented (a single byte is exchanged to communicate). Expanded serial telemetry protocols, like TABS, are packet-oriented with packets of bytes exchanged to communicate. The packets contain header, data and checksum bytes. This offers vastly more detail without requiring a companion database, but bandwidth requirements are obviously many times higher for packet-oriented protocols. As time marches on, however, bandwidth availability continues to increase rapidly.

SNMP is packet-oriented with the following SNMP v1 packets (Protocol Data Units or PDUs) used to communicate:

  • Get
  • GetNext
  • Set
  • Trap

The manager sends a Get or GetNext to read a variable or variables and the agent's response contains the requested information if managed. The manager sends a Set to change a variable or variables and the agent's response confirms the change if allowed. The agent sends a Trap when a specific event occurs.

The image below shows the packet formats. Each variable binding contains an identifier, a type and a value (if a Set or response). The agent checks each identifier against its MIB to determine whether the object is managed and changeable (if processing a Set). The manager uses its MIB to display the readable name of the variable and sometimes interpret its value.

SNMP Packet Formats
SNMP Packet Formats

Do you have any specific SNMP examples I can review?

Absolutely. Here are two:

  1. As a remote-monitoring-equipment manufacturer, SNMP isn't the only protocol we work with (we have to support lots of legacy and proprietary protocols if that's what our clients need), but it is certainly the most common.

    In our environment, SNMP RTUs are a great example of SNMP agents. These are remote boxes that sit out at remote, unmanned locations and monitor the equipment and conditions there. One NetGuardian 832A, for example, might be monitoring temperature sensors, humidity sensors, doors, motion, water leakage, fuel levels, and power voltages using external sensors. It could also be tracking contact-closure alarms from various equipment like generators, rectifiers, switches, SONET/optical ring gear, UPS batteries, and other important equipment.

    Any deviation from ideal conditions would, in this example, trigger an SNMP trap from the NetGuardian 832A. The beauty of an open protocol like SNMP is that the trap could be directed at any standard SNMP manager from any manufacturer (you could also use the DPS Telecom T/Mon manager, of course). Your SNMP manager could direct a response from the NetGuardian, such as turning on a backup generator to handle a commercial power failure.

  2. Another great example is a power distribution unit (PDU). These are more focused on remote control than remote monitoring. They're basically industrial grade power strips with the ability to toggle power on/off to individual devices. This provides a last-resort remote-reboot capability if you have a server get stuck or something similar go wrong. Some devices just need to be power cycled.

    An SNMP-capable PDU will toggle outputs in response to an SNMP set command from your SNMP manager. This type of device brings remote power control under your SNMP monitoring umbrella. That's significant, because it's silly to have one system for remote monitoring and a completely separate system for remote control. A large SNMP infrastructure in your network allows you to see what's happening AND react from your SNMP management interface.

Download this free PDF Tutorial
tutorial cover
We're here to help.

Ask Us a Question Image

Ask us anything, we're experts!

Our Commitment

"If you decide to work with me, I won't let you fail. If my solution doesn't solve your problems 100%, I don't want you to have it."

Bob Berry, CEO
Our Quality

Average client rating: 4.4 out of 5 stars based on 986 post-purchase surveys

Our HQ

DPS Telecom - Corporate Office:
4955 E. Yale Avenue,
Fresno, CA, United States 93727

USA: (800) 693-0351
International: +1 (559) 454-1600 - Fax: (559) 454-1688
Memberships: Utilities Telecom Council (UTC)