Changing cluster mode should not affect performance. Alfredo
On Mar 8, 2013, at 9:18 PM, J of Core <[email protected]> wrote: > One more question about the tuple hashing -- does changing this setting (ie, > setting it to a higher 4,5, etc tuple value) affect the throughput or > performance of pf_ring at all? I'm trying to determine the best setting for > sharing the load in relation to the traffic that I might expect -- but the > actual setting may not be determined until a later time when traffic is > actually flowing. And I'm just wondering if there are performance effects of > changing this value, ie, more processor intensive, etc..? > > Thanks! > > > On Tue, Mar 5, 2013 at 2:02 PM, J of Core <[email protected]> wrote: > Sweet, I think I have a somewhat better understanding now. > > Thanks! > > > On Tue, Mar 5, 2013 at 12:47 PM, Alfredo Cardigliano <[email protected]> > wrote: > On Mar 5, 2013, at 4:48 PM, J of Core <[email protected]> wrote: > >> I was wondering if someone would be so kind as to explain how the >> clustermode / tuple hashing affects how pf_ring runs. I did some reading on >> tuples, but it's still a bit unclear to me. > > In linux/pf_ring.h there are some comments describing each cluster mode: > > cluster_per_flow = 0, /* 6-tuple: <src ip, src port, dst ip, > dst port, proto, vlan> */ > cluster_round_robin, > cluster_per_flow_2_tuple, /* 2-tuple: <src ip, dst ip > > */ > cluster_per_flow_4_tuple, /* 4-tuple: <src ip, src port, dst ip, dst port > > */ > cluster_per_flow_5_tuple, /* 5-tuple: <src ip, src port, dst ip, dst > port, proto > */ > cluster_per_flow_tcp_5_tuple, /* 5-tuple only with TCP, 2 tuple with > all other protos */ > >> Should the number that is set for the cluster mode be related to the number >> of pf_ring / snort instances that I'm running? > > No, the cluster mode represent the way the hash is computed on the packet, > then the packet is delivered to the instance hash%num_instances. > >> Or is it determined some other way? Basically I'm trying to understand how >> to determine what number would be good to set for the clustermode, or if I >> should just leave it alone. > > If you are not sure, leave the default. > > Best Regards > Alfredo > >> >> Thanks! >> >> On Fri, Mar 1, 2013 at 3:43 PM, Alfredo Cardigliano <[email protected]> >> wrote: >> Please make sure your traffic is well balanced (i.e. that you are not using >> test traffic with a single flow), by default a 2-tuple hashing is used, you >> can change this setting using the clustermode parameter as reported in >> PF_RING/userland/snort/pfring-daq-module/README.1st >> >> --daq-var clustermode=<mode> >> >> Best Regards >> Alfredo >> >> On Mar 2, 2013, at 12:30 AM, J of Core <[email protected]> wrote: >> >>> Thanks for the reply, Jesse. I tried running multiples w/diff pid files, >>> log files, etc, but when I watch the counters I still only see one instance >>> increasing. >>> >>> I also did s'more searching online and found this on the metaflows google >>> group: >>> https://groups.google.com/forum/?fromgroups=#!topic/metaflows/Tjagd3MPr70 >>> >>> According to that post, I should be able to "run the command twice with the >>> same exact arguments and they will slip the traffic. The pfring kernel >>> module will automatically detect how many processes are running and split >>> the traffic accordingly" -- but that isn't working for me either. That >>> post is from 2011 so I'm not sure if things have changed since then or not. >>> >>> So not sure what I'm missing to make it distribute the traffic between >>> processes/instances. I'll keep investigating / testing :) >>> >>> thx >>> >>> >>> On Fri, Mar 1, 2013 at 12:46 PM, Jesse Bowling <[email protected]> >>> wrote: >>> Hi Kevin, >>> >>> This is what I get for reading in reverse order. :) >>> >>> You are correct in what you wrote: you do have it up and running it would >>> seem. To run more instances, you need to start multiple instances of snort >>> and make sure that you pass them the same clusterid. >>> >>> The only tricky part is making sure that each snort instance has it's own >>> PID file, config file, logging directory, etc; that's usually the hardest >>> part of getting multiple snort instances up. :) >>> >>> There are a few strategies for managing the snort instance configs, but the >>> one I've seen described that I liked the most was to create a vanilla >>> config that expresses the things you want for every instance, and then >>> create individual configs for each instance specifying only the things that >>> are different and including the vanilla one. For instance: >>> >>> snort.master.conf: >>> >>> config interface: eth0 >>> include /rules/SOme_rule_file >>> etc >>> >>> and then: >>> >>> inst1.conf: >>> >>> config logdir: /nsm/snort/inst1 >>> include snort.master.conf >>> >>> That makes it a little easier to maintain your conf files... >>> >>> GL, >>> >>> Jesse >>> >>> On Fri, Mar 1, 2013 at 2:46 PM, Kevin Hanser <[email protected]> wrote: >>> So I appear to have pf_ring installed (via the RPMs) and snort working with >>> it. If I start up a snort instance using a command line similar to the >>> metaflows article (except I'm doing passive instead of inline for the time >>> being): >>> >>> snort -c /etc/snort/snort.conf -y -i eth0 --daq-dir /usr/local/lib/daq >>> --daq pfring --daq-var clusterid=10 --daq-mode passive >>> >>> I get a status counter "device" created in /proc/net/pf_ring named >>> <pid>-eth0.1. If I watch this file with cat while sending some traffic to >>> the machine, I see the counters increasing, and snort is logging the >>> information. So based on this, it seems that snort is working with >>> pf_ring, which was my "first step" so that's pretty cool. >>> >>> Now I'm trying to figure out how I distribute the load across multiple >>> snort / pf_ring instances. I started up multiple instances of snort, but >>> when I watch the counters it seems that only the one I started last is >>> getting all the traffic. I'm probably missing something in how I start it >>> up, but I'm unsure what. >>> >>> What do I need to tell pf_ring / snort so that they distribute the load >>> across the multiple rings / snorts? Is that what the clusterid=10 means? >>> Is that telling each pf_ring that it's part of the same cluster? I'm still >>> working on understanding how all this works together so if anyone has any >>> thoughts / suggestions that would be great! I'll keep researching and >>> reading and testing on my own as well, >>> >>> thx! >>> >>> _______________________________________________ >>> Ntop-misc mailing list >>> [email protected] >>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>> >>> >>> >>> >>> -- >>> Jesse Bowling >>> >>> >>> _______________________________________________ >>> Ntop-misc mailing list >>> [email protected] >>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>> >>> >>> _______________________________________________ >>> Ntop-misc mailing list >>> [email protected] >>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >> >> >> _______________________________________________ >> Ntop-misc mailing list >> [email protected] >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >> >> >> _______________________________________________ >> Ntop-misc mailing list >> [email protected] >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc > > > _______________________________________________ > Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc > > > > _______________________________________________ > Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc
_______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
