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

RE: Counter32 question



Hi,

What happens if bgp initializes before snmp during startup, and the bgp
connection is established before the snmp agent starts counting? What if
20 or 100 updates have already been transmitted? Will an application
(manager) know that the value is wrong?

SNMP counters are designed to ensure that the manager, by polling twice
and including a continuity indicator in each poll, can determine the
value at the beginning of the measured period and at the end of the
measured period, and whether any counter discontinuities occurred during
the period being measured.

bgpPeerOutUpdates cannot provide those assurances about having gotten
the values at the beginning and end of the period and the continuity of
measurements during the period.

I recommend using an explicit discontinuity indicator rather than
sysUpTime because sysUpTime has its own discontinuities to worry about.

Being proactive rather than reactive, let me anticipate the next
suggestion:

A common response to being told you should not use automatically
resetting counters is to try to define a user-resettable counter, so the
user can choose the start and end points of the period and not have to
do the delta math. This typically doesn't work because SNMP supports
multiple users with interlaced access to managed objects, and user B's
reset could cause a discontinuity during user A's measurement period. 

Hope this helps,
dbh

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] 
> Sent: Thursday, September 04, 2003 6:15 PM
> To: 'Jeffrey Haas'; Wijnen, Bert (Bert)
> Cc: 'mibs@ops.ietf.org'
> Subject: 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
> Bert 
> 
> > -----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
> > 
> 
>