Hi Dennis,
Two points about your email:
* the 0.0.0.0 -> 0.0.0.0 traffic originated when using a networks_file
cannot be filtered out by pmacct itself since all filtering stages at
that point are already passed. You should essentially remove yourself
such tuples from the backend.
* aggregate_filter, performance impact, etc.: the email you reference
is about a combination of two factors: a sustained capture rate and
a long/complex filter, ie. 90 networks per filter. On simpler filters
the directive is not that CPU impacting. Hence question here is about
which scale you have to do such filtering and whether pre_tag_map can
be of help instead. Also with these solutions you can see if filtering
based on known MAC addresses applies.
Cheers,
Paolo
On Thu, Oct 25, 2012 at 02:38:27AM +0200, Dennis Jacobfeuerborn wrote:
> Hi,
> I'm currently experimenting with pmacct and I think I have found a good
> configuration that works but there is one problem:
>
> In order to account all local hosts I aggregate like this:
> aggregate[in]: dst_host
> aggregate[out]: src_host
>
> I'm testing this on my local net at home and my networks file only contains
> the net 192.168.2.0/24 and the net only contains my desktop system and the
> DSL router. As a result I only expected to see traffic from 192.168.2.118
> -> 0.0.0.0 and 0.0.0.0 -> 192.168.2.118 but I'm also seeing traffic
> aggregated as 0.0.0.0 -> 0.0.0.0.
> After looking at the counters it became clear that this was basically the
> traffic flowing in the "other" direction relative to the aggregation
> instance ("in" and "out").
>
> All of this is fine but since accounting this traffic isn't really useful I
> am wondering if there is a way to prevent this from being written to the
> database? As I understand it this is what the aggregate_filter directive is
> for but as I've read in this thread this directive has a significant
> negative performance impact:
> http://www.mail-archive.com/pmacct-discussion%40pmacct.net/msg01984.html
>
> Is there a better way to filter this? Also I'm wondering if it would be
> useful to have a directive that would allow to discard packet early that
> basically result in a NULL record. By that I mean entries where all the
> aggregated fields end up being zero. There may be cases where you still
> want to have these naked counters but in my trivial accounting case I'm
> only interested in traffic incoming where dst_host is actually useful
> information rather than 0.0.0.0.
>
> Regards,
> Dennis
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
