2

Recently we were making MIB files for NMS system, while doing so I came across that after deploying the MIBs on Linux machine to query it I need to add 101.1 at the end, where as for standard Linux mibs only .0 needs to be appended. I am not able to understand this that why my value is returned in 101.1 and not .0.

For example when I do this with linux MIBs I get the value

snmpget -v 2c -c public localhost 1.3.6.1.2.1.1.3.0
SNMPv2-MIB::sysUpTime.0 = Timeticks: (105543) 0:17:35.43

But for my mib to work I need to append 101.1

snmpwalk -v 2c localhost -c public .1.3.6.1.4.1.****.1.2.3.101.1 
SNMPv2-SMI::enterprises.****.1.2.3.101.1 = STRING: "388 MB"

When I do a walk with my MIB I get the following .

snmpwalk -v 2c localhost -c public .1.3.6.1.4.1.****.1.2.3

SNMPv2-SMI::enterprises.****.1.2.3.1.1 = INTEGER: 1
SNMPv2-SMI::enterprises.****.1.2.3.2.1 = STRING: "getSystemMemoryUsage.sh"
SNMPv2-SMI::enterprises.****.1.2.3.3.1 = STRING:
"/opt/nagios/plugins/fetch_scripts/System/getSystemMemoryUsage.sh"
SNMPv2-SMI::enterprises.****.1.2.3.100.1 = INTEGER: 0
SNMPv2-SMI::enterprises.****.1.2.3.101.1 = STRING: "388 MB"
SNMPv2-SMI::enterprises.****.1.2.3.102.1 = INTEGER: 0
SNMPv2-SMI::enterprises.****.1.2.3.103.1 = ""

Can any one advice why such behavior in our MIB and what needs to be done so that my MIB behave like Linux Mibs where I just add .0 at the end and get the value. The OBJECT TYPE is scalar for all .

Thanking you all in advance

punith
  • 1,249
  • 1
  • 15
  • 18

1 Answers1

4

The MIB nomenclature supports data represented as table's rows and non-tabular scalars. Data which are presented as scalars are accessed by using OID.0 index. The ".0" part indicates access to scalar object - single object instance in the system. The tables contain columns (each column represent some kind of data) and rows (each row represent a table instance - some kind of entity which does support that table).

In your example, you try to access some table in your Enterprise MIB. This table contain an index (there may be single or multiple indexed MIB tables). To determine first available index in that table you can start with snmpgetnext command in following way:

snmpgetnext -v2c -c public localhost .1.3.6.1.4.1.****.1.2.3

or

snmpgetnext -v2c -c public localhost .1.3.6.1.4.1.****.1.2.3.0

or

snmpgetnext -v2c -c public localhost .1.3.6.1.4.1.****.1.2.3.0.0

As you can see all of the above commands give you first existing row instance by updating two last OID parts (.0.0). These two OIDs don't have to be specified explicitly, therefore you may use only one null-index (.0) or even don't have to specify them at all.

To understand how these table's indexes are described you need to refer to your Enterprise MIB - find table described by this OID: .1.3.6.1.4.1.**.1.2.3 and learn about indexing scheme and what does these indexes represent. Well-written MIB should contain this information.

Interpretation may be following:

  • *.1.1 = 1 - data column with id=1 for entity index 1
  • *.2.1 = "getSystemMemoryUsage.sh" - data column with id=2 for entity index 1 representing script name (STRING syntax)
  • *.3.1 = "/opt/nagios/plugins/fetch_scripts/System/getSystemMemoryUsage.sh" - data column with id=3 for entity index 1 representing full script's path (STRING syntax)
  • *.100.1 = 0 - data column with id=100 for entity index 1 representing some INTEGER value and so on...

Column indexing (.1, .2, .3, .100, .101 ...) may contain gaps if MIB designers expect to add some columns in future between .3 and .100. or simply entity index 1 does not support these columns (if they are defined in MIB). It is allowed to skip empty columns.

If you would like to read about differences between scalar and columnar objects, please refer to i.e. RFC1212.

lucassm
  • 319
  • 1
  • 6