Get a Live Demo

SNMP (Simple Network Management Protocol) was originally created in 1988 as a short-term solution to manage growing networks. It has grown beyond its roots to play an important role in remote alarm monitoring of telecommunications networks. SNMP can do a lot to make your network alarm monitoring more cost-effective and your network more reliable - if you clearly identify your network monitoring goals and have the right tools to achieve them.

SNMP messages are, most commonly, created by an SNMP agent (some kind of gear at the site) and received by a central SNMP manager (a software program, ideally running on its own dedicated hardware platform). Sometimes, an SNMP manager will send a message to an SNMP agent. This message might ask, "What is the current temperature inside your site enclosure?", or any number of other important questions.

SNMP is an internet protocol defined by the Internet Engineering Task Force (IETF). SNMP has become one of the most commonly used protocols in monitoring applications. Its main function is to monitor network devices for alarms that require corrective action and/or human intervention.

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

What is a MIB file?

The structure of MIB (Management Information Base) 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 SNMP manager. But there are tens of thousands of different SNMP products, and your manager doesn't natively understand each one.

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 MIB lists the unique object identifier (OID) of each managed element in an SNMP network. Your SNMP manager can't monitor your devices unless it has compiled their MIB files. The MIB is also a guide to the capabilities of your SNMP devices. For example, if your device's MIB lists OIDs for Traps but not for GetResponse messages, you know it will report alarms, but will not respond to alarm polls. Learning to read MIBs is difficult, but it's worth the trouble.

When an SNMP manager wants to know the value of an object/characteristic, such as the state of an alarm point, the system name, or the element uptime, it will assemble a GET packet that includes the OID for each object/characteristic of interest.

The element receives the request and looks up each OID in its codebook (MIB). If the OID is found (the object is managed by the element), a response packet is assembled and sent with the current value of the object/characteristic included. If the OID is not found, a special error response is sent that identifies the unmanaged object.

When an element sends a Trap packet, it can include OID and value information (bindings) to clarify the event. DPS remote units send a comprehensive set of bindings with each Trap to maintain traditional telemetry event visibility. Well-designed SNMP managers can use the bindings to correlate and manage the events. SNMP managers will also generally display readable labels to facilitate user understanding and decision-making.

Each SNMP element manages specific objects with each object having specific characteristics. Each object/characteristic has a unique object identifier (OID) consisting of numbers separated by decimal points (e.g., 1.3.6.1.4.1.2682.1).

The MIB associates each OID with a readable label (e.g., dpsRTUAState) and various other parameters related to the object. The MIB then serves as a data dictionary or codebook that is used to assemble and interpret SNMP messages.

How do I look at a MIB?

One of the best tactics for addressing MIB problems is to simply read through the file. As a MIB (SNMP) file is just ASCII text, network administrators can view it in any word processor or text editor (even Notepad). Some manufacturers provide grouped MIBs in binary format, but those aren't readable. In order to be able to read the MIB file, you need the raw ASCII version of it.

What You Need to Know About When Reading SNMP MIB

Since MIB files are composed of ASCII text, they can be viewed using any word processor or text editor, even Microsoft Notepad.

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

Why do I need a MIB File?

The primary reason for the MIB is to translate numerical strings into readable text for humans. Your active SNMP manager needs the MIB in order to process messages (SNMP traps) from your managed objects.

The MIB is also your best guide to the real capabilities of an SNMP network device. You need to be able to read the SNMP MIB format so that you can have a good idea of what assets you do have. You won't be able to tell you what kind of Traps you can get from equipment by simply looking at its physical components.

For example, let's say you have an SNMP RTU (Remote Telemetry Unit) with a built-in temperature sensor. You think you'll get temperature alarms from this device - but you never do, no matter how hot it gets.

Why not? You read the RTU's MIB file and find out that it only lists discrete points, and not the temperature sensor. Since the sensor isn't described in the MIB, the RTU can't send Traps with temperature data.

Keep in mind that equipment vendors create and supply you with that private MIBs. This means that 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.

When you're evaluating new SNMP equipment, examine its MIB file carefully before you purchase. It might be strange that a manufacturer would add a component to a device and not describe it in the MIB. But the fact is, many devices have dubious MIBs that don't fully support all their functions.

What is an OID?

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.

You can think of an OID as an address used in SNMP messages to identify devices and their statuses - acting both as the "What is it?" as well as the "Where did it come from?" Want to know the temperature reading coming from a sensor at your mountaintop remote facility? There's an OID for that.

SNMP Object Identifiers (OIDs) point to network objects stored in a database called the Management Information Base, often referred to as the "MIB". A MIB holds the structure of the network alarms being monitored (like a map of the "city"), and it uses the OIDs to keep track of the individual components (like the address to a house or other location).

