4129

Get a Live Demo

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

Get the SNMP Fast Track GuideBook

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.

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 Tutorial: An Introduction of SNMP for Beginners

Let's start by learning what SNMP is.

The Simple Network Management Protocol (SNMP) 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 network devices support SNMP, enabling them to work together.

Because of the large amount of support, the question isn't "do I need SNMP", but "how do I support it? And how do I get SNMP training?"

How long has it been around?

SNMP was created in 1988 and 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 "Gateway").

How do the pieces fit together?

SNMP architecture is, in principle, 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. 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 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, routers, switches, servers, alarm remotes, generators, and lots of other things. These agents report problems and receive commands from a central master station also called 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 monitoring system, there are a few simple setup steps:

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

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 your 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 Management Information Base (MIB) 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 may 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. "1.3.6.1.4.1.2682.1.2.102").

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

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, "1.3.6.1.4.1..." means only "enterprise SNMP equipment". 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 managing device. If your manager received an SNMP message with that OID, it would alert your network administrators 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. OIDs are generally contained in a MIB file.

Learn more from our Library

  • Over 50 white papers written by Industry Veterans.
  • Provides tips for an effective network management system as well as how to integrate legacy equipment.
View Our Library »

What are SNMP Message Types?

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.

An RTU like a NetGuardian sends traps when the equipment and sensors it's monitoring and managing 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".

What are some SNMP best practices?

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

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 readable labels to facilitate user understanding and decision making.

Another best practice is to deploy the third version of SNMP. SNMPv3 brings many more security features than the last versions (these would depend mostly on the community string capability). With SNMPv3, your messages will totally encrypted.

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 a 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.

    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.