On 11 March 2011 12:15, Jörg Westheide <[email protected]> wrote: >> But you could certainly have a table indexed by two values: >> >> baseOid.1.col."hashKey".hashIndex >> >> That would be implemented in the same way as any other >> two-index table. > > Yes, but this has the problem that neither snmptable nor snmpwalk will give > me all the data I'm interested in.
Eh? Both snmptable and snmpwalk (on the baseOid) would give you the whole of the table. i.e. all of the values for all of the hash keys. That's *all* of the data that you're storing in this table. Surely that would include all of the data that you are interested in. > I then need to query each table column separately (with snmpwalk). > So I was looking for a smarter solution If you need a smarter solution, then this probably requires a smarter client application. For example, "snmptable" essentially issues a series of GetNext requests for each row of the table in turn. This is essentially walking the various columns in parallel. You might craft a similar command, (hardcoded to your baseOid) that took a particular hashKey and issued a sequence of GetNext requests for the various columns based on that hashkey i.e. GETNEXT myCol1."hash1" myCol2."hash1" RESPONSE myCol1."hash1".1 myCol2."hash1".1 GETNEXT myCol1."hash1".1 myCol2."hash1".1 RESPONSE myCol1."hash1".2 myCol2."hash1".2 etc stopping when you switch over from "hash1" to "hash2". (which is essentially what snmptable does, except that it looks for a change in the column object) Dave ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Net-snmp-users mailing list [email protected] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
