Re: RFC1155 Timeticks hitting maximum value

Gene,

I am not aware of the existence of "a need by the community to increase the
Timeticks maximum limit".  You are of course welcome to write and submit an
internet-draft that describes this need and a solution.

Regards,

Mark


On Fri, Jun 25, 2010 at 11:15 AM, Gene Matusovsky
<[email protected]>wrote:

> Mark, thanks for the suggestion. I will look into upgrading our agent to a
> SNMPv3 compliant.
>
> Going back to general question, given today's technological advances in
> memory and flash memory capacities, since when RFC 1155 was written, and
> being that there is a need by the community to increase the Timeticks
> maximum limit, can a suggestion be made to the IETF to create a new a "High
> Capacitity" Timeticks ASN.1 data type?
>
> -Thanks,
> Gene
>
> >>> Mark Ellison <[email protected]> 6/24/2010 4:38 PM >>>
> Gene,
>
> Agreed, not everyone has development resources.
>
> However, consider for a moment what you are asking for-  an "HC" version of
> hrSystemUptime.  "HC" counters were introduced for the IF-MIB to handle
> wrap
> situations that could occur every few minutes.  In the original post in
> this
> thread, it was noted that hrSystemUpTime can wrap once every 497 days-
> approximately every 16 months.
>
> Even if an "HC" version of hrSystemUptime were designed, it would still
> need
> to be implemented within the agents that the NMS will monitor- this would
> take development resources, just as would implementing snmpEngineBoots and
> snmpEngineTime.  Since the agent being monitored does not support these two
> objects, one can safely assume that agent does not support SNMPv3.  In
> order
> to support 64-bit counters, at least SNMPv2c is required since SNMPv1 does
> not provide support for "HC" 64-bit counters.  Note that an agent that
> implements SNMPv3 can be configured to allow retrieval of the
> snmpEngineTime
> and snmpEngineBoots values via SNMPv2c or SNMPv1 protocol messages.
>
> So, if the agent needs to be changed anyway to support a new object, the
> approach that appears obvious to me, would be to upgrade the agent to
> include compliant support for SNMPv3, which would make available the
> snmpEngineBoots and snmpEngineTime objects for use with the NMS.
>
> Hope this helps!
>
> Regards,
>
> Mark
> http://EllisonSoftware.com
>
> On Thu, Jun 24, 2010 at 3:00 PM, Gene Matusovsky
> <[email protected]>wrote:
>
> > Workarounds are possible, and can be done, but not everyone has
> development
> > resources. With todays technology and higher capacity systems, the root
> of
> > the issue can be addressed directly by extending RFC 1155/ 1902 Timeticks
> > data type. This was done before with RFC 2863, when IfInOctets was
> updated
> > to IfHCInOctets.
> >
> > Are there any existing SNMP workgroups or ongoing projects. Perhaps this
> > can be suggested to them, to attach to the next published RFC?
> >
> > Any pointers would be appreciated.
> >
> > -Thank You,
> > Gene Matusovsky
> >
> > >>> Jon Saperia <[email protected]> 6/24/2010 12:57 PM >>>
> > Others may, but I am not aware of an implementation of hrSystemUptime as
> a
> > 64-bit value.  One other solution that would not require a MIB object
> change
> > since you seem to have development resources available is to fix the NMS.
>  A
> > simple solution is to watch for the counter wrap in a way that is similar
> to
> > what people have done for interfaces.
> >
> > Your suggestion about exploring HC timeticks data objects is interesting,
> > but that would require a working group taking up the activity.
> >
> > /jon
> > On Jun 24, 2010, at 11:57 AM, Gene Matusovsky wrote:
> >
> > > 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.
> > > --------------------------------------------------------
> > >
> >
> >
> > --------------------------------------------------------
> > 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.
> > --------------------------------------------------------
> > _______________________________________________
> > 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.
> --------------------------------------------------------
>

_______________________________________________
OPS-AREA mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ops-area