Write Your Own MIB File (Tabular)
In General Linux on 9 September 2011 with 1 comment 
11882 views
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.
75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 | 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“
Sandeep
One thought on “Write Your Own MIB File (Tabular)”