2008/5/8 valantina arumugam :
> Is there a way to differentiate the request from snmpwalk &
> snmpgetnext ?


As Suresh has said, there is no such thing as an "snmpwalk"
request. The agent will simply receive a GETNEXT request.
The structure of this is standard and will look identical - whether
it is a one-off request, or part of a sequence (e.g. from snmpwalk
or snmptable). There are no "request context" flags.
The agent treats each incoming request identically.

> For snmpgetnext request i have to do some operation for xx OID.
> For snmpwalk request , i have to do the same operation
> plus some other functionality for xx OID.

That's simply not possible.
SNMP doesn't work that way.

> Eg :
> snmpwalk of xx table :
> we gather all the instance of xx table data for the 1st getnext req. itself.
> while walk is going on , there is a chance an instance may get
> deleted/added thro' other appln( other than snmp) .which will result
> in displaying of ambiguous data.

That, on the other hand, *is* possible to handle sensibly.

Three options spring to mind.

One would be to have a "last change time" object, which would
be updated whenever a row was added or deleted. The client could
then retrieve the value of this object along with the contents of the
If this value changes during the walking of the table, the app
would know that the results were inconsistent, and could discard
them and start again. This is probably most useful in conjunction
with the GETBULK request, rather than GETNEXT (though it would
work with both).

The second option is to request the data for each row in a single
GETNEXT request, rather than walking through each column in turn.
Even rows were added or deleted during the course of the walk,
the results for each row would at least be consistent.
This is the approach used by the "snmptable" command

Both of these approaches require action at the client side.
The third approach is to handle this purely at the agent side,
by loading all of the data for the table in one go, and caching
it. Incoming SNMP requests would be served from this cache,
regardless of what changes might happen to the underlying data.
The results returned might be a bit out of date, but would at least
be consistent.
That's similar to what you were asking about, but the cache
is marked as invalid based on age, rather than the characteristics
of incoming requests.

The Net-SNMP agent includes just such a cache helper.
Invoke "mib2c -S cache=1 ...." (with most of the table templates)
to generate a suitable framework.


This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
Net-snmp-users mailing list
Please see the following page to unsubscribe or change other options: