Hi Evgeniy, It might be better (more maintanable) to use a different approach for your task. Remove the aggregate_filter and go for pre-tagging:
pre_tag_map: /path/to/pretag.map pre_tag_filter[bla]: 0 refresh_maps: true pre_tag_map_entries: <say 1000? it's an upper bound anyway> It means filter in traffic tagged as 0 (no tag effectively). Then build /path/to/pretag.map as follows (with the idea what is being tagged with id == 1 within the map is then being discarded): id=1 ip=<NetFlow exporter IP address> filter='dst net <IX net, ie. 192.168.0.0/16> and not dst net <local net, ie. 192.168.100.0/24>' id=1 ip=<NetFlow exporter IP address> filter='src net <IX net, ie. 192.168.0.0/16> and not src net <local net, ie. 192.168.100.0/24>' ... You can indeed merge the two rules above in a single one, i did not do it just for readability. My current understanding of your goal is that you want to bill customer/customer traffic but not customer/IX and vice-versa. Cheers, Paolo On Wed, Sep 19, 2012 at 12:19:45AM +0300, Evgeniy Kozhuhovskiy wrote: > Thanks a lot, it works for now. > > Also i have another question, related to pcap filter. > > I have a list of networks in our IX. It has some big networks that > includes small networks > that are announced from our AS. > For example, we have 192.168.0.0/16 and 172.16.0.0/16 in IX, > but 192.168.100.0/24 and 172.16.100.0/24 are our clients networks. > > Of course, we need to bill traffic from/to our clients > (192.168.100/24, 172.16.100.0/24), but we dont need to bill > traffic to 192.168.0.0/16 and 172.16.0.0/16. > > I wrote such rule: > aggregate_filter[dsmgr]: (net not 192.168.0.0/16 and net not > 172.16.0.0/16) and (net 192.168.100/24 or net 172.16.100.0/24) > > but this filter returns no traffic at all (because it removes our > customers networks from result). Where I'm wrong in filter? > > On Tue, Sep 18, 2012 at 7:05 PM, Paolo Lucente <[email protected]> wrote: > > > > Hi Evgeniy, > > > > You are doing all good except aggregate_filter need to be bound to > > a specific plugin, can't be global. The daemon is surely spitting an > > error out about that. Please rewrite the two following lines and try > > again: > > > > plugins: print[bla] > > aggregate_filter[bla]: net not 178.120.0.0/13 > > > > It should be that the daemon is logging errors somewhere, you might > > want to add a 'logfile' directive for catching errors, etc. > > > > Cheers, > > Paolo > > > > On Tue, Sep 18, 2012 at 04:38:47PM +0300, Evgeniy Kozhuhovskiy wrote: > > > Hello. > > > > > > We're using some proprietary software (dsmgr by ispsystems), that uses > > > nfacctd as it's part to calculate traffic usage (by netflow/sflow). > > > > > > By default dsmgr generate such nfacctd config: > > > daemonize: true > > > plugins: print > > > aggregate: src_host,dst_host > > > nfacctd_port: 9995 > > > print_refresh_time: 900 > > > print_output: csv > > > print_output_file: /var/flowstat/%Y:%m:%d-%H:%M > > > > > > and csv file is processed via proprietary utility runned from cron. > > > > > > We need to exclude some networks (in fact, our local IX) from billing. > > > I've added this line: > > > aggregate_filter: net not 178.120.0.0/13 > > > to config. (178.120.0.0/13 is one of networks that we dont need to bill) > > > > > > But traffic from this network still goes to csv file: > > > > > > debian:/var/flowstat# cat 2012\:09\:18-16\:23 | grep 178.120 | head -4 > > > > > > 0,0,unknown,00:00:00:00:00:00,00:00:00:00:00:00,0,0,0,0,0,0,,0,0,0,0,,,0,0,0:0:0,178.120.88.201,178.172.181.110,0,0,0,0,0,ip,0,1072,0,75723 > > > > > > 0,0,unknown,00:00:00:00:00:00,00:00:00:00:00:00,0,0,0,0,0,0,,0,0,0,0,,,0,0,0:0:0,178.172.181.128,178.120.217.213,0,0,0,0,0,ip,0,22085,0,16089127 > > > > > > 0,0,unknown,00:00:00:00:00:00,00:00:00:00:00:00,0,0,0,0,0,0,,0,0,0,0,,,0,0,0:0:0,178.172.181.95,178.120.60.190,0,0,0,0,0,ip,0,1695,0,159303 > > > > > > 0,0,unknown,00:00:00:00:00:00,00:00:00:00:00:00,0,0,0,0,0,0,,0,0,0,0,,,0,0,0:0:0,178.120.112.234,178.172.181.64,0,0,0,0,0,ip,0,1326,0,120156 > > > > > > Where i'm wrong? > > > -- > With best regards, Evgeniy Kozhuhovskiy _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
