On 6 July 2011 08:01, Dennis Cua <[email protected]> wrote:
> I know snmp get next takes the next OID not the current.
Pretty much, yes.
It takes a given OID (which may or may not refer to an actual
instance), and returns the next valid instance.
For example, given an integer-based table, rooted at .1.3.6.1.2.1.1.9
the first valid instance would probably be .1.3.6.1.2.1.1.9.1.2.1
So
snmpgetnext .1.3.6.1.2.1.1.9
snmpgetnext .1.3.6.1.2.1.1.9.1
snmpgetnext .1.3.6.1.2.1.1.9.1.1.999
snmpgetnext .1.3.6.1.2.1.1.9.1.2
would all return the value for .1.3.6.1.2.1.1.9.1.2.1
(being the next valid instance - the first entry in the table)
snmpgetnext .1.3.6.1.2.1.1.9.1.2.1
would return the the value for .1.3.6.1.2.1.1.9.1.2.2
(being the next valid instance *after* the specified OID,
i.e. the second entry in the table)
> Is snmp get bulk similar.
Yes.
GetBulk is essentially GetNext on steroids.
It works in exactly the same way, except that rather than returning
a single varbind result, it will return *multiple* values
(the next instance after the specified OID, and the one after that,
and the one after that, etc, etc)
So
snmpbulkget .1.3.6.1.2.1.1.9
would probably return the values for
.1.3.6.1.2.1.1.9.1.2.1 through .1.3.6.1.2.1.1.9.1.2.10 inclusive
> At times it does not display the next OID but the current
What do you mean by "current" ?
SNMP does not have any concept of state, or a "current pointer".
It will always work with the OID that you specify on the command line.
If you run "snmpbulkget {someOID}" you should never get back
a value for {someOID} itself. But you might well issue a GetBulk
request for two or three different OIDs, and get the same results
each time - just as you would with GetNext.
See the example above.
> For example an OID of
> 1.3.6.1.4.1.1971.6.2.9.115.6 is a table. snmpgetbulkget will display
> snmp 1.3.6.1.4.1.1971.6.2.9.116.1 ... 1.3.6.1.4.1.1971.6.2.9.116.10.
That looks as if the agent you are querying does not
implement the table rooted at ....115.6
So it is returning the next ten valid varbinds,
being the first entries in a table rooted at ...116
(If this output is accurate, then there is still a problem, since those
particular OIDS do not form a valid SNMP table anyway!)
> The number of out is equal to the number of column of
> 1.3.6.1.4.1.1971.6.2.9.115.6. At times it is the variables bulk data.
Sorry - that doesn't really make sense.
But the output you list above doesn't have anything to do with
the number of columns in the ...115.6 tree, since the OIDs refer
to a different block of the tree altogether.
The number of values returned is controlled by the -Cn option
to snmpbulkget - which has a default of 10.
Dave
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
