SNMP nested table defined one level below the parent table

Question

As described in this post and this note, it is possible to model nested tables in SNMP with the following structure:

parentTable ... ::= { parentNode 1 } -- using index x
childTable  ... ::= { parentNode 2 } -- using index x and y

That is the parent and child tables are registered under the same node (i.e. at the same level), which is something I want to avoid (mainly because it waists one OID on this node which is problematic in the application I'm dealing with).

My question is: is it possible to do exactly the same, the only difference being that I register the child table in a sub-node of parentNode? It would look like something like:

subNode OBJECT IDENTIFIER ::= { parentNode 512 }
parentTable ... ::= { parentNode 1 } -- using index x
childTable  ... ::= { subNode 1 }    -- using index x and y

And if this syntax is valid, would it have the same properties as the first version (a deletion of a raw in parentNode would also delete the corresponding raw in childNode)?

I've tried to compile a MIB containing tables defined as above and it works perfectly: childTable can be defined in a sub-node (even multiple level sub-nodes). — stackoverflowed, Jul 17 '15 at 07:17

score 2 · Answer 1 · edited May 18 '18 at 12:50

Please refer the link for detailed explanation https://sourceforge.net/p/net-snmp/mailman/message/24158139/

Credits to chenyapu A quote from the excellent book Understanding SNMP MIBs (page 277):

The SNMP SMI does not allow a MIB writer to state that an object in a table is an array (an ASN.1 sequence). This restriction, known as "no table in a table" in the SNMP community, is a frequent source of frustration for beginning SNMP MIB designers.

score 0 · Accepted Answer · answered Jun 10 '15 at 15:41

Try it! Your MIB compiler should tell you if it's valid or not.

If you're not using a MIB compiler, you really should! It's very bad form to release invalid MIB files onto the world, so you should take every precaution. (Well, posting here is a good start.) Since SNMP does not really allow you to break backwards compatibility for any user of your MIB, even removing illegal constructs is going to cause trouble if your MIB has been circulated to a wider audience.

When it comes to the "parent" and "child" table indexing, it sounds to me like what is commonly known in SNMP as "Augmented Tables". You'll have to defined childTable using the AUGMENTS keyword. Do let me know if that's not the case you're imagining. From the WebNMS API documentation:

Augmented Table comes into picture when there is one-to-one dependency between rows of one table and rows in another table. In such cases, one table is the base and the other is the augmenting table. This might arise when a particular MIB imports another MIB and shares the same table. A classic example is IF-MIB importing the group interfaces defined in RFC 1213-MIB, where IF-MIB augments the ifTable defined in RFC 1213-MIB.

My hunch is that your construct is perfectly legal. The MIB tree would look like this, and I've seen similar trees many times. I don't think the indexes come into the question at all, they should really not matter.

parentNode (1)
|
|-parentTable(1.1)
| |
| |-x(1.1.1)
| \-secondColumn(1.1.2)
\-subNode(1.512)
   |
   \-childTable(1.512.1)
      |
      |-x(1.1.1)
      |-y(1.512.1.1)
      \-someData(1.512.1.2)

As for the semantics of your tables, yes, augmenting a table means that when deleting a row in parentTable, the corresponding data should be deleted from childTable. Your implementation of the MIB needs to make sure this happens.

SNMP nested table defined one level below the parent table

2 Answers2