Re: sequence_number/sample_pool question?

Hello,

It is better to detect the reset based primarily on the sequence
number. You should use an unsigned subtraction so that 32-bit
rollovers are handled gracefully (see below), but if you see a large
jump in the sequence number (maybe 50 or more) then you should not
accumulate the sample_pool delta that time. When there is a reset, the
next sample should start again with sequence number = 1. Of course,
that packet might be lost in transit, so you can't rely entirely on
seeing it. That's why you also need to detect any large jump and treat
it as a reset too.

With the above scheme there are still one or two corner cases where you
have to be careful. For example, if the last sequence number was
4294967289 (0xFFFFFFF9) and there was a reset but the next datagram was
lost, then you might see the next sequence number = 2 and not detect
the reset (because the delta was only 9). To help protect against
that you might add a sanity check limiting the maximum sample_pool
delta you are prepared to accept.

Just to be absolutely clear about the unsigned 32-bit rollover thing,
here is an example in C:

u_int32_t delta32(u_int32_t newValue, u_int32_t oldValue) {
        return (newValue - oldValue);
}

delta32(6, 5) = 1
delta32(2, 4294967289) = 9

regards,
neil

On Mar 3, 2005, at 5:50 AM, jo@atsresults.com wrote:

> How does an sflow collector know when the agent has "reset the
> sample_pool"?
>
> I am writing my own collector and I want to know if any datagrams have
> bee lost.
> Is the correct procedure to check the "current" sample_pool value
> against the
> "last" sample_pool value and if the current is smaller they "reset" the
> sequence_number?
>
> Does this sound right?
>
> Thanks for your help
>
> unsigned int sequence_number;
> /* Incremented with each flow sample
> generated by this source_id.
> Note: If the agent resets the
> sample_pool then it must
> also reset the sequence_number.*/
>
>
----------
Neil McKee
http://www.inmon.com
Received on Thu Mar 3 08:55:14 2005