pmacct [IP traffic accounting : BGP : BMP : IGP : Streaming Telemetry] pmacct is Copyright (C) 2003-2018 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 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, 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. 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 ' command; b) kill the whole pmacct instance: you can either use the 'killall -INT ' command or identify the Core Process and use the 'kill -INT ' 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 */