Re: RFC1155 Timeticks hitting maximum value

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
>

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