SNMP MIBs: OIDs, MIB-II Objects and Enterprise Trees

01 /SNMP versions and why v3

Three SNMP versions are in service. Operations barely changed; security and counter width did.

Use v3 with authentication and privacy for anything reachable beyond one management VLAN. Use v2c only where old hardware lacks v3, restricted to read-only communities and a source ACL. Never enable write access through a community string.

02 /OIDs and the MIB tree

Every managed object has an object identifier (OID): a dotted sequence of integers naming a path from the root of one global tree, administered top-down so organisations cannot collide. The prefix that matters is 1.3.6.1, iso.org.dod.internet. Below it, 2.1 holds the standard objects (mib-2) and 4.1 holds private enterprise branches, one per vendor.

1               iso
1.3             org
1.3.6           dod
1.3.6.1         internet
1.3.6.1.2.1     mgmt.mib-2
1.3.6.1.2.1.1.3 sysUpTime
1.3.6.1.2.1.2.2 ifTable
1.3.6.1.4.1     private.enterprises
1.3.6.1.4.1.1991  Foundry Networks

A MIB module is the human-readable file, written in the SMI subset of ASN.1, that assigns names, types, access rules and descriptions to those numbers. Without it a poller still returns values, but as anonymous numbers under anonymous OIDs.

03 /MIB-II standard objects

MIB-II (RFC 1213) defines what every SNMP-capable device should offer. The system group gives sysDescr, sysObjectID (which identifies the model by pointing into the vendor branch), sysUpTime, sysName and sysLocation. The interfaces group gives ifTable: one row per interface with ifDescr, ifSpeed, ifOperStatus, ifInOctets, ifOutOctets and error counters. RFC 2863 added ifXTable with ifName, ifAlias, ifHighSpeed and the 64-bit ifHCInOctets and ifHCOutOctets. Bandwidth graphs should read the HC counters; see counter wrap below.

04 /Enterprise MIBs and the Foundry 1991 branch

Anything the standards do not cover (CPU load, temperature, power and fan state, optical diagnostics, load balancer session counts) lives in the vendor branch under 1.3.6.1.4.1. Each vendor holds an IANA enterprise number; Foundry Networks was assigned 1991, so every Foundry-specific object begins 1.3.6.1.4.1.1991. Second-hand BigIron, FastIron and ServerIron units still answer under that branch, and IronView Network Manager was essentially a front end to it. The original Foundry MIB reference documented the branch as one large PDF.

05 /Loading vendor MIBs into a poller

Obtain the MIB files matching the software release on the device; definitions move between releases. Copy them into the directory your poller or command-line tools search, and make sure every imported module (usually SNMPv2-SMI, SNMPv2-TC, IF-MIB and the vendor root module) is present. Bare numbers under the enterprise branch mean the root module is missing or the file is for another release. Pollers also need a device template mapping vendor objects onto graphs; that is separate from the MIB.

06 /Polling intervals and counter wrap

Octet counters increase monotonically and wrap to zero at their maximum, 4,294,967,295 for 32 bits. The poller computes rate as the difference between two readings divided by the interval, so a counter that wraps more than once between polls gives a silently wrong rate. Wrap time falls with link speed:

Poll interfaces every 60 seconds if the load is affordable, every 300 if not, and always use 64-bit counters above 100 Mbps. A single wrap between polls can be corrected by adding 2 to the power of 32 to a negative difference; a double wrap cannot.

07 /Traps versus polling, and common mistakes

Polling asks the device for values on a schedule. A trap (or in v2c and v3 an acknowledged inform) is sent by the device the moment something happens: a link drops, a power supply fails. Traps arrive on UDP 162 and are defined in the MIB as NOTIFICATION-TYPE objects. Use both: polling gives trends and catches events lost with a dropped UDP packet; traps give sub-second notice without polling every object every second.