---
type: Article
title: "MIB and OID Explained"
description: "An OID is the numeric address of one value; a MIB is the dictionary that defines it. Together they give SNMP a single global namespace for machine data."
resource: "https://snmp-monitoring.com/what-is-snmp/mib-and-oid/"
tags: [what-is-snmp, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# 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](/what-is-snmp/index.md); for who talks to whom, see [SNMP architecture](/what-is-snmp/architecture.md).

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.

![Diagram of the SNMP OID tree branching from root through internet, mib-2, and Host Resources MIB down to hrProcessorLoad](https://snmp-monitoring.com/img/what-is-snmp/oid-tree-diagram.webp)

## 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:

| Object name | OID | MIB / standard |
|---|---|---|
| `hrSystemUptime` | `1.3.6.1.2.1.25.1.1.0` | Host Resources MIB (RFC 2790) |
| `hrProcessorLoad` | `1.3.6.1.2.1.25.3.3.1.2` | Host Resources MIB (RFC 2790) |
| `hrStorageUsed` | `1.3.6.1.2.1.25.2.3.1.6` | Host Resources MIB (RFC 2790) |
| `laLoad` (15-min) | `1.3.6.1.4.1.2021.10.1.3` | UCD-SNMP-MIB (enterprise 2021) |
| `ifHCInOctets` | `1.3.6.1.2.1.31.1.1.1.6` | IF-MIB (RFC 2863) |

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](/sensors/index.md).

## Practical example

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

```bash
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:

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

![Table showing SNMP OIDs mapped to their MIB object names and data types for CPU, storage and uptime](https://snmp-monitoring.com/img/what-is-snmp/mib-oid-mapping.webp)

## FAQ

**What's the difference between a MIB and an OID?**
The MIB is the definition document; the OID is the numeric address of one object defined in it. The MIB tells you `1.3.6.1.2.1.25.3.3.1.2` is `hrProcessorLoad`, a 0–100 integer. The OID is what your query actually sends.

**Why are OIDs so long?**
Because they encode the full path from the root of the OID tree down to a specific object. Each dot is a branch. The length is what guarantees every value has a globally unique, unambiguous address.

**Do I need MIB files to use SNMP?**
No. MIB files only translate numeric OIDs into readable names. You can poll `1.3.6.1.2.1.25.1.1.0` and get the value with no MIB loaded — you just won't see the friendly `hrSystemUptime` label.

**What does a trailing number after the OID mean?**
It's the instance or index. A `.0` marks a scalar (single value); any other number is a table row index, identifying which disk, interface, or processor the value belongs to.

## Conclusion

MIBs and OIDs are the addressing system that makes SNMP universal: the MIB defines the object, the OID locates it, and the tree keeps every value globally unique. Learn to read an object identifier left to right and to spot a table index, and the rest of SNMP monitoring opens up. From here, browse the real numbers in the [sensor & OID catalog](/sensors/index.md). When you're ready to act on those values, [ostr.io Monitoring](https://ostr.io/service/monitoring) polls your chosen OIDs from outside the network and alerts in real time — the [double durability](/monitoring/double-durability.md) idea that keeps you covered even when the monitored host goes dark.