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.
MIB is a collection of information used for managing devices in the network. Network devices have a database called 'MIB' or 'MIB table' or 'MIB Tree' with the set of 'objects'. These object stores valuable information like memory status, hardware status, etc. within the network device.
The SNMP MIB defines the data types and access permissions for the various managed objects that can be accessed through the BEA SNMP Agent software. It also defines the event notifications that can be generated by the BEA SNMP Agent software.
Viewing the Contents of a MIB fileGo to the MIB Compiler page (System > Tools > MIB Compiler). In the MIB Compiler page, find the MIB you want to view. Select its information icon ( ). The MIB Viewer modal page appears and displays the contents of the MIB file.
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With