SNMP: ASN.1 MIB Definitions. Referencing a table within a table

Question

Its\'s been a while since I\'ve written ASN.1 so..

Our data model is comprised of several table definitions within a table. This is not workable in SNMP, so we need

Answer 1

It sounds like you're on the right track. In order to define a table as a child of another table, you simply index it by the parent's index plus the child's index (e.g., 0.1.8.23.7.2.42 where 2 is the parent index and 42 is the child index).

For example, you could define a parent like:

parentTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF parentEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION  "Parent table"
    ::= { example 1 }

parentEntry OBJECT-TYPE
    SYNTAX       ParentEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION  "Entry in Parent table"
    INDEX        { parentIndex }
    ::= { parentTable 1 }

ParentEntry ::= SEQUENCE {
    parentIndex            Unsigned32,
    -- other columns in the table
    }

-- define the columns in the parent table

With a child table defined as:

childTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF childEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION  "Child table"
    ::= { example 2 }

childEntry OBJECT-TYPE
    SYNTAX       ChildEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION  "Entry in Child table"
    INDEX        { parentIndex,
                   childIndex }
    ::= { childTable 1 }

ChildEntry ::= SEQUENCE {
    childIndex            Unsigned32,
    -- other columns in the table
    }

-- define the columns in the child table

Note that it's not necessary to list parentIndex in the ChildEntry sequence since it's already be declared elsewhere in the MIB.

This method works well and it even responds to snmp walks without issue.

Once you have a MIB that you think accurately defines the structure you want, you can validate it using smilint if you are on a linux machine or have cygwin installed or you can validate it online.

Update

This pattern will work for deeper nesting as well.

A grandchild table could be defined as:

grandChildTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF grandChildEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION  "Grandchild table"
    ::= { example 3 }

grandChildEntry OBJECT-TYPE
    SYNTAX       GrandChildEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION  "Entry in Grandchild table"
    INDEX        { parentIndex,
                   childIndex,
                   grandChildIndex }
    ::= { grandChildTable 1 }

grandChildEntry ::= SEQUENCE {
    grandChildIndex            Unsigned32,
    -- other columns in the table
    }

-- define the columns in the grandChild table

The only limit on nesting depth is the maximum OID length (which, I believe, is 127): A column's base OID length plus the number of indices for the table must be less than the maximum OID length.

One other item to note is that at each level there can be multiple siblings.

A second child could be defined as:

secondchildTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF secondchildEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION  "Second child table"
    ::= { example 4 }

secondchildEntry OBJECT-TYPE
    SYNTAX       SecondchildEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION  "Entry in Second child table"
    INDEX        { parentIndex,
                   secondchildIndex }
    ::= { secondchildTable 1 }

SecondchildEntry ::= SEQUENCE {
    secondchildIndex            Unsigned32,
    -- other columns in the table
    }

-- define the columns in the second child table