[c-nsp] "snmpEngineTime" seems to wrap with "sysUpTime" in old IOS release

[Martin T]

Nathan,

yes, "sysUpTime" wraps after 496 days. However, "snmpEngineTime"
should not wrap before 68 years(or 135 years according to Cisco
documentation). However, my issue is that they both seem to wrap at
the same time.


Chuck,

I think I have this bug:
https://quickview.cloudapps.cisco.com/quickview/bug/CSCeh49492 It
seems to present also in NX-OS code:
https://quickview.cloudapps.cisco.com/quickview/bug/CSCuu82973 ..and
in IOS-XR: https://quickview.cloudapps.cisco.com/quickview/bug/CSCub30579
In addition, looks like other vendors have had issues with exactly the
same thing: https://gtacknowledge.extremenetworks.com/articles/Solution/Securestack-snmpEngineTime-counter-wraps-with-497-days-of-uptime

Based on my testing, Cisco devices running IOS seem to fall into three
categories on this subject:

1) "snmpEngineTime" resets to zero when "sysUpTime" rolls over after
496 days and "snmpEngineBoots" is not incremented. For example IOS
12.0(5)WC14 behaves like this.
2) "snmpEngineTime" resets to zero when "sysUpTime" rolls over after
496 days, but at least "snmpEngineBoots" is incremented at each wrap.
This is in accord with
http://www.net-snmp.org/docs/mibs/SNMP-FRAMEWORK-MIB.txt which says
that "When incrementing snmpEngineTime object's value would cause it
to exceed its maximum, snmpEngineBoots is incremented as if a
re-initialization had occurred, and snmpEngineTime object's value
consequently reverts to zero." For example IOS 12.1(22)EA12 seems to
behave like this.
3) "sysUpTime" rolls over after 496 days and "snmpEngineTime" wraps
after 68/135 years. For example 12.2(50)SE5 seems to behave like this.
Hopefully all newer IOS versions as well(?).

Could somebody confirm this?


thanks,
Martin

On Thu, Apr 6, 2017 at 7:52 PM, Chuck Church <chuckchurch at gmail.com> wrote:
> I'm not sure if the snmpenginetime wrapping would increment the
> snmpEngineBoots, but it would make sense that it would.  If that is the
> case, there are definitely bugs from a 8 or so years ago where devices
> didn't update their snmpEngineBoots counter upon reload.  So you'd reboot
> switch, snmpEngineBoots didn't increment on the device (I guess it's stored
> in NVRAM), and the SNMP manager would stop talking to the device since
> snmpenginetime was no longer what it was expecting, and the snmpengineboot
> hadn't incremented.
>
> Chuck
>
> -----Original Message-----
> From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> Nathan Lannine
> Sent: Thursday, April 6, 2017 12:23 PM
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] "snmpEngineTime" seems to wrap with "sysUpTime" in old
> IOS release
>
>> How to explain this behavior? Is it likely some kind of SNMP agent
>
> I may not have this totally right, but I believe sysUpTime is a 32-bit
> value, which will only go out about 400 and some odd days before it wraps to
> 0.
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/