On Aug 29, 2013, at 8:33 AM, Terry Rohmannan <[email protected]> wrote:
> Hi all > > I seem to experience similar issue, what is the difference between > reflect_packet_and_stop_rule_evaluation and > reflect_packet_and_continue_rule_evaluation? > does reflect_packet_and_stop_rule_evaluation mean that after reflecting the > first packet matched the rule will be removed? No, this means the following rules are not evaluated. > or it means that the packet is reflected but not forwarded into user space? Right Alfredo > > thanks, > Terry > > > 2013/8/28 Alfredo Cardigliano <[email protected]> > Hi Assamak > please read inline > > On Aug 23, 2013, at 6:54 PM, b n <[email protected]> wrote: > >> Hi Alfredo, >> >> thanks for your response. >> >> 1. In linear scan do you mean that for each packet an iteration is performed >> across all rules, until a match is found? > > Yes > >> By "optimized data structure for ip rules" I reckon that I should use the >> same bloom test performed in the exact rules, only modified so that it >> should test for the ip address alone. Do you have any suggestions of a >> comfortable library as a starting point? should it be implemented via a >> plugin? >> >> 2. No I didn't load any plugin. I simply opened a ring, and added only one >> rule to it - a wildcard rule that bounces all packets (full of zeroes). Then >> I called the function discussed. I'll look into it a bit more. >> >> 3. In that context, what happens to a packet that matches a filtering rule, >> whose action is to reflect the packet? >> is it still queued in the pfring queue? > > This depends on the action you set, reflect_packet_and_stop_rule_evaluation > or reflect_packet_and_continue_rule_evaluation. > >> I am aiming towards collecting stats of the packets that arrive to the >> server. the stats should be collected from all packets- those bounced and >> those that didn't (stats would be- distribution of flags, type of layer 4 >> protocol etc...). How do you suggest doing that? via pfring_recv or >> pfring_loop? or by writing a plugin? > > I would do it via pfring_loop or pfring_recv (they are equivalent, it depends > on your application) rather than in a plugin to simplify the porting to DNA > whether you need it in future. > > Best Regards > Alfredo > >> >> thanks again, >> Assamak. >> >> >> >> 2013/8/23 Alfredo Cardigliano <[email protected]> >> Hi Assamak >> please read below >> >> On Aug 22, 2013, at 7:37 PM, b n <[email protected]> wrote: >> >> > Hi guys, >> > >> > I have 3 questions, and I thank you in advance for reading them :) >> > >> > 1. efficiency of wildcard filters >> > I'm trying to develop a pfring based application that bridges traffic from >> > one nic to another, by ip address. >> > After reading the user guide and the tutorial I thought of implementing it >> > using pfring's wildcard filtering, i.e. define 2 rules for each ip >> > address. in the first rule the address will be the src, and in the other >> > it will be the dst. >> > However I couldn't find any reference as to how that is implemented, and >> > what is the efficiency of the implementation. Is it a variant of the bloom >> > test used in the precise filters? >> >> No, a linear scan is used in case of wildcard filters. >> >> > I need the application to support thousands of ip address (maybe even tens >> > of thousands), with high bandwidth (10 Gbps nic). >> >> For 10 Gbit I would recommend you to use DNA/Libzero, with an optimized data >> structure for ip rules. >> >> > 2. wildcard rules stats retrievel >> > Another thing is retrieving the stats of each wildcard rule. The return >> > type isn't mentioned anywhere. Also, the user guide says it returns >> > "number of received and dropped packets", but grepping >> > "pfring_get_filtering_rule_stats" in the example folder gives another >> > view: (taken from pfcount) >> > rc = pfring_get_filtering_rule_stats(pd, 5, (char*)&stats, &len); >> > if(rc < 0) >> > fprintf(stderr, "pfring_get_filtering_rule_stats() failed >> > [rc=%d]\n", rc); >> > else { >> > printf("[Pkts=%u][Bytes=%u]\n", >> > (unsigned int)stats.num_pkts, >> > (unsigned int)stats.num_bytes); >> > >> > also, when I tried a small test application, in which i set one wildcard >> > filtering rule,and set the action to >> > "reflect_packet_and_continue_rule_evaluation", with the above code the >> > values were stuck in- >> > "[Pkts=1][Bytes=0]" >> > does anyone have any experience with the function? >> >> pfring_get_filtering_rule_stats() retrieves user-defined stats from the >> kernel plugin bound to the filtering rule, if any. >> The sample plugin used by pfcount is PF_RING/kernel/plugins/dummy_plugin.c. >> Did you load it? >> >> > 3. pushing packets into the ring, and from it >> > I can't fully understand the way pfring manages the ring. Does it wait for >> > the application to free slots by reading packets, and only then pushes in >> > newly arrived packets? >> >> Yes >> >> > in what situation would there be packet drops? >> >> When the application can't keep up with incoming packets and ring is full. >> >> > if my application is slower than line rate what packets will be dropped >> > the oldest? or the newer? >> >> Newer. >> >> Best Regards >> Alfredo >> >> > >> > thanks, >> > Assamak >> > _______________________________________________ >> > 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
