pmacct [IP traffic accounting : BGP : BMP : RPKI : IGP : Streaming Telemetry]
pmacct is Copyright (C) 2003-2020 by Paolo Lucente
Q1: What is pmacct project homepage ?
A: pmacct homepage is http://www.pmacct.net/ . pmacct is also present on GitHub at
the URL: https://github.com/pmacct/pmacct .
Q2: 'pmacct', 'pmacctd', 'nfacctd', 'sfacctd', 'uacctd', 'pmtelemetryd',
'pmbgpd' and 'pmbmpd' -- but what do they mean ?
A: 'pmacct' is the name of the project; 'pmacctd' is the libpcap-based IPv4/IPv6
accounting daemon; 'nfacctd' is the NetFlow (versions supported NetFlow v1,
v5 and v9) and IPFIX accounting daemon; 'sfacctd' is the sFlow v2/v4 and v5
accounting daemon; 'uacctd' is the Linux NFLOG-based accounting daemon
(historically, it was using ULOG, hence its name); 'pmtelemetryd' is the
Streaming Telemetry collector, where "Streaming telemetry [ .. ] data can be
used for analysis and troubleshooting purposes to maintain the health of the
network. This is achieved by leveraging the capabilities of machine-to-machine
communication. [ .. ]" (quoting Cisco IOS-XR Telemetry Configuration Guide at
the time of this writing); 'pmbgpd' is the pmacct BGP collector and 'pmbmpd'
is the pmacct BMP collector.
Q3: Does pmacct stand for Promiscuous mode IP Accounting package?
A: Not anymore, it was originally though: pmacct was born as a libpcap-based traffic
collection project only. Over the time it evolved to include NetFlow first, sFlow
shortly afterwards and NFLOG more recently. Latest additions being in the areas
of BGP, BMP, RPKI and Streaming Telemetry. However the unpronounceable name
'pmacct' remained as a distinctive signature of the project.
Q4: What are pmacct main features?
A: pmacct can collect, replicate and export network information. On the data plane
(ie. IPv4/IPv6 traffic) it can cache in memory tables, store persistently to
RDBMS (MySQL/MariaDB, PostgreSQL, SQLite 3.x), noSQL databases (key-value:
BerkeleyDB 5.x via SQLite API or document-oriented: MongoDB) and flat-files
(CSV, formatted, JSON, Apache Avro output), publish to AMQP and Kafka brokers
(ie. to insert in ElasticSearch, InfluxDB, Druid or ClickHouse). Export sFlow
v5, NetFlow v5/v9 and IPFIX. pmacct is able to perform data aggregation,
offering a rich set of primitives to choose from; it can also filter, sample,
renormalize, tag and classify at L7. On the control and infrastructure planes it
can collect and publish to AMQP and Kafka brokers BGP, BMP, RPKI and Streaming
Telemetry data both standalone and as correlation/enrichment of data plane
Q5: Do pmacct IPv4/IPv6 traffic accounting daemons log to flat files?
A: Yes. Each micro-flow (NetFlow, IPFIX and sFlow) or packet (libpcap, NFLOG) can
be written to a flat-file for a two-stages approach, ie. a) write all down to
persistent storage then b) consolidate stats to build the desired view(s). Also
pmacct always aimed to offer a single-stage approach so to get immediate view(s)
of the traffic and this be achieved leveraging data reduction tecniques and
correlation tools to process network traffic data on the fly. pmacct writes to
files in text-format (JSON, Avro, CSV or formatted via 'print' plugin, and JSON
or Avro via Kafka and AMQP plugins, see QUICKSTART doc for further information)
so to maximize integration with 3rd party tools while keeping low the effort of
Q6: What are the options to scale a pmacct deployment to match input data rate?
A: There are two dimensions to it: 1) scale within the same instance of pmacct: make use
of data reduction tecniques part of pmacct, ie. spatial and temporal aggregation,
filtering, sampling and tagging. As these features are fully configurable, going from
full micro-flow visibility to - say - node-to-node IP network traffic matrix, data
granularity/resolution can be traded off for scalability/resources consumption; 2)
divide-and-conquer input data over a set of pmacct instances by either balancing or
mapping data onto collectors. See next point, Q7, for libpcap; the 'tee' plugin can
be used for this purpose for NetFlow, IPFIX and sFlow.
Q7: I see my libpcap-based daemon (pmacctd) taking much CPU cycles; is there a way to
reduce the load?
A: CPU cycles are proportional to the amount of traffic (packets, flows, samples) that
the daemon receives; in case of pmacctd it's possible to reduce the CPU share by
avoiding unnecessary copies of data, also optimizing and buffering the necessary
ones. Kernel-to-userspace copies are critical and hence the first to be optimized;
for this purpose you may look at the following solutions:
Linux kernel has support for mmap() since 2.4. The kernel needs to
be 2.6.34+ or compiled with option CONFIG_PACKET_MMAP. You need at
least a 2.6.27 to get compatibility with 64bit. Starting from 3.10,
you get 20% increase of performance and packet capture rate. You
also need a matching libpcap library. mmap() support has been added
in 1.0.0. To take advantage of the performance boost from Linux
3.10, you need at least libpcap 1.5.0.
PF_RING, http://www.ntop.org/PF_RING.html : PF_RING is a new type of network socket
that improves the packet capture speed; it's available for Linux kernels 2.6.32 and
newer. It needs a kernel module to be loaded, it's device driver independent and
has libpcap support for seamless integration with existing applications.
NetMap, http://info.iet.unipi.it/~luigi/netmap/ : Netmap is a BSD-licensed framework
that supports line-rate direct packet I/O even on 10GBit/s interfaces (14.88Mpps)
with limited system load, and includes a libpcap emulation library to port
Internal buffering can also help and, contrary to the previous tecniques, applies
to all daemons. Buffering is enabled with the plugin_buffer_size directive; buffers
can then be queued and distributed with a choice of an home-grown circolar queue
implementation (plugin_pipe_size) or a ZeroMQ queue (plugin_pipe_zmq). Check both
CONFIG-KEYS and QUICKSTART for more information.
Q8: I want to to account both inbound and outbound traffic of my network, with an host
breakdown; how to do that in a savy fashion? Do i need to run two daemon instances
one per traffic direction?
A: No, this is a toy case where you will be able to leverage the pluggable architecture
of the pmacct daemons: you will run a single daemon with two plugins attached to it;
each of these will get part of the traffic (aggregate_filter), either outbound or
inbound. A sample config snippet follows:
aggregate_filter[inbound]: dst net 192.168.0.0/16
aggregate_filter[outbound]: src net 192.168.0.0/16
plugins: mysql[inbound], mysql[outbound]
It will account all traffic directed to your network into the 'acct_in' table and
all traffic it generates into 'acct_out' table. Furthermore, if you actually need
totals (inbound plus outbound traffic), you will just need to play around with
basic SQL queries.
If you are only interested into having totals instead, you may alternatively use
the following piece of configuration:
Where 'networks.lst' is a file where to define local network prefixes.
Q9: I'm intimately fashioned by the idea of storing every single flow flying through my
network, before making up my mind what to do with such data: i basically would like
to (de-)aggregate my traffic as 'src_host, dst_host, src_port, dst_port, proto' or
'src_host, dst_host, src_port, dst_port, proto, timestamp_start, timestamp_end'. Is
this feasible without any filtering?
A: If such data granularity is required by the use-case addressed, ie. DDoS, forensics,
security, research, etc. then this can be achieved no problem with pmacct - you have
only to be careful planning for the right amount of system/cluster resources. In all
other cases this is not adviceable as this would result in a huge matrix of data -
meaning increased CPU, memory and disk usage - for no benefit - plus, to be always
considered, the impact of unexpected network events (ie. port scans, DDoS, etc.) on
Q10: I use pmacctd. What portion of the packets is included into the bytes counter ?
A: The portion of the packet accounted starts from the IPv4/IPv6 header (inclusive) and
ends with the last bit of the packet payload. This means that are excluded from the
accounting: packet preamble (if any), link layer headers (e.g. ethernet, llc, etc.),
MPLS stack length, VLAN tags size and trailing FCS (if any). This is the main reason
of skews reported while comparing pmacct counters to SNMP ones. However, by having
available a counter of packets, accounting for the missing portion is, in most cases,
a simple math exercise which depends on the underlying network architecture.
Example: Ethernet header = 14 bytes, Preamble+SFD (Start Frame Delimiter) = 8 bytes,
FCS (Framke Check Sequence) = 4 bytes. It results in an addition of a maximum of 26
bytes (14+8+4) for each packet. The use of VLANs will result in adding 4 more bytes
to the forementioned 26.
Q11: What is historical accounting feature and how to get it configured?
A: pmacct allows to optionally define arbitrary time-bins (ie. 5 mins, 1 hour, etc.)
and assign collected data to it basing on a timestamp. This is in brief called
historical accounting and is enabled via *history* directives (ie. print_history,
print_history_roundoff, sql_history, etc.). The time-bin to which data is allocated
to is stored in the 'stamp_inserted' field (if supported by the plugin in use, ie.
all except 'print', where to avoid redundancy this is encoded as part of the file
name, and 'memory'). Flow data is by default assigned to a time-bin basing on its
start time or - not applying that or missing such info - the timestamp of the whole
datagram or - not applying that or missing such info - the time of arrival at the
collector. Where multiple choices are supported, ie. NetFlow/IPFIX, the directive
nfacctd_time_new allows to explicitely select the time source.
Q12: Counters via CLI are good for (email, web) reporting but not enough. What are the
options to graph network data?
A: An option could be to use traditional graphing tools like RRDtool, MRTG and GNUplot
in conjunction with the 'memory' plugin. The plugin works as a cache and offers a
pull mechanism, the pmacct IMT client tool, that allows to easily retrieve counters:
shell> ./pmacctd -D -c src_host -P memory -i eth0
shell> ./pmacct -c src_host -N 192.168.4.133 -r
Et voila'! This is the bytes counter. Because of the '-r', counters will get reset
or translating into the RRDTool jargon, each time you will get an 'ABSOLUTE' value.
Let's now encapsulate our query into, say, RRDtool commandline:
shell> rrdtool update 192_168_4_133.rrd N:`./pmacct -c src_host -N 192.168.4.133 -r`
Multiple requests can be batched as part of a single query, each request can be ';'
separated via CLI or read from an input file (one query per line):
shell> ./pmacct -c src_host,dst_host -N 192.168.4.133,192.168.0.101;192.168.4.5,192.168.4.1;... -r
shell> ./pmacct -c src_host,dst_host -N "file:queries.list" -r
shell> cat queries.list
A second option, perhaps the most current of the two, is to leverage one of the
many modern data analytics stacks that do typically comprise of data manipulation,
storage and visualization. Like the ELK stack (ElasticSearch, Logstash, Kibana) or
the TICK stack (Telegraf, InfluxDB, Chronograf, Kapacitor). Many more, free and
Q13: The network equipment i'm using supports sFlow but i don't know how to enable it.
I'm unable to find any sflow-related command. What to do ?
A: If you are unable to enable sFlow commandline, you have to resort to the SNMP way.
The sFlow MIB is documented into the RFC 3176; all you will need is to enable a SNMP
community with both read and write access. Then, continue using the sflowenable tool
available at the following URL: http://www.inmon.com/technology/sflowenable
Q14: When i launch either nfacctd or sfacctd i receive the following error
message: ERROR ( default/core ): socket() failed. What to do ?
A: When IPv6 code is enabled, sfacctd and nfacctd will try to fire up an IPv6 socket.
The error message is very likely to be caused by the proper kernel module not being
loaded. So, try either to load it or specify an IPv4 address to bind to. If using a
configuration file, add a line like 'nfacctd_ip: 192.168.0.14'; otherwise if going
commandline, use the following: 'nfacctd [ ... options ... ] -L 192.168.0.14'.
Q15: SQL table versions, what they are -- why and when do i need them ? Also, can i
customize SQL tables ?
A: pmacct tarball gets with so called 'default' tables (IP and BGP); they are built
by SQL scripts stored in the 'sql/' section of the tarball. Default tables enable
to start quickly with pmacct out-of-the-box; this doesn't imply they are suitable
as-is to larger installations. SQL table versioning is used to introduce features
over the time without breaking backward compatibility when upgrading pmacct. The
most updated guide on which version to use given a required feature-set can be,
once again, found in the 'sql/' section of the tarball.
SQL tables *can* be fully customized so that primitives of interest can be freely
mixed and matched - hence making a SQL table to perfectly adhere to the required
feature-set. This is achieved by setting the 'sql_optimize_clauses' configuration
key. You will then be responsible for building the custom schema and indexes.
Q16: What is the best way to kill a running instance of pmacct avoiding data loss ?
A: Two ways. a) Simply kill a specific plugin that you don't need anymore: you will
have to identify it and use the 'kill -INT <process number>' command; b) kill the
whole pmacct instance: you can either use the 'killall -INT <daemon name>' command
or identify the Core Process and use the 'kill -INT <process number>' command. All
of these, will do the job for you: will stop receiving new data from the network,
clear the memory buffers, notify the running plugins to take th exit lane (which
in turn will clear cached data as required).
To identify the Core Process you can either take a look to the process list (on
the Operating Systems where the setproctitle() call is supported by pmacct) or
use the 'pidfile' (-F) directive. Note also that shutting down nicely the daemon
improves restart turn-around times: the existing daemon will, first thing, close
its listening socket while the newly launched one will mostly take advantage of
the SO_REUSEADDR socket option.
Q17: I find interesting store network data in a SQL database. But i'm actually hitting
poor performances. Do you have any tips to improve/optimize things ?
A: Few hints are summed below in order to improve SQL database performances. They are
not really tailored to a specific SQL engine but rather of general applicability.
Many thanks to Wim Kerkhoff for the many suggestions he contributed on this topic
over the time:
* Keep the SQL schema lean: include only required fields, strip off all the others.
Set the 'sql_optimize_clauses' configuration key in order to flag pmacct you are
going to use a custom-built table.
* Avoid SQL UPDATEs as much as possible and use only INSERTs. This can be achieved
by setting the 'sql_dont_try_update' configuration key. A pre-condition is to let
sql_history == sql_refresh_time. UPDATEs are demanding in terms of resources and
are, for simplicity, enabled by default.
* If the previous point holds, then look for and enable database-specific directives
aimed to optimize performances ie. sql_multi_values for MySQL and sql_use_copy for
* Don't rely automagically on standard indexes but enable optimal indexes based on
clauses you (by means of reports, 3rd party tools, scripts, etc.) and pmacct use
the most to SELECT data. Then remove every unused index.
* See if the dynamic table strategy offered by pmacct fits the bill: helps keeping
SQL tables and indexes of a manageable size by rotating SQL tables (ie. per hour,
day, week, etc.). See the 'sql_table_schema' configuration directive.
* Run all SELECT and UPDATE queries under the "EXPLAIN ANALYZE ..." method to see
if they are actually hitting the indexes. If not, you need to build indexes that
better fit the actual scenario.
* Sometimes setting "SET enable_seqscan=no;" before a SELECT query can make a big
difference. Also don't underestimate the importance of daily VACUUM queries: 3-5
VACUUMs + 1 VACUUM FULL is generally a good idea. These tips hold for PostgreSQL.
* MyISAM is a lean SQL engine; if there is no concurrence, it might be preferred to
InnoDB. Lack of transactions can reveal painful in case of unsecured shutdowns,
requiring data recovery. This applies to MySQL only.
* Disabling fsync() does improve performance. This might have painful consequences
in case of unsecured shutdowns (remember power failure is a variable ...).
Q18: Does having the local timezone configured on servers, routers, etc. - which can
very well include DST (Daylight Saving Time) shifts - impact accounting?
A: It is good rule to run the infrastructure and the backend part of the accounting
system as UTC; for example, accuracy can be negatively impacted if sampled flows
are cached on a router while the DST shift takes place; plus, pmacct uses system
clock to calculate time-bins and scanner deadlines among the others. In short,
the use of local timezones is not recommended. timestamps_utc config directive
set to true can be used to present timestamps in UTC even if the system where
pmacct is running is set to some timezone different than that.
Q19: I'm using the 'tee' plugin with transparent mode set to true and keep receiving
"Can't bridge Address Families when in transparent mode. Exiting ..." messages,
A: It means you can't receive packets on an IPv4 address and transparently replicate
to an IPv6 collector or vice-versa. Less obvious scenarios are: a) some operating
systems where loopback (127.0.0.1) is considered a different address family hence
it's not possible to replicate to a 127.0.0.1 address; it's possible though to use
any locally configured IPv4 address bound to a (sub-)interface in 'up' state; b)
an IPv4-mapped IPv6 address is still technically an IPv6 address hence on servers
running IPv4 and IPv6 it is good practice to explicitely define also the receiving
IP address (nfacctd_ip), if IPv4 is used.
Q20: I'm using IPv6 support in pmacct. Even though the daemon binds to the "::"
address, i don't receive NetFlow/IPFIX/sFlow/BGP data sent via IPv4, why?
A: Binding to a "::" address (ie. no [sn]facctd_ip specified should allow to receive
both IPv4 and IPv6 senders. IPv4 ones should be reportd in 'netstat' as IPv4-mapped
IPv6 addresses. Linux has a kernel switch to enable/disable the functionality and
its status can be checked via the /proc/sys/net/ipv6/bindv6only . Historically the
default has been '0'. It appears over time some distributions have changed the
default to be '1'. If you experience this issue on Linux, please check your kernel
Q21: How can i count how much telemetry data (ie. NetFlow, sFlow, IPFIX, Streaming
Telemetry) i'm receiving on my collector?
A: If the interface where telemetry data is received is dedicated to the task then any
ifconfig, netstat or dstat tools or SNMP meaurement would do in order to verify
amount of telemetry packets and bytes (from which packets per second, bytes per
second can be easily inferred). If, instead, the interface is shared then pmacctd,
the libpcap-based daemon, can help to isolate and account for the telemetry traffic;
guess telemetry data is pointed to UDP port 2100 of the IP address configured on
eth0, pmacctd can be started as "pmacctd -i eth0 -P print -c none port 2100" to
account for the grand total of telemetry packets and bytes; if a breakdown per
telemetry exporting node is wanted, the following command-line can be used: "pmacctd
-i eth0 -P print -c src_host port 2100"; this example is suitable for manual reading
as it will print data every 60 secs on the screen and can, of course, be complicated
slightly to make it suitable for automation. A related question that often arises
is: how many flows per second am i receiving? This can be similarly addressed by
using "nfacctd -P print -c flows" for NetFlow/IPFIX and "sfacctd -P print -c flows"
for sFlow. Here FLOWS is the amount of flow records (NetFlow/IPFIX) or flow samples
(sFlow) processed in the period of time, and is the measure of interest. Changing
the aggregation argument in "-c peer_src_ip,flows" gives the amount of flows per
telemetry exporter (ie. router).
/* EOF */