Hi, Are you sure that the below is caused by a clock drift? A reset of the engine boots counter at the manager seems to be more likely.
You are right, that a notInTimeWindow error/report should be returned if the times of sender and responder are not in sync. Doing an automated rediscovery is a security issue. Best regards, Frank On 03.11.2011 17:19, Robert Pierce wrote: > Hi, > We are encountering an issue with particular AMD processors in that the > system clock drifts causing the snmpV3 requests to timeout after some > point. Even once the clock gets resynched, the request will continue to > timeout. > Couple questions: > > 1) Initially, I would of expected a time not in window exception instead of > a timeout? > 2) If I do a discoverAuthoritativeEngineID after it timeouts, the requests > starts working again. My question is it best practice to rediscover the > engine ID on a timeout or exception? Or should I be looking at something > else, such as clearing the usm time table? > > Thanks again for your help. > Robert > _______________________________________________ > SNMP4J mailing list > SNMP4J@agentpp.org > http://lists.agentpp.org/mailman/listinfo/snmp4j -- AGENT++ http://www.agentpp.com http://www.snmp4j.com http://www.mibexplorer.com http://www.mibdesigner.com _______________________________________________ SNMP4J mailing list SNMP4J@agentpp.org http://lists.agentpp.org/mailman/listinfo/snmp4j
