8380

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.

1-800-693-0351

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

How to Read SNMP MIB Structure

Let's start by refreshing how SNMP works.

"SNMP" stands for Simple Network Management Protocol.

SNMP network 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 managed device 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 are MIBs?

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

When are MIBs SNMP-Compliant?

MIBs play an important role in network management. A MIB will be SNMP-compliant if it has the following:

  1. Syntax Adherence: SNMP MIBs must follow the syntax defined by the ASN.1 (Abstract Syntax Notation One) standard, a notation used to describe data structures. Compliance with this syntax makes sure that SNMP managers and agents can understand the MIB structure.
  2. Object Identifiers (OIDs): Every MIB variable is assigned a unique OID, organized hierarchically. SNMP-compliant MIBs must use these standardized OIDs to maintain interoperability, allowing SNMP tools to identify each data point uniquely.
  3. MIB Modules: SNMP-compliant MIBs are structured in modules that define specific groups of related OIDs. For example, NetGuardian RTUs support SNMP MIBs and modules for discrete alarms, analog inputs, and control relays​​. Each MIB module must define OIDs according to standard SNMP management objects.
  4. Supported SNMP Versions: SNMP-compliant MIBs should support the SNMP version in use (e.g., SNMPv1, v2c, or v3). Compliance for SNMPv3, for example, requires support for security features like authentication and encryption. SNMPv3 proxy devices allow older MIBs to be proxied securely, enabling compliance with SNMPv3 without replacing legacy systems​.
  5. Defined Access and Operations: An SNMP-compliant MIB specifies how objects can be accessed (read-only, read-write, etc.) and what operations are supported (e.g., GET, SET, TRAP). MIBs must clearly define access types to be compatible with SNMP managers.

MIB compliance protects SNMP managers' ability to efficiently retrieve and act on network data, facilitating integration into broader monitoring and control systems.

How do I look at a MIB format?

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.

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.

Manager Agent SNMP MIB

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

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

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.

What terms are defined in the MIB?

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.) When diving into a MIB (Management Information Base) file, an IT engineer should become familiar with a few essential terms to decipher the information effectively:

  1. RFC MIB: An RFC MIB (Request for Comments Management Information Base) serves as a foundational reference. It details the nodes present at the higher levels of the Object Identifier (OID) tree. These standard files are vital because equipment vendors leverage them to avoid redefining the entire OID structure from scratch. Instead, they incorporate existing terms using the "IMPORTS" statement at the beginning of their device-specific files. This practice ensures compatibility and streamlines the implementation process.
  2. TRAP-TYPE: The TRAP-TYPE label is crucial for identifying notifications or messages from managed devices. These traps serve as alerts for network administrators, highlighting events or changes in the device status that may require attention. Understanding TRAP-TYPE terms allows IT engineers to efficiently interpret alerts and take the necessary actions.
  3. OBJECT-TYPE: An OBJECT-TYPE is essentially a data container designated for a specific managed device. It defines the data structure, including syntax and status, which makes retrieving and managing device data more straightforward. By understanding OBJECT-TYPEs, engineers can better manage network configurations and monitor performance.

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.

SNMP MIB OID Tutorial.

Understanding Object Identifiers (OIDs) in MIB Files

The significance of OIDs extends beyond identification in the realm of network management. Essentially, these object identifiers serve as the backbone of communication within Simple Network Management Protocol (SNMP) systems. Here's why:

  • Unique Identification: OIDs uniquely identify each data object within the MIB, ensuring precise tracking and management across a network's devices. This is crucial for IT teams to differentiate between various elements inside complex setups.
  • Data Retrieval: OIDs enable the retrieval of critical information from managed devices, such as device configuration settings, network traffic statistics, and port statuses. This information varies based on the equipment in use, providing tailored insights for effective management.
  • Hierarchical Organization: The entries within MIB files are organized hierarchically, allowing for structured management of network data. This organization aids in navigating extensive databases and efficiently accessing required information.
  • Facilitating Communication: OIDs play a pivotal role in translating device messages. They convert numerical data into human-readable formats, allowing seamless communication between the managing entity and network devices. Without OIDs, these messages would remain indecipherable strings of numbers.

Practical Applications

For example, when monitoring a switch, OIDs help track data like incoming and outgoing traffic, busy port numbers, and packet loss rates. This ensures that network administrators can maintain optimal performance and quickly address issues as they arise.

By integrating standard and device-specific MIB files, network management systems can decode messages accurately, translating them into actionable insights for IT teams. In this way, OIDs are indispensable for maintaining the efficiency and reliability of network operations.

The MIB File Structure

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.