pf_ring and argus

Thu Apr 10 09:38:00 EDT 2008

Hey Grodaas,
I will be very interested in your results and opinions on how to make
argus faster.

  For argus-3.1, or argus-3.0.2, depending on our next release target,
I can either go for a smaller memory model, or a better multi-core
design and I'd like to start the discussions as soon as to what would
be the best use of time.

If there is anything I can do to help, please send email to the  
list!!!!!!

Carter

On Apr 10, 2008, at 5:52 AM, Ole Morten Grodås wrote:

> 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/196f8fb2/attachment.html>