[SNMP4J] SNMPv3 timing information

[Frank Fock]

Hi Peter,

SNMP4J does not do an automatic rediscovery,
because then the buggy agent would never
have been discovered.

If you want to automatically rediscover, you
have to implement it on application level.

Best regards,
Frank

On 17.06.2010 09:25, Peter Verthez wrote:
> Hello Frank,
>
> I have a small question regarding SNMPv3 timing (engine boots, engine time).
>
> We are managing an agent that does not behave entirely properly
> regarding this timing: in some cases it resets the engine time back to
> 0, but without incrementing the engine boots.   What we see is that we
> as manager are then sending requests according to our knowledge of the
> engine boots/engine time, and these are - rightfully - rejected by the
> agent, because our engine time is higher than the agent's engine time.
> And the agent sends an SNMPv3 report with the usmStatsNotInTimeWindows
> variable.   This is never resolved, unless we force a cleanup in SNMP4J
> of the timing information for that agent.
>
> Of course, the root cause (not incrementing the engine boots in the
> agent) is a bug in the agent, but there is a discussion going on in our
> team now what the proper behaviour of the manager should be.  The
> discussion is whether in such cases, since we are the non-authoritative
> engine in this exchange, the manager (and thus SNMP4J in this case)
> should automatically do a rediscovery of the engine boots/engine time.
> I couldn't immediately find an explanation in the RFCs to counter that
> argument, but it is clear that SNMP4J does not do that.
>
> Could you explain your view on this?
>
> Best regards,
> Peter.
>

-- 
AGENT++
http://www.agentpp.com
http://www.snmp4j.com
http://www.mibexplorer.com
http://www.mibdesigner.com