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 TodayIn a typical SNMP network, there are many components that are linked together to give your company complete visibility of all your gear and sites.
In this article, I'll break down the concept of SNMP, the MIB file, and OIDs, so you can take that knowledge with you when you're managing your network to keep everything running smoothly.
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, since it's an open protocol, a very large number of devices support it, enabling them to work together.
SNMP was created in 1988. It came to replace the earlier SGMP (Simple Gateway Management Protocol). At that time, SNMP was just a short-term way to manage computers on the Internet and in private networks.
Nowadays, this protocol is everywhere. You'll find it in office buildings, remote industrial telecom sites, and even home offices.
SNMP architecture is very similar to the internet technology you're using right now to read this article. Your computer - or tablet, or smartphone - sends a standardized request to our web server. Our web server responds by sending 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 terms, an "agent" is the remote device out in the network. What exactly the agents are will depend on the kind of managed system you have. Are you in a small office, a national telephone company, or a power utility? Printers, managed switches, alarm remotes, generators, and servers are some example of agents.
From a network management system point of view, a standard SNMP agent is a network device joined to the gear being monitored - or to environmental levels via a sensor. For instance, in a remote site, you might be monitoring the temperature.
If the temperature gets too high or too low, it could damage your gear. The temperature sensor is joined to a remote terminal unit (RTU), which acts as the SNMP agent in the system.
Your agents report problems to and receive commands from a central "SNMP manager." The job of the manager is to receive the values from the agent and display them in meaningful terms to the appropriate person for corrective action.
There are many ways that the agent and manager can communicate. SNMP message types include:
TRAP messages are sent by the agent to the manager, and indicate a change-of-state (COS) alarm. An RTU like the NetGuardian sends traps when the equipment and sensors that they are monitoring report a problem.
Traps are the essence of SNMP, since they provide your manager with the info required to give you an overall understanding of your network status.
Managers don't have to wait for agents to send a message, though. They can proactively ask for information.
This allows your manager to build reports by having all agents send a status update at regular, programmed intervals. It also ensures that devices are still active. Without this feature, it would be hard for you to know if a quiet device is offline or simply doesn't have anything to report right now.
GET, GET-NEXT and GET-RESPONSE are the three types of GET alarms. Each message is used in sequence.
When a manager asks an agent for information with a GET message, the agent replies with a GET-RESPONSE. The manager might only need that once piece of data, or it can then send a GET-NEXT message (repeated as many times as necessary) to ask for a full status update.
An SNMP manager also may order an agent to take action. Some agents have control relay outputs that can be switched. Others have beacon lights, backup systems, thermostats, and other things that can be switched on/off via a "SET" command.
This command, for example, could tell the agent to open a door, set the temperature, or toggle some other controlled input. A SET message might conceptually be something like "Set thermostat to 21 degrees Celsius" or "Activate backup generator."
If you want to set up a new agent in your network, all you need to do is follow a couple of steps:
This will change from device to device, of course, but there's always some way to tell your new agent where to find your master. It's even better if you have a master that can perform auto-discovery and automatically configure new agents. That way, you won't have to configure each new device individually.
Have you ever connected a printer to your computer? What about a camera or other accessory?
If so, you know about installing drivers. A driver is a file that tells your computer how to communicate with the other device. It's a "codebook" or "dictionary", much like you might use if you needed to interact in a foreign language.
In SNMP, although the basic protocol is always the same, every agent has different things that it can report. Generators, for example, report fuel levels, while printers report toner and paper levels. This means that the Management Information Base (MIB) is 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'll compile it into your manager as part of setting up the new agent.
An SNMP MIB is a key component of SNMP. More specifically, a MIB describes SNMP network elements - any device in the network - as a list of data objects.
The MIB is loaded ("compiled") into the SNMP manager and contains knowledge relevant to network management. Both the SNMP manager and agent utilize this information base. The manager uses the MIB as a "reference" to know traps, or messages, sent from agents within the network. The agent is designed to match what's in its own MIB, making communication possible.
In short, your SNMP manager needs the MIB in order to process messages from your devices. The MIB is also your best guide to the real capabilities of an SNMP device. You need to be able to read the MIB so that you can have a good idea of what assets you do have.
Keep in mind that MIB files are created and supplied by equipment vendors. These files are equipment specific, so it's important to make sure that you have the correct MIB for you gear type, model, and version number. This information should be provided for free by your vendor/manufacturer.
The MIB is essentially a device-specific dictionary of the SNMP language. Every object referred to in an SNMP message must be listed in the MIB.
The SNMP MIB can define large-scale elements (like the name/classification of an entire device). It also can define very specific elements, like a particular trap message generated by a certain alarm point on an RTU.
Individual objects in the MIB have an object identifier (OID), which the manager uses to determine the values from those single devices. In simple terms, an OID is an address used to uniquely identify managed devices and their statuses.
The OIDs describe SNMP network elements by using a number string. They look like extra-long IP addresses, like this: 1.3.6.1.4.1.2682.1.2.102
Just like an IP address, each additional number in the OID adds detail.
The first several numbers are always the same for SNMP devices. In the example, "1.3.6.1.4.1..." means "enterprise SNMP equipment". That's going to be the same for every agent you use.
The last few numbers mean "DPS Telecom" (this agent's manufacturer), "Alarm monitoring", "RTU", and "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 about whatever it was you decided to plug into Alarm Point 2 during installation.
SNMP messages utilize OIDs to transmit information such as point status or alarm descriptions. When the SNMP manager requests the value of any object, it creates a message using the OID. The MIB allocates readable labels to each object identifier, as well as other parameters relevant to the individual object. This MIB allows for human interpretation of created SNMP messages.
Each entry in a MIB has the following properties:
Individual vendors create their own MIBs that only include the OIDs associated specifically with their device. They commonly reference other industry-standard MIBs (called "RFC MIBs"). This structure is what makes an SNMP MIB object-oriented, a maximally efficient way of storing information.
Here's an example of the first lines of the standard DPS Telecom MIB file:
DPS-MIB-V38 DEFINITIONS ::= BEGIN
IMPORTS
DisplayString
FROM RFC1213-MIB
OBJECT-TYPE
FROM RFC-1212
enterprises
FROM RFC1155-SMI;
dpsInc OBJECT IDENTIFIER ::= {enterprises 2682}
dpsAlarmControl OBJECT IDENTIFIER ::= {dpsInc 1}
tmonXM OBJECT IDENTIFIER ::= {dpsAlarmControl 1}
tmonIdent OBJECT IDENTIFIER ::= {tmonXM 1}
tmonIdentManufacturer OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-only
STATUS mandatory
DESCRIPTION "The TMON/XM Unit manufacturer."
::= {tmonIdent 1}
tmonIdentModel OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-only
STATUS mandatory
DESCRIPTION "The TMON/XM model designation."
::= {tmonIdent 2}
Are you wondering what language that is? All MIBs are written in Abstract Syntax Notation 1, or simply ASN.1. This standard notation is managed by the ISO (International Organization for Standardization) and is used in everything from the World Wide Web to aviation control systems.
The descriptions and specifications for ASN.1 are incredibly broad. Standard references to ASN.1 run up to 600 pages. However, there are some things that you should know about ASN.1:
Don't worry - you don't have to master MIB notation in order to get useful information from the MIB. One of the best tactics for addressing MIB problems is to simply read through the file.
Since MIB files are composed of ASCII text, they can be viewed using any word processor or text editor, even Microsoft Notepad.
Some manufactures provide precompiled MIBs in binary format, but those aren't readable. You want the raw ASCII version of the MIB file. Some manufacturers will frustrate you, though, as they like to keep tight controls on their MIB to force you to purchase their proprietary network fault management suite despite saying they "support SNMP" on the product brochure.
When reading the MIB, you don't need to read every single line of text. However, it's important for you to know some of the concepts embedded in the MIB. Including:
Note that RFC MIBs are open-source, so they can be found and downloaded with a simple web search for "RFC MIBs."
Even if you have a next-generation SNMP manager, such as the T/Mon LNX (which partially obsoletes MIB files with pre-configuration of common devices), being able to confidently read and understand MIB file contents can provide insight into equipment design and capabilities.
If you are wondering how to create SNMP MIB files, know that MIB files aren't really designed to be created or edited by the end-user.
If you want, you could edit the text descriptions of managed objects to be more user-friendly, but it's better to simply use your SNMP manager's presentation software to create a useful display.
When an agent sends a trap message, it can include OID and a data payload (variable bindings) to clarify the event.
Quality agents, such as NetGuardians RTUs, send a comprehensive set of plain-English variable bindings within each trap to maintain traditional telemetry event visibility. Managers will also generally display readable labels to facilitate user understanding and decision making.
As a full-service manufacturer, all of us here at DPS are used to developing solutions for all types of scenarios and problems. This includes clients that require specific MIBs for their applications.
For example, we had a client that needed to send certain SET commands to remote units at some microwave sites. The units that he had were not capable of sending those commands.
Our solution involved custom new OIDs that were configured with variable bindings to accept SNMP traps. This allowed monitoring and control of the remote sites with the ability to work with up to 40 discrete relays in the system. This solution saved them money and downtime - and increased the use of existing equipment for our client.
I, and everyone else here at DPS, would love to help you with your SNMP project - whatever it might be. Even if you'd just like to have a 10-minute phone call to get your bearings, you can call us any time.
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...
