pf_ring and argus

[Nick Diel]

Good info Peter.  I know this question is highly dependent on your packet
size distribution, but I am curious what your threshold is for successful
captures using your setup (where do you start to see noticeable packet
loss)?

The memory mapped solution is quite interesting and would like to hear other
people's experience with it.  From what I gather, with future versions of
the Linux kernel you will be able to throw as much memory as you want to
buffer your capture (think a buffer for a gig link measured in seconds).

I use an Endace card, and as Peter mentions, you can't beat it.  The system
won't even sweat capturing a saturated gig link.  Now the price for one is a
different story, the system itself was cheaper then the card alone.
Speaking of Endace, they recently did an online presentation on using their
cards with Snort, while it is a sales pitch for their card, they do a pretty
good job explaining some of the traditional means of captures.
http://www.endace.com/assets/flash/snort_webinar/endace/files/lobby.html

Nick

On Wed, Apr 9, 2008 at 9:25 AM, Peter Van Epp <vanepp at sfu.ca> wrote:

> On Wed, Apr 09, 2008 at 01:16:11PM +0200, Ole Morten Grod?s wrote:
> >  Hi
> > I'm having some performance problems with my Argus setup. And after
> reading
> > a couple of articles about PF_RING [1,2]. I'm under the impression that
> > PF_RING could help with some of my performance problems. I'm about to
> setup
> > a test environment to test the performance gained from using PF_RING. In
> > regard to this I was wondering if you had any experience with PF_RING
> and
> > Argus. Are there any known problems? Can I expect a large performance
> > improvement?
> >
> > I'm currently running Argus 2. Will that result in any problems? There
> > reason I'm not switching to Argus 3 is mostly due to stability concerns.
> >  I'm also concerned about possible compability issues with my current
> setup.
> >
> >
> >
> > References
> > 1. Performance test of packet sniffing architectures
> > http://luca.ntop.org/Ring.pdf
> > 1 PF_RING User guide
> >
> https://svn.ntop.org/trac/browser/trunk/PF_RING/doc/UsersGuide.pdf?format=raw
> >
> >
> > Regards
> > Grodaas
>
>         With the caveat that we are possibly back level on pf-ring and
> certainly on SUSE (being on 10.1 rather than 10.3) we have been running
> pf-ring
> for a year or more now on an IBM P510 64 bit PPC machine. 2.0.6 won't run
> there, so I haven't tried it with pf-ring but 3.0 works without change so
> I
> expect 2.0.6 will too (pf-ring mimics libpcap).
>        Performance jumps about %50 (the only thing better is Endace DAG
> cards
>  :-)) or more with pf-ring, but I just tried a capture on a saturated gig
> link
> as part of CAIDA's ditl experiment and results weren't good. The busy side
> of
> the link (~800 megs the other side is about 500 megs and I was running two
> identical machines, one on each side of a fdx tap) would hang so hard it
> needed a reboot and basically never functioned correctly. Same when I
> tried
> running argus 3.0 on it with two interfaces on one sensor with disk writes
> going on the other machine. We also have a few quirks (signals don't work
> correctly for instance) which may be because of the dual mods, pf-ring and
> web100 that are in our kernel.
>        The pf-ring code is hard to get in. The kernel mods are extensive
> and
> when last we did it (probably a year or more ago) the code was for a back
> level kernel and we did it to the then current one but it was exciting. It
> may
> be that there have been updates in the interrum and its easier now.
> However if
> I were doing it again I'd probably use Phil Wood's version of memory
> mapped
> libpcap from:
>
> http://public.lanl.gov/cpw/
>
> I believe Russell is running this and perhaps can comment on how its
> working.
> I don't believe it needs kernel mods which is a big plus (to be fair we
> also
> have the web100 stuff for ndt in the same kernel which likely doesn't help
> a lot ...).
>        A late thought strikes: you are running two machines for argus I
> assume?
> The sensor machine has the ethernet cards and argus writing to a socket to
> the archive machine which runs ra reading from the socket and writing the
> archive to disk. At anything above about 100 megs you will lose packets
> due
> to PCI contention on a single machine without DAG cards (which buffer
> packets
> on card and eliminate this issue). If you aren't already in this
> configuration
> thats what I would try first.
>
> Peter Van Epp / Operations and Technical Support
> Simon Fraser University, Burnaby, B.C. Canada
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20080409/b2bbb600/attachment.html>