pmacct [IP traffic accounting : BGP : BMP : IGP : Streaming Telemetry]
pmacct is Copyright (C) 2003-2017 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 intended to be the name of the project; 'pmacctd' is the name of the
   libpcap-based IPv4/IPv6 accounting daemon; 'nfacctd' is the name of the NetFlow
   (versions supported NetFlow v1 to v9) and IPFIX accounting daemon; 'sfacctd' is
   the name of the sFlow v2/v4/v5 accounting daemon; 'uacctd' is the name of the
   Linux Netlink NFLOG-based accounting daemon (historically, it was using ULOG,
   hence its name); 'pmtelemetryd' is the name of the Streaming Telemetry collector
   daemon, where, quoting Cisco IOS-XR Telemetry Configuration Guide at the time of
   this writing, "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. [ .. ]";
   'pmbgpd' is the name of the pmacct BGP collector daemon; 'pmbmpd' is the name of
   the pmacct BMP collector daemon. 


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 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, 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 or Cassandra). Export speaking sFlow v5, NetFlow v1/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, IGP and Streaming Telemetry data
   both standalone and as correlation/enrichment of data plane information.


Q5: Do pmacct IPv4/IPv6 traffic accounting daemons log to flat files?
A: Yes. But while in other tools flat-files are typically used to log every micro-flow
   (or whatever aggregation the NetFlow agents have been configured to export with) and
   work in a two-stages fashion, ie. a) write down to persistent storage then b)
   consolidate to build the desired view, by inception, pmacct always aimed to a
   single-stage approach instead, ie. offer data reduction tecniques and correlation
   tools to process network traffic data on the fly, so to offer immediate view(s) of
   the traffic. 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 customization.


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 : it's a new type of network socket that
   improves the packet capture speed; it's available for Linux kernels 2.[46].x; it's
   kernel based; has libpcap support for seamless integration with existing applications.

   Device polling: it's available since FreeBSD 4.5REL kernel and needs just kernel
   recompilation (with "options DEVICE_POLLING"), and a polling-aware NIC. Linux kernel
   2.6.x also supports device polling. 

   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[inbound]: dst_host
   aggregate[outbound]: src_host
   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]
   sql_table[inbound]: acct_in 
   sql_table[outbound]: acct_out 
   ... 

   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:

   ...
   aggregate: sum_host
   plugins: mysql
   networks_file: /usr/local/pmacct/etc/networks.lst
   ...

   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
   the solution.


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. 
   If using an SQL plugin, starting from release 0.9.2, such adjustment can be achieved
   directly within pmacct via the 'adjb' action (sql_preprocess).


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
   2339
   shell>

   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 
   50905
   1152
   ...

   OR 

   shell> ./pmacct -c src_host,dst_host -N "file:queries.list" -r
   ...

   shell> cat queries.list
   192.168.4.133,192.168.0.101
   192.168.4.5,192.168.4.1
   ...

   A second option is to leverage one of the several modern data analytics stacks that
   do typically comprise of data manipulation, storage and visualization. Pointers in
   this sense would be the ELK stack (ElasticSearch, Logstash, Kibana) or the TICK
   stack (Telegraf, InfluxDB, Chronograf, Kapacitor). Much more exist. 


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
     PostgreSQL.
   * 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. 


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,
     why?

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
   setting.


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 */
