Hi Adam, libpcap (and similar solutions) capture the traffic before it is passed on to the netfilter (iptables) framework. So what you will be monitoring with pmacct will be the unfiltered traffic.
HTH. Regards, Ruben On Thursday 16 August 2007, Adam Niedzwiedzki wrote: > I have another query. > > This is my setup very basic. > > Internet --> eth0 - leaf router/firewall - eth1 --> switch > > The leaf box is my router and of course my firewall as well, will pmacct > take it flows AFTER iptables has "firewalled" my net, or is it lower, as in > all flows? > > Cheers > Ad > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Paolo Lucente > Sent: Friday, 10 August 2007 3:13 AM > To: [email protected] > Subject: Re: [pmacct-discussion] Small simple setup, just want to know if > I'm doing this right.. > > Hi Adam, > > please follow my replies inline: > > On Wed, Aug 08, 2007 at 09:04:18AM +1000, Adam Niedzwiedzki wrote: > > For only counting bytes,protocol,ip,port do I just need a v1 sql table? > > Yes, that's enough. You can even think at stripping the unused fields to > make the table smaller and activate the "sql_optimize_clauses" directive > in your config. > > > I wish to be able to at least store down to the hourly data transferred > > per > > > IP/port of my servers. > > I was thinking of building queries that roll an hours worth of counts > > into > > a > > > table then deleting the original data, has anyone tried/done this? > > I wouldn't see any problem in having such sliding-window kind of approach. > I would just be careful at looking at the amount of tuples the "src_host, > src_port" and "dst_host,dst_port" couples might generate - ie. a trivial > port scan against a public IP subnet. If the subnet is somehow filtered in > a way that the boxes can't receive packets on any possible port but only > on specific ones, then you should be OK. Otherwise it's as simple as ... > you have to give it a try and see whether the footprint is too large to > be easily manageable. > > > Should I use a filter for my ip range? (I don't quite understand the > > filter > > > side of things, if my class c is 202.45.102.0/24 is that what I add as an > > aggregate_filter) > > Yes, you have to add the following lines to your config: > > aggregate_filter[in]: dst net 202.45.102.0/24 > aggregate_filter[out]: src net 202.45.102.0/24 > > > Here is what I plan to run as my config has anyone got any tips on what I > > should add? > > debug: false > > logfile: /var/log/pmacct.log > > daemonize: true > > promisc: false > > interface: eth1 > > > > plugins: mysql[in], mysql[out] > > > > aggregate[in]: dst_port,dst_host,proto > > sql_table[in]: acct_in > > > > aggregate[out]: src_port,src_host,proto > > sql_table[out]: acct_out > > > > sql_host: xx.xx.xx.xx > > sql_db: pmacct > > sql_table_version: 1 > > sql_passwd: xxxx > > sql_user: pmacct > > sql_refresh_time: 10 > > sql_optimize_clauses: true > > sql_history: 5m > > sql_history_roundoff: mh > > If possible, i would just get that sql_refresh_time a bit more loose: say, > 60 > secs. If you don't need nearly real-time data, you can even raise the value > to > 300 secs (5 mins, ie. matching the sql_history value in your config) and > avoid > UPDATE queries at all - which translates in huge savings on CPU resources. > If > you go for it, then you need to add the "sql_dont_try_update" directive. > > Cheers, > Paolo > > _______________________________________________ > pmacct-discussion mailing list > http://www.pmacct.net/#mailinglists > > > _______________________________________________ > pmacct-discussion mailing list > http://www.pmacct.net/#mailinglists _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
