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? 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? 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? 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
