By the SNMP Monitoring team · Reviewed July 2026
Open a vendor MIB once and it looks like someone sneezed ASN.1 onto the disk. By the end of this page you should be able to find OBJECT-TYPE, read SYNTAX and MAX-ACCESS, and spot a table's INDEX without panicking.
Parent overview: MIB files. OIDs as addresses: OID. Standard modules you'll recognize: standard MIBs.
SMI: the language of MIBs
MIBs are written in SMI—Structure of Management Information—a constrained use of ASN.1 notation. SMIv2 is RFC 2578. Textual conventions live in RFC 2579; conformance statements in RFC 2580. You don't need to recite those numbers daily, but when a compiler complains, those RFCs are the law.
SMI defines how you declare types and objects so different vendors' tools can parse the same module. It's not the SNMP wire protocol (that's PDUs on UDP). It's the schema language.
Anatomy of a MIB module
Numbered walk through a typical file:
- Header / module name —
SOME-MIB DEFINITIONS ::= BEGIN - IMPORTS — pull types and OIDs from other modules (SNMPv2-SMI, SNMPv2-TC, …)
- MODULE-IDENTITY — who published this module, revisions, contact fluff
- OBJECT-IDENTITY (sometimes) — intermediate OID nodes for structure
- OBJECT-TYPE definitions — the actual leaves and table columns
- END
Skip the marketing DESCRIPTION paragraphs if you're in a hurry. Don't skip SYNTAX and the OID assignment—that's the operational meat.
If IMPORTS can't resolve, the whole module fails to load. Install dependency MIBs first; that's half of “our browser won't open the vendor file.”
The OBJECT-TYPE macro
Core macro. Rough shape you'll see again and again:
sysUpTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The time since the network management portion of the
system was last re-initialized."
::= { system 3 }
Fields that matter:
- SYNTAX — data type (TimeTicks, Counter64, …)
- MAX-ACCESS — how managers may use it
- STATUS — current / deprecated / obsolete
- DESCRIPTION — human meaning (sometimes actually useful)
::= { parent n }— OID assignment under a parent node

MAX-ACCESS values from the SMI set include: not-accessible, read-only, read-write, read-create, accessible-for-notify. Table index objects are often not-accessible—you don't Get them as standalone scalars the way juniors expect.
SMI data types
Base types you'll meet constantly:
| Type | Meaning in practice |
|---|---|
| Integer32 | Signed 32-bit integer (enums often layered on integer) |
| Counter32 | Wraps; use deltas over time—not absolute “amount” |
| Counter64 | Wider counter for high-speed links / big counts |
| Gauge32 | Can go up and down (levels, rates already computed, etc.) |
| TimeTicks | Hundredths of a second (sysUpTime style) |
| OCTET STRING | Bytes / strings (display hints vary) |
| OBJECT IDENTIFIER | An OID value |
| IpAddress | IPv4 address in classic SMI |
Counter32 vs Counter64: both are counters (monotonic until wrap). 64-bit exists because 32-bit wraps too fast on busy high-speed interfaces. If you graph a counter as a gauge, you'll invent fiction—compute rates from deltas.
Textual conventions (RFC 2579) alias these into friendlier names (DisplayString, etc.). Same underlying idea.
Tables: SEQUENCE OF, INDEX, conceptual rows
SNMP tables aren't SQL. A table is usually:
- A table object whose SYNTAX is SEQUENCE OF SomeEntry
- An entry object (conceptual row) with an INDEX clause
- Columnar OBJECT-TYPEs under that entry
INDEX columns identify the row (ifIndex, etc.). When you walk a column, you get one value per row index. That's why interface counters come back as many OIDs under the same column prefix.
Conceptual row = one INDEX combination. Don't expect SELECT * semantics from snmpwalk, but mentally mapping “row/column” helps.
Custom table design is advanced—start from custom OID patterns only if you're implementing, not just polling.
Annotated example
Scalar (single instance, often ends in .0 on the wire): like sysUpTime under the system group—SYNTAX TimeTicks, read-only, OID under system.
Table column: something like an interface counter column—SYNTAX Counter32 or Counter64, indexed by ifIndex, many instances.
Wire proof you don't need the MIB file if you know the number:
snmpget -v2c -c <RO_string> <host> 1.3.6.1.2.1.1.3.0
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (240000) 0:40:00.00
With MIBs loaded, tools print the name. Without them, the number still works. Production templates should prefer the number; humans can keep the name.
More on addressing: OID. Parent: MIB overview.
How I actually read a new vendor MIB
- Search for the object name support mentioned.
- Jump to its OBJECT-TYPE.
- Note SYNTAX + MAX-ACCESS.
- Find the
::= { ... }parent chain until I can form a full OID—or trust a compiled browser. - Walk that OID on a lab unit.
- Only then paste into the NMS.
If step 5 fails, the MIB is a wish list. Don't build alerts on wishes.
Gotchas
- Deprecated STATUS — still present; prefer replacements if listed
- not-accessible indexes — can't snmpget the index object alone the way you hope
- SMIv1 vs SMIv2 quirks in ancient modules
- Wrong endian mental model for OCTET STRING “numbers”
- Assuming DESCRIPTION matches firmware — firmware lies; walks don't
Glossary: glossary.
Mini field exercise
Grab any standard module that defines sysUpTime (or open SNMPv2-MIB on your system). Find the OBJECT-TYPE. Confirm SYNTAX is TimeTicks, MAX-ACCESS read-only, and the assignment sits under system. Then:
snmpget -v2c -c <RO_string> <host> 1.3.6.1.2.1.1.3.0
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (100) 0:00:01.00
You've closed the loop: text definition → numeric OID → live agent value. Do the same once with a table column (pick an ifTable/ifXTable counter you care about) and INDEX will stop being abstract.
If the file won't parse, fix IMPORTS and SMIv2 dependencies before rewriting monitoring theory. Compilers are picky so you don't have to be guessing types on the wire.
Keep a short personal cheatsheet: OBJECT-TYPE fields, the MAX-ACCESS enum list, Counter vs Gauge, and “INDEX means row key.” That covers 90% of files support dumps on you at 17:55 on a Friday. The other 10% is vendor creativity—and that's what lab walks are for.
Frequently asked questions
What language are MIBs written in?
SMI (Structure of Management Information), a specialized ASN.1-based notation. SMIv2 = RFC 2578 (with RFC 2579/2580 companions).
What is OBJECT-TYPE?
The core SMI macro that declares a managed object: SYNTAX, MAX-ACCESS, STATUS, DESCRIPTION, and its OID assignment.
What is MAX-ACCESS?
It states how the object may be used: e.g. read-only, read-write, not-accessible, read-create, accessible-for-notify.
Counter32 vs Counter64?
Both are counters for delta/rate math. Counter64 is wider—needed when 32-bit wrap is too fast (classic high-speed interface problem).
Key takeaways
- MIB modules = IMPORTS + identity + OBJECT-TYPEs in SMIv2 (RFC 2578).
- Read SYNTAX, MAX-ACCESS, OID assignment first.
- Types: Integer32, Counter32/64, Gauge32, TimeTicks, OCTET STRING, OID, IpAddress.
- Tables: SEQUENCE OF + INDEX conceptual rows.
- Always verify with a walk. Next: MIB, standard MIBs, OID.