The SNMP OID Tree: Numbering Hierarchy Explained

By the SNMP Monitoring team · Reviewed July 2026

The OID tree is one global namespace. Every SNMP object you poll sits somewhere on it—from the boring root path 1.3.6.1 down to a leaf like sysUpTime or a vendor sensor under enterprises.

Hierarchy matters because prefixes become allowlists, walk targets, and mental maps. “Walk mib-2” means something precise. “Walk the whole internet node” means you hate your agent. Parent: What is an OID.

What the OID tree is

Think of a phone numbering plan or a DNS tree, but with integers: each organization/std body owns a branch and hands out child numbers. The result is a single registered space so Cisco’s 9 and someone else’s 9 under different parents don’t collide the way random flat IDs would.

SNMP tooling shows you paths into that tree. MIBs attach names to nodes; the tree itself is numbers.

You never “create a new root.” You get a PEN under enterprises or use standard mib-2 objects.

From root to object

Numbered path from root to the internet node:

1. 1 — iso
2. 3 — org
3. 6 — dod
4. 1 — internet → full prefix 1.3.6.1

Almost every SNMP OID you’ll touch in ops starts with 1.3.6.1. If it doesn’t, you’re either in a weird experimental space or looking at something that isn’t a normal internet MIB path.

From there, management objects dive into mgmt → mib-2, and vendor objects into private → enterprises.

Key branches under internet

Under 1.3.6.1:

Ops cheat sheet:

• mgmt.mib-2 = 1.3.6.1.2.1
• private.enterprises = 1.3.6.1.4.1

If a ticket shows 1.3.6.1.4.1.…, you’re in vendor land. If it shows 1.3.6.1.2.1.…, you’re in standard management space (when implemented).

The MIB-2 subtree

1.3.6.1.2.1 is mib-2. Groups under it (classic MIB-II numbering):

• system(1) — 1.3.6.1.2.1.1
• interfaces(2) — 1.3.6.1.2.1.2
• at(3) — address translation (legacy)
• ip(4) — 1.3.6.1.2.1.4
• icmp(5)
• tcp(6) — 1.3.6.1.2.1.6
• udp(7) — 1.3.6.1.2.1.7
• snmp(11) — 1.3.6.1.2.1.11
• host(25) — 1.3.6.1.2.1.25 (HOST-RESOURCES lives here)

Later IF-MIB / IP-MIB / etc. refine parts of this world—see standard MIBs. The group numbers above are the tree map you navigate with walks.

Sensor catalog that hangs off these ideas: sensors/all.

Where enterprise OIDs branch off

1.3.6.1.4.1 = enterprises. Next integer is the vendor PEN, then their private tree. Full story: enterprise OIDs.

Mixing standard and enterprise in one template is fine—just label which is which so the next engineer doesn’t “standardize” a Cisco-only leaf fleet-wide.

Navigating the tree with snmpwalk

Walk a prefix, not the entire universe:

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

SNMPv2-MIB::sysDescr.0 = STRING: Linux edge-01 6.1.0-generic ...
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
SNMPv2-MIB::sysUpTime.0 = Timeticks: (720000) 2:00:00.00
SNMPv2-MIB::sysName.0 = STRING: edge-01

That was the system(1) group under mib-2. Widen carefully:

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

…only if HOST-RESOURCES is what you want—and the view allows it.

GetBulk-oriented tools help on big subtrees (PDU / GetBulk), but the tree prefix is still your unit of navigation.

How deep does it go?

As deep as modules define. There’s no fixed “OID has N arcs” rule for all objects. Scalars often end with .0; tables add index arcs. Vendor trees can be deep and ugly. Depth isn’t the problem—unknown prefixes are.

Practical mapping habits

1. Memorize 1.3.6.1.2.1 and 1.3.6.1.4.1.
2. Learn system …1.1 and host …1.25 if you do servers.
3. Learn interfaces …1.2 / IF-MIB .31 if you do networks.
4. Everything else: look up, walk, document.

Numbered onboarding for a new device class:

1. Walk 1.3.6.1.2.1.1 — prove agent life
2. Walk candidate standard groups
3. Note empty branches
4. Explore 1.3.6.1.4.1.<pen> only with vendor MIB in hand
5. Freeze numeric OIDs into templates

Failure modes tied to the tree

• Walking 1.3.6.1 on a slow agent — don’t
• Views that allow system but not host — “tree incomplete”
• Confusing experimental 1.3.6.1.3 with production mgmt
• Assuming group numbers without checking standard MIBs

Glossary: glossary. OID basics: OID.

Drawing the tree on a whiteboard

Boxes that earn their ink:

1. 1.3.6.1 internet
2. split to 2 mgmt vs 4 private
3. mib-2 1.3.6.1.2.1 with system / interfaces / host
4. enterprises 1.3.6.1.4.1 with a couple of PENs your company actually owns

Skip drawing directory and experimental unless someone asks. Clutter hides the paths you walk daily. Same reason NMS folders should mirror this split: Standard templates vs Vendor templates—not one giant “SNMP” bucket.

When onboarding, force the new hire to walk system, then host or interfaces, then one enterprise prefix. If they can narrate where they are in the tree, they’re ready for allowlists. Full stop.

Frequently asked questions

What is the root of the OID tree?

For practical SNMP, you almost always start from iso.org.dod.internet = 1.3.6.1, under the broader ISO/ITU registration tree beginning at iso(1).

What is 1.3.6.1.2.1?

mib-2 (mgmt.mib-2)—the standard management subtree where system, interfaces, host, etc. live.

What is under 1.3.6.1.4.1?

private.enterprises—vendor/organization branches keyed by Private Enterprise Numbers.

How deep does the OID tree go?

As deep as definitions require; no single fixed depth. Instances add final arcs (.0 or table indexes).

Key takeaways

• Global tree; ops lives under 1.3.6.1.
• mib-2 = 1.3.6.1.2.1; enterprises = 1.3.6.1.4.1.
• internet children: directory(1), mgmt(2), experimental(3), private(4).
• Navigate with prefix walks, not whole-tree fishing.
• Next: enterprise, standard MIBs, OID intro.