[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Counter32 question

[added mibs mailing list for additional comments or input]

Counters are NOT supposed to be reset. If/when they do get
reset, then we speak of a discontinuity. The idea is that these
counters do not have meaningfull information if you do a GET 
once, You need to do two GETs with some interval, and then
the difference means something. If there is a discontinuity,
during the interval, then you know that you need to discard the 
measurement during that interval.

We have so called ZeroBasedCounter32, but again, it is also
assumed to only start with zero only once. It is not supposed
to be reset to zero with every the connection gets (re-)established.

So if your connection gets established only once, then a ZeroBasedCounter32
might be what you are looking for.

Hope this helps

> -----Original Message-----
> From: Jeffrey Haas [mailto:jhaas@nexthop.com]
> Sent: donderdag 4 september 2003 17:49
> To: Wijnen, Bert (Bert)
> Cc: Jeffrey Haas
> Subject: Counter32 question
> In the bgp MIB (which is past last call except for this one point),
> we have a few objects like this:
>         bgpPeerOutUpdates OBJECT-TYPE
>             SYNTAX     Counter32
>             MAX-ACCESS read-only
>             STATUS     current
>             DESCRIPTION
>                     "The number of BGP UPDATE messages
>                      transmitted on this connection.  This
>                      object should be initialized to zero (0)
>                      when the connection is established.  The
>                      value of this object, when not in the
>                      established state, is undefined."
>             ::= { bgpPeerEntry 11 }
> Note that the counter essentially resets whenever we transition
> to the established state.
> Observation 1: Many implementations don't actually do this.
> Observation 2: Most people say they don't because counters are never
>   supposed to reset.
> What's the veracity of 2?  Do you have any suggestions?
> -- 
> Jeff Haas 
> NextHop Technologies