Re: RFC1155 Timeticks hitting maximum value

Thanks to all on the IETF list for providing solutions and suggestions that could be used to work around the existing 32bit Timetick limit. In our case, our SNMP agent vendor does not currently support snmpEngineTime or snmpEngineBoots. I will ask the developer to look into supporting these objects.

Perhaps another suggestion to the IETF board would be to define a new HC ASN1 Timeticks data type? This would provide compatibility to existing systems using the 32bit Timeticks, and give flexibility to agent developers to use a higher capacity Timeticks data type.

I believe something similar was done with IfInOctets/IfOutOctets when they were extended to "HC" High Capacity 64bit counters in RFC 2863.

On another note, does anyone know a case where a SNMP agent vendor/developer might have "broken the standard" and used 64bit counters for IfInOctets, IfOutOctets or TimeTicks 
Would this break anything in a closed island type Enterprise network? I am considering asking our SNMP agent developer to use 64bit data type for Timeticks on the agent. The NMS system doesn't care or check for standards, it just treats hrSystemUptime as an infinite increasing counter.

-Thanks,
Gene Matusovsky


>>> Mark Ellison <[email protected]> 6/23/2010 9:17 PM >>>
Hi-

I would anticipate that an intelligently designed NMS would watch for wrap
on a TimeTicks object by checking for an increment in snmpEngineBoots, or
alternatively, simply watch the value of the snmpEngineTime object, since
its granularity is seconds rather than 1/100th seconds yielding a 40k+ day
wrap interval.

In any case, the target system sure isn't running a MS OS ;-)

Regards,

Mark
--
http://EllisonSoftware.com/ 

On Wed, Jun 23, 2010 at 7:43 PM, Jon Saperia <[email protected]> wrote:

> But is was in the context specifically of hrSystemUptime - at least that is
> how I read it.  I was suggesting a surgical fix to a specific problem
> related to uptime.  That could be fixed with a single object and leave the
> others that use time ticks intact.
>
> That said, I do agree with you that a good NMS should be able to deal with
> this and other oddities in this and many other objects.
>
> /jon
> On Jun 23, 2010, at 7:30 PM, Randy Presuhn wrote:
>
> > Hi -
> >
> >> From: "Jon Saperia" <[email protected]>
> >> To: "Randy Presuhn" <[email protected]>
> >> Cc: <[email protected]>
> >> Sent: Wednesday, June 23, 2010 3:54 PM
> >> Subject: Re: [OPS-AREA] RFC1155 Timeticks hitting maximum value
> >>
> >> Why would a whole new set of objects be required to either fix,
> >> hrSystemUptime, or create a new higher capacity object?
> >
> > The question wasn't just about hrSystemUptime, but the fundamental
> > deficiency of time ticks.
> >
> > Coming up with a new time ticks syntax would effectively mean
> > every existing time ticks object would at least need to be
> > considered for obsolescence, and new objects would need
> > to be created in appropriate cases.  Counters currently referencing those
> > time ticks objects as discontinuity indicators would then have to be
> > considered for update as well, unless we were going to say that
> > implementations MUST support both representations.  (This quickly
> > becomes a replay of the 32-bit counter / 64-bit counter / paired-counter
> > discussion from SMIv2.)
> >
> > But that really wouldn't address the problem - an existing NMS
> > application that behaves badly when hrSystemUptime wraps.
> >
> > Randy
> >
> > _______________________________________________
> > OPS-AREA mailing list
> > [email protected] 
> > https://www.ietf.org/mailman/listinfo/ops-area 
> >
>
> _______________________________________________
> OPS-AREA mailing list
> [email protected] 
> https://www.ietf.org/mailman/listinfo/ops-area 
>


-------------------------------------------------------- 
The information transmitted in this email and any of its attachments is intended only for the person or entity to which it is addressed and may contain information concerning Cablevision and/or its affiliates and subsidiaries that is proprietary, privileged, confidential and/or subject to copyright.   Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient(s) is prohibited and may be unlawful.  If you received this in error, please contact the sender immediately and delete and destroy the communication and all of the attachments you have received and all copies thereof.
--------------------------------------------------------