I recently needed to understand actually how the ordering for the oids in an SNMP table need to be arranged for commands like snmpwalk and snmptable to correctly traverse a table.
So here is a MIB fragment for a table:
jmxTable OBJECT-TYPE
SYNTAX SEQUENCE OF jmxEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
""
::= { monMIB 2 }
jmxEntry OBJECT-TYPE
SYNTAX JmxEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
""
INDEX { routeIndex }
::= { jmxTable 1 }
JmxEntry ::= SEQUENCE {
routeIndex INTEGER,
routeName DisplayString,
contextName DisplayString,
exchangesFailed INTEGER
}
routeIndex OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
""
routeName OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
""
::= { jmxEntry 2 }
contextName OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
""
::= { jmxEntry 3 }
exchangesFailed OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
""
::= { jmxEntry 4 }
We've got a four column table with a visible integer index, two text columns and a numeric column.
It turns out the important thing is that getnext on jmxEntry.0 must return jmxEntry.1.1.
Of course jmxEntry.0 doesn't exist in the MIB, except for its ability to respond to getnext.
No comments:
Post a Comment