What Is an OID in SNMP? Object Identifiers Explained

By the SNMP Monitoring team · Reviewed July 2026

An OID (Object Identifier) is the address of a managed object. When snmpget prints 1.3.6.1.2.1.1.3.0 or a pretty name that means the same thing, that dotted string is how manager and agent agree which value they mean.

If you only learn one SNMP skill beyond “run snmpwalk,” learn to read OIDs. Templates, allowlists, and 2 a.m. ticket screenshots are full of them. Parent: What is SNMP. Schema side: MIB.

OID definition

An OID uniquely identifies a node in a global hierarchical namespace. On the wire and in tools you usually see dotted decimals: 1.3.6.1.2.1.1.3.0.

Symbolic names (SNMPv2-MIB::sysUpTime.0) come from MIB files loaded in the tool. The agent still thinks in numbers. No MIB on the laptop? Numeric still works. MIB without agent implementation? Pretty name, empty walk.

OIDs are not “secret vendor codes” in the movie sense—they're registered paths. Some branches are standard (mib-2). Some are enterprise under 1.3.6.1.4.1.

Anatomy of an OID

Read left to right, root toward leaf:

• Each number is a node under its parent
• Longer = more specific
• The full string is the path from the root of the tree

Example pieces you’ll see constantly:

• 1.3.6.1 — iso.org.dod.internet
• 1.3.6.1.2.1 — mgmt → mib-2
• 1.3.6.1.4.1 — private → enterprises

Deep hierarchy tour: OID tree.

Worked example: decoding 1.3.6.1.2.1.1.3.0

Numbered decode of 1.3.6.1.2.1.1.3.0 (sysUpTime instance):

1. 1 — iso
2. 3 — org
3. 6 — dod
4. 1 — internet
5. 2 — mgmt
6. 1 — mib-2
7. 1 — system group
8. 3 — sysUpTime object
9. 0 — scalar instance

So: under internet → management → mib-2 → system → sysUpTime → instance 0.

snmpget -v2c -c <RO_string> <host> 1.3.6.1.2.1.1.3.0

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (12345600) 1 day, 10:17:36.00

Same object, two presentations: number in the request, maybe a name in the output if MIBs loaded.

The OID tree

All OIDs hang on one global tree. Branches are allocated so standard management and private enterprise space don't collide by accident. Full walkthrough of roots and mib-2 groups: the OID tree.

You navigate the tree with walks: start at a prefix, agent returns everything under it (subject to views). That's why snmpwalk … 1.3.6.1.2.1.1 dumps the system group.

Standard vs enterprise OIDs

Enterprise deep dive: enterprise OIDs. Standard modules: standard MIBs.

Scalar OIDs vs tables

Scalars — one instance. Convention: instance identifier .0. Example: …1.3.0 for sysUpTime.

Tables — many rows. Instance IDs are row indexes (ifIndex, etc.), not .0. A column OID plus index selects one cell.

Walk excerpt (table-ish idea—multiple instances under a column):

snmpwalk -v2c -c <RO_string> <host> 1.3.6.1.2.1.25.3.3.1.2

HOST-RESOURCES-MIB::hrProcessorLoad.196608 = INTEGER: 12
HOST-RESOURCES-MIB::hrProcessorLoad.196609 = INTEGER: 47
HOST-RESOURCES-MIB::hrProcessorLoad.196610 = INTEGER: 9

Those trailing indexes are row IDs, not “.0 scalars.” More on table structure in MIBs: MIB structure.

Finding OIDs

Practical toolkit:

• snmpwalk / snmpget from the real poller — truth
• MIB browser — navigate names when modules loaded (MIB browser)
• Sensor catalog — common metrics already mapped (sensors/all)
• Vendor docs / MIBs — for enterprise leaves only after a lab walk

Numbered habit:

1. Identify the metric in plain language
2. Prefer a standard MIB object if it exists
3. Confirm with a walk on that device class
4. Put the numeric OID in the template
5. Keep the name in comments for humans

Mistakes that burn hours

• Copying an OID from a blog without walking the device
• Using a column OID without an index (or with the wrong one)
• Mixing enterprise PEN from memory (“Cisco is… uh…”) — look it up
• Allowlisting only .0 when you needed a whole table prefix
• Assuming symbolic name in one tool matches another tool's MIB set

Why allowlists care

OID allowlists and VACM views speak numbers. If you only think in names, you'll open too much or too little. External pollers that document specific OIDs (CPU, uptime, etc.) expect those prefixes to be reachable—not the entire enterprises tree.

Glossary: glossary. How a Get uses the OID: how it works.

Talking about OIDs without sounding lost

In tickets, paste the full numeric string, the host, and the command you ran. “CPU OID is broken” wastes an hour. “snmpget of 1.3.6.1.2.1.25.3.3.1.2 times out from poller A” is actionable.

When comparing two devices, diff the prefix first (mib-2 vs enterprise), then the leaf. Half of “they should be the same metric” arguments die when one side is HOST-RESOURCES and the other is 1.3.6.1.4.1.vendor….

Keep a short personal list: sysUpTime, ifHCInOctets (or whatever IF-MIB column you standardized), hrProcessorLoad—and the enterprise exceptions per platform. Update the list when firmware lies to you.

One more habit: when an NMS imports a “template pack,” expand every item and read the raw OID before enabling. Packs love symbolic names that resolve differently after a MIB upgrade. Numbers age better in production configs; names age better in documentation sitting next to those numbers.

Frequently asked questions

What does OID stand for?

Object Identifier—the hierarchical address of a managed object in SNMP (and ASN.1-related naming).

How do I read an SNMP OID?

Left to right as a path of nodes. Example: 1.3.6.1.2.1.1.3.0 → iso.org.dod.internet.mgmt.mib-2.system.sysUpTime instance 0.

What does .0 mean?

On scalars, .0 is the instance identifier for the single value. Table cells use row indexes instead.

Where do vendor OIDs start?

Under the enterprise branch 1.3.6.1.4.1, then a vendor PEN, then their subtree. See enterprise OIDs.

Key takeaways

• OID = object address; example 1.3.6.1.2.1.1.3.0 (sysUpTime.0).
• Decode prefix: 1.3.6.1.2.1 = mib-2 path; enterprises = 1.3.6.1.4.1.
• Scalars end in .0; tables use row indexes.
• Names come from MIBs; numbers work without them.
• Next: tree, enterprise, sensors/all.