spamcontrol2@xxxxxxxxx wrote:
> Has anyone done any serious performance testing of
Ethereal/libpcap/tcpdump as
> regards network capture performance?
>
> I'm curious if there have been any studies done as to how well the
capture lib
> holds up under various network load conditions on various platforms -
> particularly while saving to disk.
>
> For example, with a reasonably powerful system (let's say a
Dual-Athlon MP 1800
> system with a couple of gig of Dual-DDR RAM, and a fairly fast
striped RAID
> array that should handle 80MB/s) running Linux, what is the maximum
data rate I
> should expect to be able to capture? At what rate do I begin to drop
packets
> (and therefore at what rate should I expect packets to be saved
reliably)?
>
> I'm trying to decide whether it'd be feasable to build an open
source/free
> software-based capture device. I rarely need to capture rates larger
than
> 350Mbit/s, but I have yet to find a single commercial (all
Windows-based, of
> course) package that can come close to keeping up with this rate
_while saving
> to disk_.
1) It all depends
2) It still depends.
3) :)
Seriously, I've been doing I speed packet capture off of our network for
the past 2.5 years. Originally I started with a OC3(155MB) monitor based
off the designs for CoralReef (www.caida.org). However, we recently
moved off of ATM to GigE and consolidated our commodity (non-research I2
network) into one interface off of a Juniper. This gives me a max of
540Mbits to montitor but usually its closer to 420Mbits.
Now, we're using optical so we slip in a pair of optical splitters
leading off to 2 GigE interfaces (SysKonnect) as the actual packet
collection point. I then just use libpcap to grab header data from each
interface - the problem is that if I try to capture from both interfaces
at the same time I always end up losing 10% to 50% of the packets -
which if you are doing sampling isn't that bad but thats way too high
for what I'm doing. Anyway, so what I've decided to do is alternate the
capture sequence - collect 3.5 million packets from one interface and
then switch to the other - I kind of cheat in that I'm not intrested in
individual packets but in the flow data so everything gets piped
directly into the CoralReef crl_flow analyzer (it produces netflow and
netmetra like results). This what I don't have to deal with disk
bottleneck. I then do a whole bunch of fun stuff with the flow data
(match it to routing tables, port analysis, basic DoS analysis and so
forth). At this point I'm capturing around 1 out of every 3 packets in
either direction. Once I port to C and get it on a better platform I
should be doing a lot better though.
Now, I'm kind of hamstrung by my capture hardware - I have a dual CPU
system (albeit 800Mhz PIII) but I've read that the SMP handling actually
reduces the total IO capability of the system because of that overhead.
Being that you are mostly interested in being able to handle a whole lot
of interruts being thrown off at any one time this is a problem. Still
this is a YMMV sort of thing.
In a lot of ways I've given up trying to capture duplex streams from
this optical set up on a single box. Being that I have two strands
(optical being 2 half duplex streams) its easy to drop it into two boxes
- the problem at that point becomes one of timing - if the boxes fall
out fo sync then its more difficult to reintegrate the streams - you can
use a GPS based timer (see the IPPM sites about this) or you can set up
a timing beacon on the network and have the system constantly update
their clocks from there...
In any case - there has been a lot of work on this sort of thing from
the universities and that might be your best place to start your
research - particularly CAIDA's CoralReef and OCxMon.
Chris Rapier
Pittsburgh Supercomputing Center
Network Research Programmer
