SNMP: Mistake of Using Tabular OID in Practice

Arif — Tue, 20 Mar 2012 07:57:58 +0000

Recently, I retrieve rectifier-related SNMP data from Eltek’s Smartpack Controller. This one has the following rear type where we can connect to the ethernet plug (see the purple area).

Eltek Smartpack Controller rear view (type that comes with SNMP support)

It is presumably in its default configuration and I can snmpwalk through its corporate specific OIDs (under 12148 tree) to find i.e. output voltage, current, battery temperature, etc. Doing it without translating against the MIB will retrieve all the values perfectly fine. However, I want to show you a mistake in practice related to how the MIB is written and put to place, which is a version 4 by the name of ELTEK-DISTRIBUTED-PLANTV4-MIB. It has tabular part as clipped in the following tree (see previous post on how to write such part in your own MIB):

            |     +--eltek(12148)
            |        |
            |        +--eltekDistributedPlantV4(9)
...
            |           |
            |           |     |
            |           |     +--rectifierStatusTable(2)
            |           |        |
            |           |        +--rectifierStatusEntry(1)
            |           |           |  Index: rectifierStatusID
            |           |           |
            |           |           +-- -R-- Integer32 rectifierStatusID(1)
            |           |           |        Range: 1..100
...
            |           |           +-- -R-- Integer32 rectifierStatusOutputVoltage(4)
            |           |           |        Range: 0..65535

Looking at the above rectifierStatusEntry branch, it marks a tabular entry expected to range from 1 to 100 as defined by rectifierStatusID. Hence, putting 0 as one of the output voltage index will confuse the OID reported by GET as

belong to the scalar type (a misconception that is)
belong to the tabular type but out of index range

GET against the MIB will return the following error

$ sudo snmpget -m +ELTEK-DISTRIBUTED-PLANTV4-MIB -v 1 -c public raddlex ELTEK-DISTRIBUTED-PLANTV4-MIB::rectifierStatusOutputCurrent.0
ELTEK-DISTRIBUTED-PLANTV4-MIB::rectifierStatusOutputCurrent.0: Unknown Object Identifier (Index out of range: 0 (rectifierStatusID))

while the item (output current) actually has value in it as found below

$ sudo snmpget -v 1 -c public raddlex .1.3.6.1.4.1.12148.9.5.5.2.1.3.0
SNMPv2-SMI::enterprises.12148.9.5.5.2.1.3.0 = INTEGER: 1

By this time the MIB is already the latest to be used with firmware version 4.3.

Write Your Own MIB File (Tabular)

Arif — Fri, 09 Sep 2011 11:23:19 +0000

When it comes to writing our own MIB, a practical choice might be to write the whole objects as of scalar type (RFC-1212). That means, let’s say we have 2 battery statuses, each of them must be explicitly written individually within the MIB file. Example of calling their voltages:

$ snmpwalk -m +REKTRONIK-MIB -v 1 -c public monitored-host .1.3.6.1.4.1.38610
...
REKTRONIK-MIB::battery1Voltage.0 = INTEGER: 9
REKTRONIK-MIB::battery2Voltage.0 = INTEGER: 11
...

If additional 3rd battery is to be monitored, REKTRONIK-MIB.txt in this example must be modified. In small scale we don’t need consistent MIB as changes are manageable, but if a whole bunch of different people must reference to this, a better way is to have tabular object where the above batteries are indexed instead of ended with “.0” scalar identifier.

Quick approach by checking established LM-SENSORS-MIB.txt shows at least we need three object definitions inside the MIB file:

Components of writing tabular MIB

Its stemmed MIB tree to show the (1) Table, (2) Entry, and (3) Index:

...
            |     |  |     +--lmFanSensorsTable(3)
            |     |  |     |  |
            |     |  |     |  +--lmFanSensorsEntry(1)
            |     |  |     |     |  Index: lmFanSensorsIndex
            |     |  |     |     |
            |     |  |     |     +-- -R-- Integer32 lmFanSensorsIndex(1)
            |     |  |     |     |        Range: 0..65535
...

Now the writing part of those three types to our MIB, plus the batteryVoltage which is the actual object to be indexed in the final SNMP monitoring.

batteryTable OBJECT-TYPE
    SYNTAX     SEQUENCE OF BatteryEntry
    MAX-ACCESS not-accessible
    STATUS     current
    DESCRIPTION
        "The (conceptual) table of batteries contained by the
        module."
    ::= { monitor 1 }
 
batteryEntry OBJECT-TYPE
    SYNTAX     BatteryEntry
    MAX-ACCESS not-accessible
    STATUS     current
    DESCRIPTION
        "A (conceptual) entry for one battery contained by
        the module.  The batteryIndex in the index represents
        the entry in the batteryTable that corresponds to the
        batteryEntry.
 
        As an example of how objects in this table are named,
        an instance of the batteryVoltage object might be
        named batteryVoltage.3"
    INDEX { batteryIndex }
    ::= { batteryTable 1 }
 
batteryIndex OBJECT-TYPE
    SYNTAX      DeviceIndex
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "A unique value, greater than zero, for each battery. 
            It is recommended that values are assigned contiguously
            starting from 1."
    ::= { batteryEntry 1 }
 
batteryVoltage    OBJECT-TYPE 
   SYNTAX Integer32 
   ACCESS read-only 
   STATUS current 
   DESCRIPTION 
      "Voltage A/D value" 
   ::= { batteryEntry 2 }

There are some header parts of course, check the resulting REKTRONIK-MIB.txt here.

The tree view becomes:

            +--private(4)
            |  |
            |  +--enterprises(1)
            |     |
            |     +--rektronik(39559)
...
            |        |
            |        +--monitor(2)
            |        |  |
            |        |  +--batteryTable(1)
            |        |  |  |
            |        |  |  +--batteryEntry(1)
            |        |  |     |  Index: batteryIndex
            |        |  |     |
            |        |  |     +-- -R-- Integer32 batteryIndex(1)
            |        |  |     |        Textual Convention: DeviceIndex
            |        |  |     |        Range: 1..2147483647
            |        |  |     +-- -R-- Integer32 batteryVoltage(2)
            |        |  |     +-- -R-- Integer32 batteryCurrent(3)
            |        |  |
            |        |  +--environment(2)
            |        |  |  |
            |        |  |  +-- -R-- Integer32 temperature(1)
            |        |  |  +-- -R-- Integer32 humidity(2)
...

and example of getting SNMP is

$ snmpwalk -m +REKTRONIK-MIB -v 1 -c public monitored-host .1.3.6.1.4.1.38610
REKTRONIK-MIB::name.0 = STRING: "RekMini"
REKTRONIK-MIB::version.0 = STRING: "1.0"
REKTRONIK-MIB::date.0 = STRING: "2011-09-08"
REKTRONIK-MIB::batteryIndex.22 = INTEGER: 22
REKTRONIK-MIB::batteryIndex.23 = INTEGER: 23
REKTRONIK-MIB::batteryVoltage.22 = INTEGER: 9
REKTRONIK-MIB::batteryVoltage.23 = INTEGER: 11
REKTRONIK-MIB::batteryCurrent.22 = INTEGER: 2
REKTRONIK-MIB::batteryCurrent.23 = INTEGER: 2
...

in the above example any additional 3rd battery voltage insertion will be OID “REKTRONIK-MIB::batteryVoltage.24“

logIt » MIB

SNMP: Mistake of Using Tabular OID in Practice

Write Your Own MIB File (Tabular)