[Snort-users] Linux packet loss statistics?

Mike Johnson mike at ...874...
Sat Apr 7 11:53:49 EDT 2001

Phil Wood [cpw at ...440...] wrote:
> Those linux stats are bogus.

Then why are they there?  It's not that I don't beleive you,
but I'm curious as to why the statistics (which didn't
used to be displayed) are now displayed, when they're
One thing I need to point out is that I'm using really
contrived data.  I don't have access to a real world
setting that has anywhere near the amount of data that
I care about.  So, I have to use netperf to generate
the data for me.
> (What happens here is tcpdump goes off and trys to resolve all the ip
> addressess and hangs waiting for the braindead ISP's that are too lazy
> to provide some kind of name for an address.  DNS, what's that?  Even
> if they did resolve the address for you, it take too long, and you lose
> packets)

Again, no real data, so I have to make it up.  DNS isn't
going to slow me down.  However, I decided to run a horribly
parallelized kernel build while capturing packets:
time tcpdump  -i eth1 -c 10000000 > ./cap
tcpdump: listening on eth1
1972452 packets received by filter
0 packets dropped by kernel
real    5m7.458s
user    0m26.140s
sys     0m9.590s

This was during a time that the load on the system was in the
four to five range.  I would have assumed that it would have
been dropping packets all over the place.  
> If I do a tcpdump on linux 2.4.2 kernel (non SMP
> [cause fddi/SMP/2.4.2 outright dies]), I will see packet loss.
> If you read the kernel source, you can see how it is done, and it
> seems reasonable.  I just don't trust the distributions out there,
> and have my own source for libpcap, modified by Alexey K. (ru).  Also,
> I build my own kernel so I know that PACKET_STATISTICS are being created.
> (I also configure the kernel with  CONFIG_PACKET_MMAP, and use some
> gigantic ring buffers.)

Er, I don't see PACKET_STATISTICS in either my 2.2.16 or 2.4.3 
config files.  Do you mean CONFIG_PACKET?  I have that enabled,

I'm pondering working on getting netfilter to dump directly to
snort, which should be about optimum as far as packet filtering
> There is not one OS out there that can capture all the packets we
> see.  You need to spread the load among multiple systems/cpus and use the
> fastest cpu, memory, i/o you can afford on each one.  And then you got
> to figure out where you are going to keep all that information, and for
> how long, but that's another story. 

Well, I'm really going to be operating on much lower bandwidth
networks.  My end goal is to make a resonable descision between
a flavor of Linux or OpenBSD.  Outside of packet capture, they
both have their strengths and weaknesses in our environment.
So, I'm trying to figure out which has the best packet capture
by some quantifyable and repeatable means.

If at first you don't succeed, destroy all evidence that you tried -- unknown

More information about the Snort-users mailing list