Re: [pmacct-discussion] timestamp rounding bug
Hi Paolo, On Mon, 3 Aug 2009, Paolo Lucente wrote: Didn't act on it yet, being focused on some new features. My goal is to do something about it in 0.12.0rc2. Basically it would be a fix for who doesn't use an UTC clock on the system running pmacct. If there is general interest around this story, I'll remember to briefly post here about it the code is committed to the CVS. Btw, i guess the outcome of that thread was a recommendation to run pmacct on a system which is set up for UTC. Maybe this should also be made slightly more visible - maybe inserted into the FAQS document. Is any real-world system set to UTC? I'm certainly not going to run my firewall (where I run pmacct currently) on UTC. All my logs would be screwed up and much harder to interpret. Cheers, Chris. -- Aptivate | http://www.aptivate.org | Phone: +44 1223 760887 The Humanitarian Centre, Fenner's, Gresham Road, Cambridge CB1 2ES Aptivate is a not-for-profit company registered in England and Wales with company number 04980791. ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] timestamp rounding bug
On Tue, Aug 04, 2009 at 10:35:31AM +0100, Chris Wilson wrote: Is any real-world system set to UTC? I'm certainly not going to run my firewall (where I run pmacct currently) on UTC. All my logs would be screwed up and much harder to interpret. i tend to run all my servers in utc. the logs are much easier to match/interpret if they are in different time zones with differing 'summertime' rules... -- ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
[pmacct-discussion] multiple interfaces uni-directional flows
I notice with multiple interfaces that I get duplicate flows. If I recall correctly a cisco router does netflow only on input while it seems pcap captures both inbound outbound packets. My work around to filter out the output flows was to use a pcap_filter such as: ! daemonize: true promisc: false pidfile: /var/run/pmacctd-eth0.pid imt_path: /tmp/pmacctd-eth0.pipe plugins: nfprobe, memory aggregate: src_host,dst_host,src_port,dst_port,proto,tos,flows,tag interface: eth0 syslog: daemon ! filter out packets with the mac address of eth0 pcap_filter: !ether src 00:0c:29:8c:53:7c nfprobe_receiver: 172.16.117.25:2100 nfprobe_version: 5 nfprobe_engine: 1:2 post_tag: 2 Is this the approach others are using with multiple interfaces or is there a better way? Thanks, stig ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] multiple interfaces uni-directional flows
Hi Stig, Very briefly to confirm: a) you are correct, libpcap captures both inbound and outbound traffic and b) the workaround you have put in place not only makes sense but is also by far the most efficient way to filter traffic out of pmacctd. Cheers, Paolo On Tue, Aug 04, 2009 at 10:39:00AM -0700, Stig Thormodsrud wrote: I notice with multiple interfaces that I get duplicate flows. If I recall correctly a cisco router does netflow only on input while it seems pcap captures both inbound outbound packets. My work around to filter out the output flows was to use a pcap_filter such as: ! daemonize: true promisc: false pidfile: /var/run/pmacctd-eth0.pid imt_path: /tmp/pmacctd-eth0.pipe plugins: nfprobe, memory aggregate: src_host,dst_host,src_port,dst_port,proto,tos,flows,tag interface: eth0 syslog: daemon ! filter out packets with the mac address of eth0 pcap_filter: !ether src 00:0c:29:8c:53:7c nfprobe_receiver: 172.16.117.25:2100 nfprobe_version: 5 nfprobe_engine: 1:2 post_tag: 2 Is this the approach others are using with multiple interfaces or is there a better way? Thanks, stig ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] timestamp rounding bug
On 08/04/2009 04:35:31 AM, Chris Wilson wrote: Is any real-world system set to UTC? I'm certainly not going to run my firewall (where I run pmacct currently) on UTC. All my logs would be screwed up and much harder to interpret. Setting the system clock to UTC is traditional in Unix, AFAIK. The obvious reason being that it makes it easy to compare times across systems. It's up to the logging application to decide whether to output UTC, localtime without time zones, localtime with time zones etc. Likewise other programs that produce times for human consumption. The Internet (e.g. rfc2822 and, iirc, rfc5424) tends to solve the human consumption problem by logging in localtime but including an offset from utc in the timestamp. Karl k...@meme.com Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
