>>>>> On Thu, 23 Jun 2011 05:26:04 -0400, <[email protected]> said:
> We are using net-snmp5.2.6 library to communicate with switches SNMP agent. 5.2.6 is rather old at this point, you might consider upgrading to a newer release. > Our manager was working fine for some time without any issues. after > some days the agent starts giving report " usmStatsNotInTimeWindows" > to all GETNEXT queries. we noticed that the enginetime supplied by > manager and enginetime respond by agent is having a huge difference. Huge differences do occur after a while, but they should be small and generally auto-corrected. > Manager : > snmp.msgAuthoritativeEngineBoots:6 > snmp.msgAuthoritativeEngineTime:17501513 > Agent: > snmp.msgAuthoritativeEngineBoots:6 > snmp.msgAuthoritativeEngineTime:2935400 That to me says that the agent's time went backward or the managers time jumped forward way too far. Is there a chance that the agent has been online for more than 200+ days? If the engineTime wraps it should be incrementing the boots value as it resets to 0 again. > When we contact with Agent team , they say that It is a problem from > manager that it is not using the enginetime provided by agent. when I > look deep in code I see that we use " snmp_sess_synch_response" > function of net-snmp and net-snmp lib generates this engineboot, > enginetime values. > We restart the manger and it solves the problem. That's because the manager is synchronizing the time starting from scratch. The SNMPv3 specifications say that a running manager should allow its notion of an agents clock values to go forward, but not backward. Thus, we're doing what we're supposed to do: we won't accept *older* values than what we have cached (but would accept newer values). So, we're following the specifications. The possibilities are: 1) Our code is broken and caching an incorrect value. However, that code hasn't changed in a very long time and it's unlikely this is the problem since it's well vetted and no one else has seen this issue in the 10+ years since it was written. 2) The manager's clock was updated so it was significantly later. 3) The agent's clock was updated so it was significantly older. 4) The agent rebooted and failed to increment the boots number. 5) ??? -- Wes Hardaker Please mail all replies to [email protected] ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
