pf_ring and argus
Ole Morten Grodås
grodaas at gmail.com
Thu Apr 10 05:52:50 EDT 2008
Thanks for the helpful answers Peter and Nick.
After reading the paper "Improving Passive Packet Capture:Beyond Device
Polling" and the pf_ring user guide I was under the impression that PF_RING
was the most used and most stable option. But after your comments, I'm not
so sure anymore.
As Peter suspects, my main concern at the moment is with a setup where
everything is running on one box and I hoped that the use of pf_ring or
mm-pcap could help.
When running my test I also hope to get a better understanding of the
performance bottlenecks in my system and the performance characteristics off
Argus. I'm therefore a bit curios Peter, how you measure the PCI contention
problems you refer to. I was planning on using systat for performance
monitoring. Are there any better alternatives?
Regards
Grodaas
On Wed, Apr 9, 2008 at 6:21 PM, Nick Diel <nick at engineerity.com> wrote:
> 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/20080410/d0803b11/attachment.html>
More information about the argus
mailing list