Hi John,
thanks very much for your interesting email and for your interest
into the pmacct project. Please follow me inline:
On Sun, Jul 27, 2008 at 08:07:45AM +0000, John Rouillard wrote:
> Just started using pmacct (0.11.5) this evening on a Centos 4.5
> machine. I wanted to aggregate a number of internal networks together
> while retaining individual host stats for hosts that aren't in one of
> those networks.
This is not supported by the networks_file directive. The idea
behind its implementation is simple: a) let people owning an IP
address space to focus onto it; b) deliver data consistent with
the aggregation method selected.
This means it has never been considered to include as part of
the feature either negations (ie. to negate a prefix) or mixing
somehow hosts and subnets. The 0.0.0.0/0 catch it all up entry
is implicit at the end of a prefix list.
An alternate way to accomplish what you would like to, is to
use the pre_tag_map directive along with a filter, in libpcap
style. Pre-Tagging allows to stick a tag to the packet or flow
being considered, which can be used internally (ie. to split
traffic among different plugins) or externally (ie. shown in
the backend to the user).
Applying Pre-Tagging to your specific case means you can split
the traffic: specific traffic can be delivered to a plugin for
subsequent aggregation by the networks_file map, like you are
doing currently; the remaining is delivered to another plugin
and can be even aggregated differently (ie. with more details
to get insights) compared to the one of interest.
The only issue with this approach is that currently the lines
in a Pre-Tag Map are limited to slightly more than 256 chars,
meaning there is space for around 10 prefixes at the most in
the same filter; i can easily extend this by introducing a new
directive to let the user to choose the length of the Pre-Tag
Map line as this already happens for the number of entries the
map can contain, by default 384). I really have this item on
the todo list for quite a while now. Splitting prefixes onto
different filters/tag is doable at the moment but would result
in a less efficient approach. Will let you know as soon as this
feature is committed in the CVS.
Following there is an example of the config:
pmacctd.conf:
...
plugins: memory[in], memory[in2]
!
pre_tag_map: /path/to/pretag.map
!
aggregate[in]: dst_net
pre_tag_filter[in]: 1,2
!
aggregate[in2]: dst_host
pre_tag_filter[in2]: 0
...
pretag.map:
id=1 filter='dst net 192.168.2.0/24 or dst net 192.168.3.0/24 or dst net
192.168.5.0'
id=2 filter='dst net 192.168.7.0/24 or dst net 192.168.9.0/24 or dst net
192.168.12.0'
> How does the "networks_mask" keyword work?
>
> KEY: networks_mask
> DESC: specifies the network mask - in bits - to apply to IP address
> values in L3 header. The mask is applied sistematically and
> (systematically btw)
> before evaluating the 'networks_file' content (if any is
> specified).
>
> This doesn't really tell me how it is applied, and there are no
> matches for networks_mask in the docs directory. If I was to set that
> to 32, would I get what I want? Does it set the default "network" for
> a host using the networks_mask and a more specific mask can be set in
> the networks_file? Hmm, just tried setting that to /24 to see if I got
> a 192.168.10.0 entry in the output above and I didn't so I am truly
> confused as to what this keyword does.
You need to make sure you are using src_net or dst_net primitives (and
not src_host or dst_host) in the aggregate directive. This appears to
not be properly specified in the docs, will take action on this. And
yes, it it set the default "network" for a host using the networks_mask
and a more specific mask can be set in the networks_file.
> Also how are the matches determined in the networks file when there
> are overlapping networks? The first match listed in the file? The most
> specific match?
>
> Given the networks_file:
>
> 192.168.10.0/24
> 192.168.10.0/25
Most specific.
> expect. How do I disable the specification of a networks_file? Using
> 'pmacctd -f config -n /dev/null' doesn't undo the effects of the
> networks_file specification. If I specify a null file "-n '' ", I get
> ERROR: network file '' not found.
A networks_file once defined, can't be reversed commandline but only
modified - it can be nice to add though through the '' string.
> Is using 'pmacctd -C' supposed to cause the daemon to exit if there is
> no "classifiers" keyword in the config file?
no, it's not intended behaviour that the daemon exists in case of a
'pmacct -C', if the classifiers table is not loaded; will look into
that.
> Also for the -c aggregation strings, are the sum_ selectors supposed
> to act like a 'host' keyword in a filter spec?
Precisely.
> And while I am at it, it would be nice to allow:
>
> pmacct -c src_net -N '192.168.0.0/22'
>
> so that CIDR or netmasks could be used to select networks to report
> on.
Might spend a thought at this.
Cheers,
Paolo
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
