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.
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 TodayMIB is a Management Information Base, a key component of SNMP (Simple Network Management Protocol). More specifically, a MIB is a group of managed objects within a network. This local database at is compiled to the SNMP manager, and contains knowledge relevant to network management. Both the SNMP manager and agent utilize this database. The manager uses the MIB as a "reference" to know traps, or messages, sent from agents within the network.
"SNMP" stands for Simple Network Management Protocol.
SNMP monitoring is distinct from other forms of monitoring because it involves the use of SNMP protocol.
SNMP messages are, most commonly, created by an SNMP agent (some kind of gear at the site) and received by a central 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). It 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.
"MIB" stands for Management Information Base.
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.
A MIB contains definitions and info about the properties of managed resources and the services that the agents (devices) support. The features of resources, as defined in a MIB, are called "managed objects" or "management variables".
A management station gets and sets objects in the MIB, and an agent notifies the management station of events using messages called (somewhat oddly) "traps". All message exchanges between the management station and its agents take place using SNMP. The MIB at the management station contains network management info taken from the MIBs of all the managed parts in the network.
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.
The manufacturer of your device will supply you with a MIB file.
You'll load the MIB into your SNMP manager.
Your SNMP manager will use the MIB to interpret the incoming messages from your new device.
When you buy a 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 devices, 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 (If you've ever installed a device driver on a PC, you understand this concept). Without the MIB for message translation, communication simply won't happen.
A MIB is organized into a tree. Individual objects in the MIB have an OID, which the manager uses to determine the values from those single devices. These objects can be specific alarm points, with one representing an alarm, and another representing a clear.
SNMP messages utilize these variables to convey information such as point status or alarm descriptions. When the SNMP manager requests the value of any object, it assembles a message using the OID, which is sent to the MIB for decoding. The MIB assigns readable labels to each object identifier, as well as other parameters relevant to the individual object. This allows the MIB to interpret and assemble SNMP messages.
"OID" stands for Object IDentifier.
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.
The MIB is essentially a codebook that translates these numerical strings into human-readable text. Elements defined in the SNMP MIB can be very broad like all objects created by private businesses, or very specific, like a particular trap message generated by a certain alarm point on an RTU.
While each OID is unique, the first several pieces of each OID are almost always the same. These upper location levels are defined by a series of standard reference within the MIB. These series are called RFCs, or Requests for Comments. The RFCs that define SNMP OIDs are part of a larger group of RFC documents that define the Internet as a whole. Individual vendors create their own MIBs that only include the OIDs associated specifically with their device. This structure is what makes an SNMP MIB object-oriented, a maximally efficient way of storing information.
If an object does not have an identifier within an SNMP MIB, it does not exist to your SNMP manager. For example, if an SNMP RTU has a built-in component to monitor temperature, but the temp sensor is not listed in the MIB file, the RTU will be unable to send and receive traps with temperature data.
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, you 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. You want the raw ASCII version of the MIB (SNMP) file.
You can note from the previous MIB sample that MIBs are written in ASN.1, or AbstractSyntax 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.
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.
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.
MIB files are composed of ASCII text, and thus can be viewed using any word processor or text editor. When reading the MIB, it is not needed to read every single line of text. However, it is important for every telemetry manager to know some of the concepts embedded in the MIB. This includes:
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.
RFC MIBs are open-source, and can be found and downloaded with a simple web search for "RFC MIBs".
