I am designing an SNMPv2 MIB to allow management of a set of resources that come and go over time. Their unique identifier is a string. I will create a table


I see alternatives for the index to this table:

  1. Add a generated numeric index field
  2. Use the Name

I'm asking for advice on which alternative to use (or indeed for other options). I have no experience of using SNMP to manage systems in the real world and so I find it hard to evaluate the practical implications of this choice.

Pros and Cons for each:

Generated numeric index


Really simple. Just obtain my list of resources, the index value derives from the position in the sequence.


The index value is not stable over time. The resource list will be alphabetical by Name, so addition of a resource can insert in the middle of the list, deletion will also have the effect of changing the index values of later items in the list.

I see from questions likes this that index instability does cause some problems. The interface interface MIB has been designed to use an artificial, unstable, integer index rather than the unique interface identifier. In that example the instability occurs in the rare case of agent restart, in my case instability occurs much more frequently, whenever a resources is created. So why not use a:

Unique String Index

PROs: It's stable, we access the resource by its name.

CONs: The oid derived from the string index is a string of encoded characters. As decribed here the resulting oid is not readily intelligible.

for example, the only indication of the username “alice” in the usmUserTable of The usmUserTable might be the OID fragment, representing the ASCII codes for the letters a.l.i.c.e.

worse, SNMPv2 requires that index items be marked as not accessible, and so would not be returned in an SNMP GET - the idea being that the index value is represented in the OID. I suppose I could address that last point by adding an extra column.

My guess is that I should follow the seemingly universal practice of using a numeric index and assume that folks work around the instability. Agreed?

  • I would vote for using string index with octet string encoding: [strlen].[asciicode]..., like 5.a.l.i.c.e Net-snmp tools can decode it to human readable format. Otherwise applications will have to get/keep string-to-num mapping every time they want to get resource. Alternatively you can consider using appropriate string-to-integer hash function go generate sparse but predictable unique numeric indexes for your table (md5, etc). – Yuri Lachin May 28 '18 at 11:56
  • Thanks Yuri. For the reasons you outline I had thought this would be the approach; however it seems that every example I find uses unstable indexes. I'll be interested to hear from anyone else. – djna May 28 '18 at 19:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.