In SNMP, what is an object identifier, and how does the numeric OID 1.3.6.1.2.1.1.3.0 map to a named MIB object?
answer
- a path of numbers, not a name
- iso, org, dod, internet
- mgmt(2) then mib-2(1)
- system group, object 3
- trailing zero means scalar instance
basics
~10 sAn OID is a path of numbered arcs through a global registration tree. 1.3.6.1.2.1.1.3.0 reads iso.org.dod.internet.mgmt.mib-2.system.sysUpTime plus .0, the single instance of that scalar; a MIB module supplies the name, type and meaning.
solid answer
~40 sAn **object identifier** is an ordered list of non-negative sub-identifiers naming a node in a tree whose arcs are delegated to registration authorities. SNMP carries only the numbers; the human names live in **MIB modules**. Reading `1.3.6.1.2.1.1.3.0`: `1.3.6.1` is `iso(1).org(3).dod(6).internet(1)`, the subtree IANA administers; `2.1` is `mgmt(2).mib-2(1)`, where standard objects live; `1` is the `system` group; `3` is `sysUpTime`, defined in SNMPv2-MIB (RFC 3418) as `TimeTicks`, hundredths of a second since the agent's management subsystem was last re-initialised. The trailing `.0` is not part of the object's name: it is the instance suffix SMIv2 (RFC 2578) appends to a scalar. A manager without the module can still request the number; it just cannot name or interpret the answer.
go deeper
Be able to read 1.3.6.1.2.1 and 1.3.6.1.4.1 aloud by name and say what lives under each. Know that the trailing .0 marks a scalar's single instance.
Explain that only numbers cross the wire and that the module supplies name, type, access and meaning. Show you know what a manager can and cannot do with an OID it has no module for.
Treat the module as the contract for what a number means: units, reset behaviour and type. Point out that sysUpTime measures the management subsystem, not necessarily the whole device.
Frame the OID tree as delegated registration: each authority owns its arc forever, which is why names are stable for decades and why collisions never need arbitration.
## What an OID is An **object identifier (OID)** is an ordered list of non-negative numbers called **sub-identifiers**. Each number is an arc in a single global tree, and each arc is assigned by whoever owns the node above it. RFC 2578, the Structure of Management Information version 2 (**SMIv2**), limits an OID to at most **128 sub-identifiers**, each at most **2^32-1**, and requires at least two, the first being `ccitt(0)`, `iso(1)` or `joint-iso-ccitt(2)`. SNMP never puts a name on the wire. A request or response carries the numeric OID and, in a response, a value. Names such as `sysUpTime` exist only in **MIB modules**, the documents written in SMI notation that register an OID and say what lives there. ## Walking 1.3.6.1.2.1.1.3.0 arc by arc | Arc | Name | Who defines it | |---|---|---| | `1` | `iso` | the root's well-known name | | `3` | `org` | SMIv2's path to the root | | `6` | `dod` | SMIv2's path to the root | | `1` | `internet` | the subtree IANA administers | | `2` | `mgmt` | standard (IETF) objects | | `1` | `mib-2` | the standard MIB root | | `1` | `system` | SNMPv2-MIB, RFC 3418 | | `3` | `sysUpTime` | SNMPv2-MIB, RFC 3418 | | `0` | instance | SMIv2's suffix for a scalar | The object's **name** is `1.3.6.1.2.1.1.3`. RFC 3418 defines it with `SYNTAX TimeTicks`, `MAX-ACCESS read-only` and a description: the time, in hundredths of a second, since the network management portion of the system was last re-initialised. The **instance** a manager actually reads is `1.3.6.1.2.1.1.3.0`. ## The branches worth knowing by heart RFC 2578 section 4 places the network-management branches under `internet` (`1.3.6.1`): - **`mgmt(2)`** — objects in IETF standard modules; `mib-2` is `mgmt 1`, so standard objects start `1.3.6.1.2.1`. - **`experimental(3)`** — objects being designed by IETF working groups; when a module enters the standards track its objects move under `mgmt`. - **`private(4)`** with **`enterprises(1)`** beneath it — `1.3.6.1.4.1`, where each organisation gets a number from IANA and defines whatever it likes below it. - **`snmpV2(6)`** — the SNMP framework's own modules sit under `snmpModules`, `1.3.6.1.6.3`. Two more arcs appear often enough to recognise: `transmission` is `mib-2 10`, the home of media-specific modules, and `security(5)` sits beside `private`. RFC 2578 adds that the SMI does not forbid defining objects elsewhere in the tree, but these branches are where an operator meets them. Because every authority only ever adds arcs under its own node, two organisations can never collide, and a number assigned decades ago still means the same thing today. ## Why the trailing .0 matters RFC 2578 section 7 says a leaf object that is not in a table has its instance identified by appending a sub-identifier of **zero**. A table column is different: its instance suffix is built from the row's index values. So `sysUpTime.0` is the one and only value of `sysUpTime`, while a request for `1.3.6.1.2.1.1.3` without the `.0` names the object type, not an instance, and returns no value. ## What the MIB module adds, and what you lose without it A MIB module turns a number into knowledge: 1. the **descriptor** (the name), 2. the **SYNTAX** (the data type, such as `TimeTicks` or `Counter32`), 3. the **MAX-ACCESS** (whether reading, writing or row creation makes sense), 4. the **STATUS** (current, deprecated or obsolete), 5. the **DESCRIPTION**, which is the actual meaning, including units and when the value resets. Without the module, a manager can still send a request for `1.3.6.1.2.1.1.3.0`, and the agent still answers, because the agent implements the object whether or not the manager knows its name. The value even arrives tagged with its SMI type, so the manager can tell a `TimeTicks` from an `OCTET STRING`. What it cannot know is that this number is uptime, in hundredths of a second, reset when the management subsystem restarts. Loading the module is what lets a tool print `sysUpTime.0` instead of a string of digits. ## Common confusions - The OID tree is not SNMP's private namespace: `iso` and `org` sit above the internet subtree, and the same registration tree names things outside SNMP. - `enterprises` is under `private`, not under `mgmt`; `1.3.6.1.2.1` and `1.3.6.1.4.1` differ at the seventh sub-identifier. - A MIB module is a specification. The agent implements the objects; the manager needs the module only to name and interpret them.
- Why does a request for 1.3.6.1.2.1.1.3 without the trailing .0 return no value?Because `1.3.6.1.2.1.1.3` is the name of the object type, not of an instance. SMIv2 identifies the single instance of a non-tabular object by appending a zero sub-identifier, so the agent holds a value only at `1.3.6.1.2.1.1.3.0`. An exact-match request for the bare name finds no instance there; a request that asks for the next object after it would land on the `.0` instance.
- What does sysObjectID.0 add when you meet a device for the first time?`sysObjectID` (`1.3.6.1.2.1.1.2`) is an `OBJECT IDENTIFIER` value that RFC 3418 says is allocated within the enterprises subtree, `1.3.6.1.4.1`, as the vendor's authoritative identification of the management subsystem. Reading it tells you which organisation's subtree, and which product registration within it, describes the box, so you know which enterprise modules to load.
An OID is like an international phone number: each authority hands out digits under its own prefix, you can dial a number without knowing whose it is, and a directory, the MIB module, is what tells you who answered.
saying these in an interview costs you the question
- SNMP sends object names like sysUpTime inside the packet
- The trailing .0 means the first row of a table
- The enterprises arc sits under mgmt, at 1.3.6.1.2.1
- A manager cannot query an object until it loads that object's MIB
- sysUpTime counts seconds since the device last booted