2891

Simple Network Management Protocol: Basics

What is SNMP?

Simple Network Management Protocol (SNMP) is a very popular computer protocol used for remotely monitoring and controlling equipment. All sorts of network devices, from industrial telecommunications gear down to simple network switches and printers, can use this protocol to report their current status or receive commands. SNMP is almost always sent over standard IP.

How will I know when an SNMP-equipped device has reported a problem?

SNMP is built on the "manager-agent" architecture, which simply means that any SNMP device is either an agent or a manager. Any managed device or managed system that reports its status (like a switch or printer) is an agent. All of your agents must be configured to report to an SNMP manager, which collects and present data from SNMP agents.

Precisely how you are notified depends on your specific manager and configuration. You might want a simple list showing all messages you've received. For more complex network traffic with a lot of messages, you'll probably benefit from a manager that filters out unimportant messages so you can focus on the few that really matter. It's also possible to receive email, text message, or phone notifications of certain messages.

What is an SNMP trap?

Even though the name is a bit confusing, a "trap" is really just the most popular type of SNMP message. An agent sends a trap message to your manager to indicate a particular problem or status.

Other than traps, what are the other types of SNMP messages?

Traps, while most common, are fairly limited. They're one-way messages from agents to managers. The manager does not respond to traps in any way, so it's possible for the occasional trap to go missing. Other message types, mostly generated by the manager, solve this problem and allow for remote controlling of agents.

SNMP Messages
T/MON sends SET to AC Unit
In this diagram, a manager (T/Mon) sends a SET to activate a backup A/C unit.

If a manager wants to gather the current status of a device, it doesn't have to wait for an incoming trap (which may never come if the device has completely failed). SNMP managers can send GET requests to "get" a value from a device.

Depending on the data needed, your manager may send a GET that demands the device's on-board temperature reading, whether it has any alarm conditions to report, or just about any other information. Upon receiving a GET, an agent response with a GET response that contains the requested data.

Your manager has an overarching "bird's eye" view of your network, so it's a great place for automated decision making.

Imagine that your manager is made aware (via traps or GET responses) that several devices in one server room are overheating. Your manager can be configured to make an immediate, automated decision to activate your backup air-conditioning (HVAC) system. To do this, it must send a SET message to "set" a value on the target device (the backup HVAC, in this case). A SET-response (see the pattern?) is sent by the agent to confirm that it has received and followed the SET instructions.

There are a few other SNMP message types, but you understand all the basic concepts if you understand traps, GETs, and SETs.

What is MIB?

The structure of Management Information Base (MIB) is a formatted text file that lists all of the data objects used by a particular piece of equipment. When you buy a monitor device that uses SNMP (for example, a managed switch), you'll tell it to send messages to your central manager. But there are tens of thousands of different SNMP products, and your manager doesn't natively understand each one.

That's where the MIB comes in. The manufacturer of your device will supply you with a MIB file (usually a download from their website) that you'll load ("compile") into your SNMP manager. Compiling converts the MIB from its raw ASCII format into a binary format the SNMP manager can use. If you've ever installed a device driver on a PC, you understand this concept.

Without the MIB for SNMP message translation, communication simply won't happen.

In other words, the MIB is a text file that describes SNMP network elements (any device in the network) as a list of data objects. It is essentially a dictionary of the SNMP language, where every object referred to in an SNMP message must be listed in the MIB. So, as far as many SNMP managers and agents are concerned, if a component of a network device isn't described in the MIB, it doesn't exist.

The elements defined in the MIB syntax can be extremely broad (for example, all objects created by private businesses) or they can be extremely specific (like a particular Trap message generated by a specific alarm point on an RTU.) Each element in the MIB is given an object identifier, or OID. An OID is a number that uniquely identifies an element in the SNMP universe. Each OID is associated with a human-readable text label.

The MIB provides a text label called for each OID. Your SNMP manager uses the MIB as a codebook for translating the OID numbers into a human-readable display.

SNMPv1, SNMPv2c, and SNMPv3

SNMPv1, SNMPv2c and SNMPv3 are the three major SNMP versions.

SNMPv1

SNMPv1 was the first version of SNMP. Although it accomplished its goal of being an open, standard protocol, it was found to be lacking in key areas for certain applications. Later versions have addressed many of these problems. Smaller RTUs commonly support SNMPv1.

SNMPv2c

SNMPv2c is a sub-version of SNMPv2. Its key advantage over previous versions is the Inform command. Unlike Traps, which are simply received by a manager, Informs are positively acknowledged with a response message. If a manager does not reply to an Inform, the SNMP agent will resend the Inform.

SNMPv3

SNMPv3 is the newest version of SNMP. Its primary feature is enhanced security.

The "EngineID" Identifier in SNMPv3 uniquely identifies each SNMP entity. Conflicts can occur if two SNMP entities have duplicate EngineID's. The EngineID is used to generate the key for authenticated messages.

SNMPv3 security comes primarily in 2 forms:

SNMP uses which port by default?

SNMP uses both port 161 and port 162 for sending commands and messages.

The manager at the top of the system sends commands down to a network device using destination port 161.

When it wants to report something or respond to a command, an agent will send a message to port 162 on the manager.

SNMP uses UDP by Default, but TCP is Possible There are two types of protocols used in the Transport Layer (a sub-division of the IP layer); Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). SNMP can be implemented over both protocols via LAN.

Transmission Control Protocol (TCP)

TCP is connection-based, meaning that one program is connected to another program and they send messages across the internet to each other. TCP is relatively heavy, meaning it requires three packets to set up a connection before user data can be sent.

User Datagram Protocol (UDP)

While TCP can be used for SNMP, it was originally designed for UDP transport only. While UDP may not have all the functionality of TCP, this actually makes it better for some applications. UDP is faster than TCP because it does not order packets (which can be done by the application layer), and it is a connectionless protocol. UDP is actually better suited for repetitive, low-priority functions like alarm monitoring.

As discussed above, SNMP uses UDP ports 161 and 162 by default.

Where can I go for more information?

Obviously, this hasn't been an exhaustive discussion of SNMP. I've tried to give you a reasonable introduction to the protocol without bombarding you with techno-jargon. There's a lot more information available right here on the DPS website. I recommend:


Get a Custom Application Diagram of Your Perfect-Fit Monitoring System

There is no other network on the planet that is exactly like yours. For that reason, you need to build a monitoring system that's the right fit for you.

"Buying more than you need" and "buying less than you need" are real risks. You also have to think about training, tech support, and upgrade availability.

Send me a quick online message about what you're trying to accomplish. I'll work with you to build a custom PDF application diagram that's a perfect fit for your network.


Make an Informed Decision


Your network isn't off-the-shelf.

Your monitoring system shouldn't be, either.

Customized monitoring application drawing

We'll walk you through this with a customized monitoring diagram.

Just tell us what you're trying to accomplish with remote monitoring.

Get a Custom Diagram