From: Marc Lavine (mlavine@foundrynet.com)
Date: 10/01/02
Rather than ifLastChange, I think the more appropriate MIB variable to use
would be ifCounterDiscontinuityTime (see RFC 2863, section 3.1.5 for
details):
ifCounterDiscontinuityTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime on the most recent occasion at which
any one or more of this interface's counters suffered a
discontinuity. The relevant counters are the specific
instances associated with this interface of any Counter32 or
Counter64 object contained in the ifTable or ifXTable. If
no such discontinuities have occurred since the last re-
initialization of the local management subsystem, then this
object contains a zero value."
::= { ifXEntry 19 }
Requiring the sFlow sample sequence numbers to be reset seems to be an
equivalent solution, though. I suggest that it be documented with reference
to ifCounterDiscontinuityTime. Essentially, for ifIndex-based data sources,
if the value of ifCounterDiscontinuityTime changes, then the counter sample
sequence number for the corresponding data source should be reset.
Also, I think the phrase "affects the sample_pool" needs some clarification.
If I understand the intent correctly, how about saying:
Note: If the agent resets the
sample_pool value then it must
also reset the sequence_number.
*/
Marc
----- Original Message -----
From: Peter Phaal <peter_phaal@inmon.com>
To: 'Neil McKee' <neil_mckee@inmon.com>; <sflow@sflow.org>
Sent: Monday, September 30, 2002 11:11 AM
Subject: RE: [sFlow] ifLastChange
> Neil,
>
> As you point out it is important to identify reset counters that might
> affect the analysis of sFlow data. In addition to counter_samples, a
silent
> reset of the sample_pool counter could cause problems in interpreting
> flow_samples.
>
> It seems that the simplest and most general solution would be to define
the
> reset semantics for the flow_sample/counter_sample sequence numbers in
> SFLOW-DATAGRAM:
>
> struct flow_sample {
> unsigned int sequence_number; /* Incremented with each flow sample
> generated by this source_id.
> Note: If a source_id reset affects
> the sample_pool then the
> sequence_number must also be
> reset. */
> sflow_data_source source_id; /* sFlowDataSource */
> ..
>
> struct counters_sample {
> unsigned int sequence_number; /* Incremented with each counter sample
> generated by this source_id
> Note: If a source_id reset affects
> any of the counters being
> reported
> then the sequence_number must
be
> reset. */
> sflow_data_source source_id; /* sFlowDataSource */
> ..
>
> I've made these changes and posted a new version of SFLOW-DATAGRAM
> http://www.sflow.org/drafts/draft7/SFLOW-DATAGRAM.txt
>
> Explicitly indicating counter resets has advantages over using a broadly
> defined variable such as ifLastChange. ifLastChange will indicate a change
> when the status of an interface changes (for example from up to down).
> Typically interface status changes do not involve counter resets. Forcing
an
> sFlow receiver to discard counter state on each status change would cause
> uneccessary errors in tracking interface statistics.
>
> Peter
> ----------------------
> Peter Phaal
> InMon Corp.
>
> Peter_Phaal@inmon.com
>
>
> > I notice that the ifLastChange variable (or equivalent) is
> > missing from
> > the counter samples. ifLastChange is useful for detecting when the
> > hardware interface counters have been reset. Otherwise there is a
> > danger of generating an erroneous "spike" when accumulating
> > deltas from
> > one sample to the next.
> >
> > IfLastChange is defined in RFC 2863 like this:
> >
> > ifLastChange OBJECT-TYPE
> > SYNTAX TimeTicks
> > MAX-ACCESS read-only
> > STATUS current
> > DESCRIPTION
> > "The value of sysUpTime at the time the interface entered
> > its current operational state. If the current state was
> > entered prior to the last re-initialization of the local
> > network management subsystem, then this object contains a
> > zero value."
> > ::= { ifEntry 9 }
> >
> > neil
>
>
This archive was generated by hypermail 2.1.4 : 10/01/02 PDT