RE: ifLastChange

From: Peter Phaal (
Date: 09/30/02

  • Next message: Marc Lavine: "Re: ifLastChange"


    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

    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

    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
                                               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

    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 Phaal
    InMon Corp.

    > 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
    > "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 : 09/30/02 PDT