MIB and OID Explained

What is MIB and OID Explained — definition

An SNMP OID (object identifier) is the unique numeric address of a single manageable value — something like 1.3.6.1.2.1.25.1.1.0, which points at a device's uptime. A MIB (Management Information Base) is the document that defines what that value means, its data type, and where it sits. So the short answer to what is MIB SNMP: the MIB is the dictionary, the OID is the word's address in it. One tells you the vocabulary; the other tells you exactly where to find a term.

Put them together and you get the defining feature of SNMP — a single, global namespace for machine data. Every value any agent can expose has one canonical object identifier, and that identifier means the same thing on a printer in Berlin as on a database server in São Paulo. This page explains the OID tree and the MIBs that describe it. For the protocol itself, see what is SNMP; for who talks to whom, see SNMP architecture.

Here's the analogy that tends to stick. Think of the OID tree as a postal system for numbers. The MIB is the address book that says who lives where — "the object at 1.3.6.1.2.1.25.1.1.0 is called uptime, it's a TimeTicks value, and here's what it means." The OID is the address itself. You don't need the address book to deliver mail to an address, but without it the address is just digits. That's the split every SNMP tool lives with: it can always route by number, and it only shows friendly names when the relevant MIB is loaded.

How it works

OIDs are hierarchical, and that's the whole trick. The OID tree starts at an unnamed root and branches downward, each node getting a number. Read an OID left to right and you're walking from the general to the specific. Take 1.3.6.1.2.1.25.3.3.1.2: the 1.3.6.1 prefix is the internet subtree, 2.1 is mib-2 (the core managed objects), 25 is the Host Resources MIB, and the tail 3.3.1.2 narrows all the way down to hrProcessorLoad, per-CPU load. Each dot is one step deeper into the branch.

Scalar objects — single values — end in .0, which is why uptime is 1.3.6.1.2.1.25.1.1.0 with that trailing zero. Table objects work differently. They repeat, one row per instance, and the row is identified by an index appended to the column OID. Poll the storage-description column 1.3.6.1.2.1.25.2.3.1.3 and you get .1, .3, .6 and so on — one entry per disk, RAM area, or swap space. The column names the metric; the index names the row.

MIBs are written in a formal language called SMIv2 (RFC 2578), which is why a MIB file can tell a tool that an object is an INTEGER from 0–100, or a Counter, or a TimeTicks value. Load the right MIB and snmpwalk prints friendly names like hrProcessorLoad instead of raw digits; skip it and you still get the numbers, just without the labels. That name-resolution step is optional cosmetics — the OID is what actually travels on the wire.

Data type isn't a footnote, either — it changes how you read the value. A Counter only ever climbs and wraps around at its maximum, so a raw interface-octet count is useless on its own; you take the difference between two reads over time to get a rate. A Gauge can go up or down and is fine to read as-is, like a memory-used figure. TimeTicks are hundredths of a second since some epoch, which is why uptime comes back as a huge integer that tools then render as days and hours. Knowing the type of the object behind an OID is the difference between a number that means something and one you misinterpret. The MIB is where that type is declared.

Key components / concepts

The pieces you'll meet constantly, and the real object identifiers behind them:

Two families are worth naming. The 1.3.6.1.2.1.* branch is standard MIB-II territory — objects defined by IETF RFCs, portable across vendors. The 1.3.6.1.4.1.* branch is enterprise space, where each vendor gets its own arc; 2021 is the old UCD-Davis / Net-SNMP arc, home to laLoad. That split — standard versus enterprise — tells you at a glance whether an OID is universal or device-specific. Every one of these numbers, mapped to its metric, lives in the sensor & OID catalog.

Practical example

Watch the tree turn into data. Walk the storage table's description column to see what areas a host reports:

snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.2.3.1.3

HOST-RESOURCES-MIB::hrStorageDescr.1 = STRING: Physical memory
HOST-RESOURCES-MIB::hrStorageDescr.3 = STRING: /
HOST-RESOURCES-MIB::hrStorageDescr.6 = STRING: /boot

Now take one of those indices — say .3 for the root filesystem — and read its size and used columns at the same index:

snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.2.3.1.5.3 1.3.6.1.2.1.25.2.3.1.6.3

HOST-RESOURCES-MIB::hrStorageSize.3 = INTEGER: 20971520
HOST-RESOURCES-MIB::hrStorageUsed.3 = INTEGER: 8388608

The index .3 ties all three columns to the same filesystem. That's the table pattern in miniature, and it's worth spelling out as a repeatable recipe:

1. Walk a descriptive column (like hrStorageDescr) to discover the indices and what they map to.
2. Pick the index for the row you care about — here, .3 for /.
3. Read the other columns at that same index (hrStorageSize.3, hrStorageUsed.3) to assemble the full record.

Prefer raw numbers? Add -On to any command and Net-SNMP skips MIB name resolution entirely, printing the bare object identifier.

Common pitfalls / notes

• A missing MIB isn't a missing value. If names come back as numbers, the tool just doesn't have the MIB file loaded. The data is fine; install or point to the MIB, or use snmptranslate.
• The trailing .0 matters. Scalars need it. snmpget on ...25.1.1 without the .0 will fail where ...25.1.1.0 succeeds.
• Indices are not row numbers. Table indices like .196608 for processors are agent-assigned and can look arbitrary. Don't infer core order or disk order from them.
• Enterprise OIDs vary by device. A 1.3.6.1.4.1.* OID that works on one vendor's box means nothing on another's. Check the device's own MIB before assuming.
• Allowlist by OID. ostr.io's SNMP monitoring — and any hardened snmpd.conf — grants access one OID subtree at a time, so if a value won't return, confirm the object identifier is actually in the agent's view.