tags:

views:

577

answers:

1

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 to flatten the definitions. The easiest way to do this would be to have the embedded table indexed by the same OID as the parent table. Thus

someTableEntry ::= SEQUENCE {
   someTableIndex
        Integer32,
   someTableDomain
        Integer32,
   someTableFooTable
        SEQUENCE OF SomeTableFooTable
} 

becomes

    someTableEntry ::= SEQUENCE {
       someTableIndex
            Integer32,
       someTableDomain
            Integer32,
    } 

someTableFooTable ::= SEQUENCE {
    someTableIndex
       Integer32,
....
} 

The good thing is that in our application there will NEVER be any kind of SET, GET or GET NEXT so no need for SNMP walk (there are some very good reasons for this that supersede the need for network management elegance. All attributes will be reported via traps only. I think this is a valid SNMP MIB definitions but wanted to get some feedback.

Thanks in advance.

+3  A: 

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. (I think that's what you were explaining in your question, but I just wanted to be clear.)

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 childEntry
    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
lostriebo
Very good. Thanks for the quick feedback.
Doug
@lostriebo: would the principle apply for a third table, i.e. it would have 3 indices, or are there better ways to manage it as the depth of the hierarchy grows?
TheJuice
@TheJuice: Yes, the principle applies to children tables up to the maximum OID length deep (which I believe is 127). As you guessed, each additional level would have another index. I'll edit my answer to include an example. I am not aware of any better ways to manage deeper hierarchies.
lostriebo