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.


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

What Is The SNMP MIB Code?


December 23, 2021


In a typical SNMP network, there are many components that are linked together to give your company complete visibility of all your gear and sites.

Skip this article and browse our SNMP devices.

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.

First Of All: What Is SNMP?

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.

How Long Has SNMP Been Around?

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.

The "Manager-Agent Model"

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.

SNMP transport diagram
This diagram shows how SNMP operates through the manager-agent model.

Which are the Types of Manager-Agent Alarms?

There are many ways that the agent and manager can communicate. SNMP message types include:

  • TRAP messages

    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.

  • GET, GET-NEXT, and GET-RESPONSE messages

    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.

  • SET messages

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

How Can I Set Up Communication Between My Manager and Agents?

If you want to set up a new agent in your network, all you need to do is follow a couple of steps:

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

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.

2. Compile the agent's MIB into your manager

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.

Why Do I Need a SNMP MIB File?

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 SNMP MIB is the "Codebook" for SNMP Managers

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.

MIB Manager Agent
The manager uses MIB files from each agent to decode the OIDs (strings of numbers) for all messages from that agent. This translates them into meaningful information.

How the MIB Uses OIDs to Communicate with Individual Objects

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:

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, "" 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.

The Structure of Management Information Base

Each entry in a MIB has the following properties:

  • Syntax
    Syntax defines the abstract data structure matching to the object type. It can take the form of binary numbers for discrete inputs - ON/OFF applications - or integers for analog inputs - which are more detailed than discretes.
  • Access
    Access defines whether the object value can be retrieved and modified (read-write) or only retrieved (read-only). When an RTU notifies the manager that there is an alarm, it's read only. Read-write describes values that also may be changed, such as an RTU relay output can remotely unlock a door.
  • Description
    The description contains a textual definition of the object type. The definition provides all semantic definitions needed for interpretation; it typically contains information that would be communicated in any commentary descriptions associated with the object. This is similar to the DNS process converting IP addresses (unreadable numbers) to domain names (ex. www.theprotocol.com).

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.

What Does a MIB Look Like?

Here's an example of the first lines of the standard DPS Telecom MIB file:

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:

  • It's human-readable
    Yes, it's human-readable, but it's not necessarily easy to understand without a basic orientation to its format. You can view and even edit ASN.1 notation with basic text editors.
  • It's designed for communication between diverse computer systems
    This means that the ASN.1 is the same for every machine. Not every machine will know what do with it, though, but it'll at least recognize this particular notation.
  • It's extensible
    It can be used to describe almost anything. Once a term is defined in ASN.1, it can be used as a foundation for making other terms. This can sometimes involve confusing references, but think of it as a puzzle. With a little understanding and perseverance, you can usually put all the pieces together.
  • Ultimately, it's worth learning
    Wouldn't you be more confident integrating SNMP telemetry with a basic understanding of ASN.1 in your skill set? As more gear is being designed with some kind of SNMP capability, being comfortable with the related MIB files has real value.
SNMP Diagram
When it comes to transitioning to SNMP, the T/Mon can be incredibly useful for you. It's able to interpret and process about 25 legacy and single manufacturer protocols. This multi-protocol interoperability gives you tremendous transitional flexibility at a pace controlled by you.

What You Need to Know about When Reading SNMP MIB

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:

  • What characteristics of the device can be controlled remotely using the SNMP manager
  • What event reports the device can send to the SNMP manager
  • What information the SNMP manager can request from the device, and what other RFC MIBs you need to support a device

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.

NetGuardian 832A G5
The NetGuardian 832A will send traps to your manager when one of its 32 discrete alarm inputs is triggered by a contact closure output from one of your devices. It can also send SNMP traps based on the current status of its eight analog current or voltage inputs. The NetGuardian 832A will inform you about its own internal alarms as well.

Do I Need to Edit the MIB?

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.

What are Some SNMP Best Practices?

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.

Get a Perfect-Fit Solution for your Problem

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.