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 TodayLet'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.
"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.
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.
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 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.
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:
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.
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.
SNMP MIB OID Tutorial.Each entry in a MIB has the following properties:
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 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.
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.
