Quoting Wes Hardaker <[email protected]>:
Paul S <[email protected]> writes:
From packet analysis, I see that when bulkwalk() is called, the SNMP
library first queries that device's EngineID if this is not already
cached.
SNMPv3 does have a larger start up cost because of this while it does
engine synchronization. It would surprise me that bulkwalk is the only
function with this problem. Are you sure the same symptoms don't occur
with other types of requests (walks or even gets)?
Actually, I'm not sure as I'm only using bulkwalk(), but I have no
doubt that engine synchronisation must happen for walks/gets if its
not already cached.
However, it's not the engine synchronization itself that's the issue -
it's the fact that the engine synchonisation is not handled within
SNMP::MainLoop(). Thus the attempted synchronisation of one
unavailable device blocks the asynchronous SNMP processing of hundreds
of other devices until that single device times-out. There may be a
number of devices unavailable, and all of these will block asynchonous
polling each time they are retried and found to be unavailable.
As an alternative immediate solution I tried to handle the engine
synchonrisation in a separate process, and pass the EngineID via
SecEngineId in SNMP::Session->new() in my code.
If I specify 0 as the EngineID (default, as above), we have the
overhead of the blocking EngineId request (a working device returns
Report 33, usmStatsUnknownEngineIDs increments)
If I specify the correct EngineID, The device replies Report 31,
usmStatsNotInTimeWindows increments, which implies I have the EngineID
correct, but bulkwalk() itself then fails to complete - callback is
immediately called with empty data.
If I specify an incorrect EngineID the device returns Report 33,
usmStatsUnknownEngineIDs increments, and this attempt is retried
before timing-out and the callback called with empty data. This does
not block.
So, specifying a non-zero SecEngineId avoids blocking of bulkwalk as
there is no EngineID synchonrisation happening in the background.
This would solve my issue except it seems bulkwalk() fails even when a
correct EngineID is specified. Any ideas how I might work around this?
Many thanks,
Paul
--
Paul S
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
