Detect packet drops

[Peter Van Epp]

On Tue, Feb 07, 2012 at 04:54:48PM +0100, elof2 at sentor.se wrote:
> On Thu, 2 Feb 2012, Peter Van Epp wrote:
> >>>The duplicates,
> >>>such as multiple copies of the exact same packet, is detectable and I put code in to do
> >>>this, although I don't have any packet files that have the conditions that you describe to
> >>>verify if they are correct or not, so I haven't finished the support.
> >
> >	As doing this properly is likely to be a performance hog at high link
> >speeds it may be that argus isn't the right place to do it. In theory given
> >proper change control (which I well know isn't a given :-)) this should be
> >only a problem when a switch configuration change is made by the network folks.
> >I suspect the correct answer is a standalone libpcap application that checks
> >for this error (multiple copies of an identical packet) on the monitored link
> >and flags it. At high line speeds it too will have performance problems (it
> >is very expensive in memory bandwidth to compare two packets) but since thats
> >all its doing its impact can be less. It also should be a persistant thing
> >so checking once an hour or once a day may be enough to detect the condition
> >and correct it.
> 
> You are quite correct.
> 
> I already got tcpdump, tshark and ngrep, so another tool for just
> measuring duplicates as well as detecting gaps would be sufficient
> for me, since I could perform spot tests every now and then instead
> of wasting cpu resources in argus.
> The problem is just that no such tool seem to exist. :-(
> 

	Then you need to roll your own :-). Easy to say but not so easy to do
unfortunatly. Given that you have DAGs, thats where I would do this. The DAG
internal CPU could compare the current packet to the last one received fairly
efficiently since it is in internal memory and doesn't impact the host bus
as doing it in pcap would (of course doing one in pcap would be much more 
portable to people withoug DAGs :-)). At high line rates it may however still 
impact performance because internal memory bandwidth may be an issue, so as 
always testing would need to be done, which as always is its own problem because
generating line rate traffic to test with is hard and/or expensive. 

Peter Van Epp