Funny you say that, because I encountered the same "problem" OP did, and thought like you. However, I have a few switches where the snmpEngineId counter seems to be reset when sysUpTime rolls over. Can anyone confirm this?

switch 1:

---------

IOS (tm) C2950 Software (C2950-I6K2L2Q4-M), Version 12.1(22)EA10, RELEASE SOFTWARE (fc2)

"sh version | inc uptime" gives "uptime is 1 year, 19 weeks, 6 days, 4 hours, 9 minutes", however:

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (61089443) 7 days, 1:41:34.43

SNMP-FRAMEWORK-MIB::snmpEngineTime.0 = INTEGER: 610894 seconds

switch 2:

--------

Cisco IOS Software, C3550 Software (C3550-IPSERVICESK9-M), Version 12.2(35)SE3, RELEASE SOFTWARE (fc1)

"sh version | inc uptime" gives "uptime is 1 year, 19 weeks, 2 days, 13 hours, 52 minutes"

however:

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (30114018) 3 days, 11:39:00.18

SNMP-FRAMEWORK-MIB::snmpEngineTime.0 = INTEGER: 301059 seconds

and finally switch 3 (which seems fine):

Cisco IOS Software, 3800 Software (C3845-ADVIPSERVICESK9-M), Version 12.4(13b), RELEASE SOFTWARE (fc3)

"sh version | inc uptime" gives "uptime is 1 year, 19 weeks, 2 days, 14 hours, 16 minutes"

however:

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (30173291) 3 days, 11:48:52.91

SNMP-FRAMEWORK-MIB::snmpEngineTime.0 = INTEGER: 43251371 seconds

This is caused by CSCeh49492. This is fixed in 12.2(40)SE for your 3550, but not fixed at all for the 2950.

Also note, that a bug was raised about the sysUpTime limitations a long time ago (CSCdm72652):

"Currently, IOS based devices rely on RFC1213's sysUpTime which is a 32 bit

counter in 1/100 second and wraps around every 496 days.

This makes it difficult to tell how long the device has been up if the counter has

rolled over.

Workarounds: The uptime value in the show version output is accurate even

after 496 days.

Routers running 12.0(3)T or higher can also use the snmpEngineTime object from

the SNMP-FRAMEWORK-MIB. This object keeps track of seconds since the

SNMP engine started. While not as granular as sysUpTime, it will not roll

over for 135 years. By polling both sysUpTime and snmpEngineTime together, then

taking the full value of sysUpTime and combining it with the additional two

digits from snmpEngineTime, one can gain additional granularity. Note, if

sysUpTime is polled right during roll-over, time will change +/- one year."

Hi folks,

I know that this is an old post but I have a question about this with regards to the iflastchange timestamps. I have multiple 4506's on the network where the sysuptime counters have rolled over multiple times, this is causing a bit of frustration when trying to understand how long an interface has been dormant for. What I would like to know is when an interface state is mark as changed on a device whos sysuptime counter has rolled over multiple times, does the time stamp taken represent:

a time stamp, in ticks since the beginning of the last roll over

or

does it represent a time stamp in ticks since the last reload (Power up)?

I'm talking raw data here, time ticks polled directly from the iflastchange table.

The reason I ask is that if the first is true then consider this:

If after 5 minutes from when the device powers up interface gig1/1's state is marked as changed. From that point onwards the interface state never changes. Now imagine that it's 5 minutes after the 1st roll over and interface G2/2's state changes. Both interfaces Gig 1/1 and Gig2/2's iflastchange time tick time stamp will show 5 min but only Gig1/1 will be accurate. In this case usuang the SNMPEngine time is useless as the time stamps are taken from a rolled over 32bit counter. I sincerly hope this is not the case.

However if the timestamps are taken based on a none rolled over sysuptime counter like the one we see in the 'sh ver', this would be much more advantageous and would allow for the use of the SNMPEngine time. Considering the same scenario as above if after 1 rollover the time stamps for Gig1/1 should represent 5 min and the time tick time stamp for gig2/2 should represent 496days and 5min. I hope this is the case as it provides more posibilities

when transforming the iflastchange output info.

If you require any further elaboration please let me know

Kind Regards

Ciaran

The value represents the value of sysUpTime at the moment the interface last changed state.  Your description of two interfaces that show "five minutes" for ifLastChange is correct.  To properly detect these kind of rollovers, your NMS will have to remember the values of ifLastChange so long as snmpEngineTime doesn't roll over.

Joseph,

thank you very much for your reply. That's cleared that up for me now thank you. A 64 bit counter is really needed with this counter but we'll have to make do until the current RFC is bettered.

Thanks again

Ciaran