ipacc is controlled primarily through its configuration file,
ipacc.cf. The following is an example configuration file, broken
down into its component parts. This is a simple example, of a small
office network, with a single gateway router passing data back to a
single server via Cisco's NetFlow export protocol.
The first major part of the configuration describes the locations of
various chargeable elements in the network. The ip statement
names a network block, and places addresses within the specified address
range within the group. (Note that groups can be nested, and a network
is placed within all the nested groups.)
group office
ip unknown 192.168.1.0/24
ip router 192.168.1.1
ip server 192.168.1.2
ip fred 192.168.1.10
ip jim 192.168.1.11
ip sheila 192.168.1.12
end group
The next part defines how traffic between various parts of the network
is to be charged. In this example, we discard traffic flows that are
completely within the office network as being irrelevant. We count
inbound and outbound traffic. Charge records are will be summarised
down to network (user) name and charge code ("in" or "out"). This is the
default level of summarisation; further detail can be recorded if
necessary.
charge office <> office
charge office -> any - out
charge office <- any - in
The data source definition describes where traffic flow data is coming
from. Data can be obtained via Cisco NetFlow flow exports, packet
sniffing using the Berkeley Packet Filter (BPF) or packet capture
library (libpcap), or extracting data from the IP accounting database on
a Cisco router. In this example, we will be listening for NetFlow data
on UDP port 1999.
Every 10 minutes, collected data will be passed through the charging
engine. (This is the default timing.)
source router
collect netflow 1999
select office
end source
This is an example of a very "friendly" usage report, demonstrating the
formatting capabilities of the summarisation facility. This report will
be run once a day, shortly after midnight local time, and the output
will be mailed to the system administrator. The report will be sorted
by network name.
This highly flexible output formatting allows data to be prepared for
input into billing systems without requiring extra scripts to parse
output and summarise by charge code, protocol etc.
summary report
frequency 1d
dateformat "%d %b %Y"
counter inbound bytes charge in
counter outbound bytes charge out
header "Traffic usage report for <date>"
header ""
header "< /User:-20> </Inbound:10> </Outbound:10>"
format "< network:-20> < inbound:10> < outbound:10>"
trailer ""
trailer "</Totals:-20> < inbound:10> < outbound:10>"
key network
sort network
postprocess "mail -s 'Nightly traffic report' root"
end summary
The final part of the configuration file is the definition of what parts
of the collecting, charging and summarisation process should be done on
which host. Since there is only one collection and summarisation host
in this configuration, it must do all the work. NetFlow and BPF sources
require a collection daemon to capture data in real time. The
process keyword is used to indicate what source or summary
processing should be scheduled on this host.
host server
daemon router
process router
process report
end host
ipacc is intended to be run as a non-privileged user on a FreeBSD
system. When installed correctly, running the ipacc utility without
parameters will launch the ipacc supervisor process under the
ipacc user ID, and in the appropriate directory. ipacc will then
manage its own directories and files appropriately.
ipacc can be run on multiple systems, e.g. to provide a collector
process close to the router collecting NetFlow data, or on multiple BPF
collectors. The exact location of collectors, charging and
summarisation will depend on the network configuration ipacc is to
be deployed on.