In this example, an SNMP OID is like the address the fire truck would drive to if the fire alarm sounded. What if a fire broke out at your house, and you called the fire department with GPS coordinates (representing the Object ID or OID)? The fire department would have to look that up in its MIB to determine the correct street address.

In telecom, SNMP OIDs describe specific locations in the network. The OID allows the MIB to translate the location of the event into a status description for your network technicians.

How do you read an OID?

While it may look daunting, the OID follows a simple structure, with each "dot" segment identifying a part of a network element. If you take a home address as an example, the beginning of the Object Identifier tells us the hemisphere of the world, the country, state, city, zip code, street address and eventually leads us to our driveway.

With this structure, very specific elements can be identified and located even in very complex networks.

An SNMP Manager (ex. T/Mon) translates these SNMP OIDs into a value that is then assigned readable labels in the Management Information Base (MIB). This allows the SNMP manager to produce messages that can be read by people.

When the SNMP Manager, a T/Mon, in this case, requests the value ("state") of any object it is monitoring, it sends a message with that object's OID to its Management Information Base. The MIB will decode the address and attach a text description to it. This allows the SNMP Manager to present the value of the alarm condition with the identifying description of the labeled alarm.

So for example, let's say the SNMP Manager wants to know if there is a car in the driveway of your house (a "yes or no" question, often referred to as a discrete alarm in the alarm monitoring world). The SNMP Manager would look up the corresponding reference in the MIB in order to "poll" (ask) if there is a car in the driveway at 123 Main St.

The MIB references 123 Main St. and translates it into the OID of your driveway. In our example OID, it would be 123 Main St = 1.3.6.1.4.1.2681.1.4.5.1.1.99.1.1.6. The driveway (or alarm point we want to monitor) would be represented by the "102" portion of the address. The "value" reported is the current state of the driveway 102: occupied by a car or not.

The sensor at the driveway reports back: Nope. Nobody's in the driveway.

How to Create SNMP MIB File?

Normally it's not necessary to create an SNMP MIB file. MIB files are not intended to be 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.

  SNMP MIB Example
 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.""
 

Deconstructing the MIB

Wow! What language is that?

You can note from the previous MIB sample that MIBs are written in ASN.1, or Abstract Syntax Notation 1. ASN.1 is a standard notation maintained by the ISO (International Organization for Standardization) and used in everything from the World Wide Web to aviation control systems. A full description of ASN.1 is completely beyond the scope of this page - standard references to ASN.1 run up to 600 pages. For our purposes, there are only a few things to understand about ASN.1:

It's human-readable.
It's specifically designed for communication between dissimilar computer systems, so it's the same for every machine.
It's extensible, so it can be used for describing almost anything.
Once a term is defined in ASN.1, it can be used as a building block for making other terms.

How the MIB is Structured?

Each entry in a MIB has the following properties:

Syntax

Syntax defines the abstract data MIB 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.

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 data structure is what makes an SNMP MIB object-oriented, a maximally efficient way of storing information.

You can download multiple MIB files at once. For your convenience, MIB files from several popular vendors have been bundled together into a single, downloadable zip file. This makes it easier to access and use the resources you need without the hassle of downloading each file individually. Using this zip file, you can efficiently manage and implement MIB files from various well-known brands in one go.

Demystifying the MIB by Marshall DenHartog

Understanding MIBs and how they describe SNMP telemetry messaging is critical to maximizing your alarm system's capabilities.

One customer recently asked us about monitoring a new device, which was not in the library of SNMP MIBs for their system. They asked, "can I reprogram the T/MonLNX to include this new device?" Fortunately, the TMonLNX can integrate SNMP telemetry without needing to load or compile a MIB file or files. For those with T/MonLNX monitoring systems, the MIB files can be a helpful reference when deciding how to monitor a new element in your network.

For those with older SNMP Managers that require MIBs to be loaded in order to integrate SNMP messages from new network elements, MIB files are absolutely critical to understand. In some cases, you may even decide to edit them to improve the messages for your SNMP Manager presentation. This report will help you understand why you absolutely need to be able to work with MIB files when you are using an older SNMP Manager.

In any case, you will learn the essentials of SNMP MIB files and will probably agree that this white paper is a must-read for anyone who works with SNMP.

Learn the SNMP Management Information Base:

Understanding the purpose and function of the MIB
How to read and make sense of a MIB.
Why multiple MIB files are usually required.
How a MIB can help to evaluate SNMP equipment.
How equipment telemetry messaging is presented in MIB file notation.

Download White Paper

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.

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

Hours:	Monday - Friday 7:00 a.m. - 6:00 p.m. PST
Support:	(559) 454-1600 / support@dpstele.com
Sales:	Domestic: (800) 693-0351
	International: 1+ (559) 454-1600
Social:	LinkedIn Twitter YouTube