Re: [Devmon] Template for Cisco WLC 4402 - Problem with uptime in table...

[Richard F. <gol...@gm...>]

On Wed, Feb 9, 2011 at 04:28, Mathias Carlsson
<Mat...@sy...> wrote:
> [transforms]
> UpTimeSec      : MATH              : cLApUpTime / 100
> UpTimeTxt       : ELAPSED               : { UpTimeSec }
>
> Does anybody know what I'm doing wrong?

It's presumably the same issue we ran into this week with a Cisco
3750: a 32 bit counter at 1/100 seconds (centiseconds?) will overflow
in about 497.1 days. Some web pages describe it as a 496 day flaw
instead of a 497 day flaw.

What you could do is see if the following oid is available:
   snmpEngineTime : .1.3.6.1.6.3.10.2.1.3.0 : leaf
If it is then you can use it directly in your transforms:
   snmpUpTimeTxt : ELAPSED : {snmpEngineTime}
And substitute it in the message, and not worry about it for 136 years.

Of course, it will be smaller than what sysUpTime would give, because
the snmp service starts after the device's operating system/kernel is
started. I've seen several instances of 103 or 104 seconds lag, but
also some instances of around 40-50 seconds and some negative values.
I hope the negative offsets are due to ntp updates! :)

Something I hadn't considered until composing this message is that
some creative transforms could determine if the sysUpTime is smaller
than snmpEngineTime, and if so then add 42949672.96 seconds (~497.1
days) to the sysUpTime value. Better yet, instead add 42949673 seconds
multiple times to sysUpTime until the difference vs snmpEngineTime is
minimized (typically less than 3600). But that could be
overengineering, and maybe not possible except for having specific
ranges in a SWITCH transform.

Ah, it's an uptime branch for each AP, not a leaf of the overall
uptime. Well, maybe there's a less granular oid available that doesn't
have a 497.1 day limit. Good luck!