Hi,
We were hoping to use a combination of sysUpTime and ifLastChange to
determine when an interface last changed operational status. We were
expecting that:
lastStateChange = now() + sysUpTime.0 - ifLastChange.N
But we've seen a Cisco Catalyst switch (SNMP::Info::Layer3::C6500) host
where ifLastChange.15 is larger than sysUpTime.0. Leading us to falsely
conclude that the interface changed ifOperStatus in the future.
Nasty.
I'm suspecting that the real problem is that sysUpTime.0 has wrapped, since
its type, TimeTicks, is a 32-bit integer, and so it will wrap every 497.1
days / 1.36 years. Yeah, these switches are up for ever between reboots.
That fits.
So I'm assuming that if we encounter an ifLastChange.N that is > sysUpTime.0
we can safely add (at least) 2^32 to sysUpTime.0. Really we could add
N*(2^32) and the last oper change could be N*(2^32) in the past too.
Is there any way to learn more from the equipment than this?
A post on the net-snmp-coders mailing list [1] suggests that
> Managers are supposed to be smart enough that when they
> see a sysUpTime wrap they should deal appropriately with counters and
> treat it as a discontinuity.
>
> and I guess that could work if we have been monitoring since day 1. Is
anybody actually doing this? What algorithm is used if we arrive after its
been booted.
[1]:
http://www.mail-archive.com/[email protected]/msg01705.html
--
Peter Valdemar Mørch
http://www.morch.com
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
