Re: ifLastChange

From: Marc Lavine (mlavine@foundrynet.com)
Date: 10/01/02

  • Next message: Marc Lavine: "Re: Distributed agent implementation"

    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