FAQS

pmacct [IP traffic accounting : BGP : BMP : RPKI : IGP : Streaming Telemetry]
pmacct is Copyright (C) 2003-2021 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
   information.


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
   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 : 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
   applications.

   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. 


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, 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
   commercial, exists. 


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