On 10/27/2012 02:40 AM, Paolo Lucente wrote:
> 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.
What I was proposing was adding that ability since this kind of "anonymous"
accounting often is not necessary/desired. By "anonymous" I mean packets
where most fields have been zeroed because of the aggregate definition and
where the fields in the aggregate definition end up being zero because they
aren't part of the local networks.
Another way of putting it is that it would be nice to have a setting "if
the packet doesn't come from go to any of the local networks stop all
processing and ignore it".
> * 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.
I don't have to deal with 90 networks but still a significant number. Also
the problem is that there is now a duplication of information as I have to
put all the networks both in the networks file and the aggregate filter and
keep them in sync.
I'm not sure if I understand how to use pre_tag_map or MAC filtering in my
use-case. Let's assume I have the uplink port to my ISP mirrored to my
monitoring system and I'm accounting on that interface and my local
networks are A, B, C and D. How can I only aggregate the in/out traffic for
IPs in these networks without resorting to aggregate_filter?
Regards,
Dennis
> 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
>
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
