Re: RFC1155 Timeticks hitting maximum value
Jon Saperia <[email protected]>
| Newsgroups | gmane.ietf.ops |
|---|---|
| Message-ID | <[email protected]> |
Why would a whole new set of objects be required to either fix, hrSystemUptime, or create a new higher capacity object? /jon On Jun 23, 2010, at 6:17 PM, Randy Presuhn wrote: > Hi - > >> From: "Gene Matusovsky" <[email protected]> >> To: <[email protected]> > > You'd be better off sending this to the MIB doctors list, > [email protected] > >> Sent: Wednesday, June 23, 2010 2:08 PM >> Subject: [OPS-AREA] RFC1155 Timeticks hitting maximum value >> >> RFC1155 defines TimeTicks as a non-negative integer, with a maximum value of 4294967296. >> >> In our environment, this limiting the hrSystemUptime object id 1.3.6.1.2.1.25.1.1.0 to 497 days, at which point the counter rolls > and resets back 0. >> This causes our NMS system to display in-accurate information from our field SNMP agents for their hrSystemUptime values. > > The snide response is to suggest getting another NMS. > > But the reality is that hrSystemUptime has obvious limitations, > which the NMS developer should have understood when deciding > how to display it. > >> Is there any workarounds to this problem we're facing? Are there any plans to increase the RFC1155 definition of TimeTicks to a > higher 64 bit integer value? > > I am not aware of any such plans. Making such a change would require > the creation of a whole new set of objects. In many cases, however, the > TimeTicks approach no longer makes sense. You might also take a look > at the material on snmpEngineBoots and snmpEngineTime in RFC 3414 > to see how a closely related issue was dealt with. > > Randy > > > _______________________________________________ > OPS-AREA mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ops-area >