Re: Improving the data supplied by BPF

[christos%astron.com@localhost (Christos Zoulas)]

In article 
<1a69a9d80812261732j10c9ec4bgdcd085768f58c4b6%mail.gmail.com@localhost>,
Arnaud Lacombe <lacombar%gmail.com@localhost> wrote:
>Hi,
>
>On Fri, Dec 26, 2008 at 7:43 PM, Jim Wise <jwise%draga.com@localhost> wrote:
>> "Arnaud Lacombe" <lacombar%gmail.com@localhost> writes:
>>> 2^32 1500-bytes packets is about 6TB of data, on 100Mbit link, the
>>> sequence number will wrap after 5.6 days (if you consider
>>> uni-directional traffic), on a 1Gb link, half a day and a bit more
>>> than 1 hour on a 10Gb link. This is the worst case scenario. Two
>>> records taken at the <wrap_time> interval will likely collide on
>>> high-load link.
>>
>> Will they?  Wouldn't you have to not sample for a whole <wrap period>
>> for it not to be immediately obvious that a wraparound had occurred?
>>
>no, think about the case where you set up a low pass filter in tcpdump
>to monitor only some event. In this case, sequence number got consumed
>by high frequency events and the wrap can happen in background.
>
>> Is an application which wants to fill a 100MB link, but not sample more
>> than once every five days what we should be designing for?
>>
>no, the timestamp will help to discern and to tell if wrap occurred.
>If two records have the same timestamp (we only have microsec.
>precision now) the seq number will give you their order. If two
>records have the same seq number, but not the same timestamp, then you
>can say that wrap occurred and you'll do the distinction based on
>timestamp. You are in trouble if a record has the same timestamp and
>seq number :-)
>
>Note that the wrap can happens sooner than the 5.6 days if the packets
>sent are smaller.
>
> - Arnaud
>

Well, we can make the counter 64 bits...


christos