pmacct [IP traffic accounting : BGP : BMP : IGP : Streaming Telemetry]
pmacct is Copyright (C) 2003-2018 by Paolo Lucente


TABLE OF CONTENTS:
I.	Plugins included with pmacct distribution
II.	Configuring pmacct for compilation and installing
III.	Brief SQL (MySQL, PostgreSQL, SQLite 3.x) setup examples
IV.	Running the libpcap-based daemon (pmacctd)
V.	Running the NetFlow/IPFIX and sFlow daemons (nfacctd/sfacctd)
VI.	Running the NFLOG-based daemon (uacctd)
VII.	Running the pmacct client (pmacct)
VIII.	Running the RabbitMQ/AMQP plugin
IX.	Running the Kafka plugin
X.	Internal buffering and queueing
XI.	Quickstart guide to packet classification
XII.	Quickstart guide to setup a NetFlow/IPFIX agent/probe 
XIII.	Quickstart guide to setup a sFlow agent/probe 
XIV.	Quickstart guide to setup the BGP daemon
XV.	Quickstart guide to setup a NetFlow/IPFIX/sFlow replicator
XVI.	Quickstart guide to setup the IS-IS daemon
XVII.	Quickstart guide to setup the BMP daemon
XVIII.	Quickstart guide to setup Streaming Telemetry collection 
XIX.	Running the print plugin to write to flat-files
XX.	Quickstart guide to setup GeoIP lookups
XXI.	Using pmacct as traffic/event logger
XXII.	Miscellaneous notes and troubleshooting tips


I. Plugins included with pmacct distribution
Given its open and pluggable architecture, pmacct is easily extensible with new
plugins. Here is a list of plugins included in the official pmacct distribution:

'memory':  data is stored in a memory table and can be fetched via the pmacct
	   command-line client tool, 'pmacct'. This plugin also allows easily to
	   inject data into 3rd party tools like GNUplot, RRDtool or a Net-SNMP
	   server. The plugin is good for prototype solutions and smaller-scale
	   environments. This plugin is compiled in by default.
'mysql':   a working MySQL/MariaDB installation can be used for data storage.
	   This plugin can be compiled using the --enable-mysql switch. 
'pgsql':   a working PostgreSQL installation can be used for data storage. This
	   plugin can be compiled using the --enable-pgsql switch.
'sqlite3': a working SQLite 3.x or BerkeleyDB 5.x (compiled in with the SQLite
	   API) installation can be used for data storage. This plugin can be
	   compiled using the --enable-sqlite3 switch.
'print':   data is printed at regular intervals to flat-files or standard output
	   in tab-spaced, CSV and JSON formats. This plugin is compiled in by
	   default.
'amqp':    data is sent to a RabbitMQ message exchange, running AMQP protocol,
	   for delivery to consumer applications or tools. Popular consumers
	   are ElasticSearch, InfluxDB, Druid and ClickHouse. This plugin can
	   be compiled using the --enable-rabbitmq switch.
'kafka':   data is sent to a Kafka broker for delivery to consumer applications
	   or tools. Popular consumers are ElasticSearch, InfluxDB, Druid and
	   ClickHouse. This plugin can be compiled using the --enable-kafka
	   switch.
'tee':	   applies to nfacctd and sfacctd daemons only. It's a featureful packet
	   replicator for NetFlow/IPFIX/sFlow data. This plugin is compiled in by
	   default.
'nfprobe': applies to pmacctd and uacctd daemons only. Exports collected data via
	   NetFlow v5/v9 or IPFIX. This plugin is compiled in by default.
'sfprobe': applies to pmacctd and uacctd daemons only. Exports collected data via
	   sFlow v5. This plugin is compiled in by default.


II. Configuring pmacct for compilation and installing
The simplest way to configure the package for compilation is to download the
latest stable released tarball from http://www.pmacct.net/ and let the configure
script to probe default headers and libraries for you. A first round of guessing
is done via pkg-config then, for some libraries, "typical" default locations
are checked, ie. /usr/local/lib. Switches you are likely to want enabled are
already set so, ie. 64 bits counters and multi-threading (pre- requisite for
the BGP, BMP, and IGP daemon codes); the full list of switches enabled by default
are marked as 'default: yes' in the "./configure --help" output. SQL plugins, AMQP
and Kafka support are all disabled by defaulf instead. A few examples will follow;
to get the list of available switches, you can use the following command-line:

shell> ./configure --help

Examples on how to enable the support for (1) MySQL, (2) PostgreSQL, (3) SQLite,
and any (4) mixed compilation:

(1) shell> ./configure --enable-mysql
(2) shell> ./configure --enable-pgsql
(3) shell> ./configure --enable-sqlite3
(4) shell> ./configure --enable-mysql --enable-pgsql

If cloning the GitHub repository ( https://github.com/pmacct/pmacct ) instead,
the configure script has to be generated, resulting in one extra step than the
process just described. Please refer to the Building section of the README.md
document for instruction about cloning the repo, generate the configure script
along with the required installed packages.

Then compile and install simply typing:

shell> make; make install

Should you want, for example, to compile pmacct with PostgreSQL support and
have installed PostgreSQL in /usr/local/postgresql and pkg-config is unable
to help, you can supply this non-default location as follows (assuming you
are running the bash shell):

shell> export PGSQL_LIBS="-L/usr/local/postgresql/lib -lpq"
shell> export PGSQL_CFLAGS="-I/usr/local/postgresql/include"
shell> ./configure --enable-pgsql

If the library does actually support pkg-config but the .pc pkg-config file
is in some non-standard location, this can be supplied as follows:

shell> export PKG_CONFIG_PATH=/usr/local/postgresql/pkgconfig/
shell> ./configure --enable-pgsql

By default all tools - flow, BGP, BMP and Streaming Telemetry - are compiled.
Specific tool sets can be disabled. For example, to compile only flow tools
(ie. no pmbgpd, pmbmpd, pmtelemetryd) the following command-line can be used:

shell> ./configure --disable-bgp-bins --disable-bmp-bins --disable-st-bins

Once daemons are installed you can check:
* how to instrument each daemon via its usage help page: 
  shell> pmacctd -h
* review version and build details:
  shell> sfacctd -V
* supported traffic aggregation primitives by the daemon, and their description:
  shell> nfacctd -a

IIa. Compiling pmacct with JSON support
JSON encoding is supported via the Jansson library (http://www.digip.org/jansson/
and https://github.com/akheron/jansson); a library version >= 2.5 is required. To
compile pmacct with JSON support simply do: 

shell> ./configure --enable-jansson

However should you have installed Jansson in the /usr/local/jansson directory
and pkg-config is unable to help, you can supply this non-default location as
follows (assuming you are running the bash shell):

shell> export JANSSON_LIBS="-L/usr/local/jansson/lib -ljansson"
shell> export JANSSON_CFLAGS="-I/usr/local/jansson/include"
shell> ./configure --enable-jansson

IIb. Compiling pmacct with Apache Avro support
Apache Avro encoding is supported via libavro library (http://avro.apache.org/
and https://avro.apache.org/docs/1.8.1/api/c/index.html); to compile pmacct with
Apache Avro support simply do:

shell> ./configure --enable-avro

However should you have installed libavro in the /usr/local/avro directory
and pkg-config is unable to help, you can supply this non-default location as
follows (assuming you are running the bash shell):

export AVRO_LIBS="-L/usr/local/avro/lib -lavro"
export AVRO_CFLAGS="-I/usr/local/avro/include"
./configure --enable-rabbitmq --enable-avro

IIc. Compiling pmacct against a own libpcap library
Compiling against a downloaded libpcap library may be wanted for several
reasons including the version packaged with the Operating System is too
old, a custom libpcap library needs to be compiled (ie. with support for
PF_RING) or static linking is wanted.

Once libpcap is downloaded, if static linking is wanted (ideal for example
for distributing pmacct without external dependencies), the library can be
configured for comipiling:

./configure --disable-shared

pmacct should be pointed to the own libpcap library when configuring for
compiling: 

./configure --with-pcap-libs=/path/to/libpcap-x.y.z --with-pcap-includes=/path/to/libpcap-x.y.z

Once pmacct is compiled, it can be confirmed that the right library was
picked by doing, for example, a 'pmacctd -V' and seeing the version of
libpcap matches with the supplied version.


III. Brief SQL and noSQL setup examples
RDBMS require a table schema to manage data. pmacct offers two options: use one
of the few pre-determined table schemas available (sections IIIa, b and c) or
compose a custom schema to fit your needs (section IIId). If you are blind to
SQL the former approach is recommended, although it can pose scalability issues
in larger deployments; if you know some SQL the latter is definitely the way to
go. Scripts for setting up RDBMS are located in the 'sql/' tree of the pmacct
distribution tarball. For further guidance read the relevant README files in
such directory. One of the crucial concepts to deal with, when using default
table schemas, is table versioning: please read more about this topic in the
FAQS document (Q17). 

IIIa. MySQL examples 
shell> cd sql/

- To create v1 tables:
shell> mysql -u root -p < pmacct-create-db_v1.mysql
shell> mysql -u root -p < pmacct-grant-db.mysql

Data will be available in 'acct' table of 'pmacct' DB.

- To create v2 tables:
shell> mysql -u root -p < pmacct-create-db_v2.mysql
shell> mysql -u root -p < pmacct-grant-db.mysql

Data will be available in 'acct_v2' table of 'pmacct' DB.

... And so on for the newer versions.

IIIb. PostgreSQL examples
Which user has to execute the following two scripts and how to autenticate with the
PostgreSQL server depends upon your current configuration. Keep in mind that both
scripts need postgres superuser permissions to execute some commands successfully:
shell> cp -p *.pgsql /tmp
shell> su - postgres

To create v1 tables:
shell> psql -d template1 -f /tmp/pmacct-create-db.pgsql
shell> psql -d pmacct -f /tmp/pmacct-create-table_v1.pgsql

To create v2 tables:
shell> psql -d template1 -f /tmp/pmacct-create-db.pgsql
shell> psql -d pmacct -f /tmp/pmacct-create-table_v2.pgsql

... And so on for the newer versions.

A few tables will be created into 'pmacct' DB. 'acct' ('acct_v2' or 'acct_v3') table is
the default table where data will be written when in 'typed' mode (see 'sql_data' option
in CONFIG-KEYS document; default value is 'typed'); 'acct_uni' ('acct_uni_v2' or
'acct_uni_v3') is the default table where data will be written when in 'unified' mode.

Since v6, PostgreSQL tables are greatly simplified: unified mode is no longer supported
and an unique table ('acct_v6', for example) is created instead. 

IIIc. SQLite examples
shell> cd sql/

- To create v1 tables:
shell> sqlite3 /tmp/pmacct.db < pmacct-create-table.sqlite3 

Data will be available in 'acct' table of '/tmp/pmacct.db' DB. Of course, you can change
the database filename basing on your preferences.  

- To create v2 tables:
shell> sqlite3 /tmp/pmacct.db < pmacct-create-table_v2.sqlite3 

Data will be available in 'acct_v2' table of '/tmp/pmacct.db' DB.

... And so on for the newer versions.

IIId. Custom SQL tables
Custom tables can be built by creating your own SQL schema and indexes. This
allows to mix-and-match the primitives relevant to your accounting scenario.
To flag intention to build a custom table the sql_optimize_clauses directive
must be set to true, ie.:

sql_optimize_clauses: true
sql_table: <table name>
aggregate: <aggregation primitives list> 

How to build the custom schema? Let's say the aggregation method of choice
(aggregate directive) is "vlan, in_iface, out_iface, etype" the table name is
"acct" and the database of choice is MySQL. The SQL schema is composed of four
main parts, explained below:

1) A fixed skeleton needed by pmacct logics:

CREATE TABLE <table_name> (
	packets INT UNSIGNED NOT NULL,
	bytes BIGINT UNSIGNED NOT NULL,
	stamp_inserted DATETIME NOT NULL,
	stamp_updated DATETIME,
);

2) Indexing: primary key (of your choice, this is only an example) plus
   any additional index you may find relevant.

3) Primitives enabled in pmacct, in this specific example the ones below; should
   one need more/others, these can be looked up in the sql/README.mysql file in
   the section named "Aggregation primitives to SQL schema mapping:" :

	vlan INT(2) UNSIGNED NOT NULL,
	iface_in INT(4) UNSIGNED NOT NULL,
	iface_out INT(4) UNSIGNED NOT NULL,
	etype INT(2) UNSIGNED NOT NULL,

4) Any additional fields, ignored by pmacct, that can be of use, these can be
   for lookup purposes, auto-increment, etc. and can be of course also part of
   the indexing you might choose. 

Putting the pieces together, the resulting SQL schema is below along with the
required statements to create the database:

DROP DATABASE IF EXISTS pmacct;
CREATE DATABASE pmacct;

USE pmacct;

DROP TABLE IF EXISTS acct;
CREATE TABLE acct (
	vlan INT(2) UNSIGNED NOT NULL,
	iface_in INT(4) UNSIGNED NOT NULL,
	iface_out INT(4) UNSIGNED NOT NULL,
	etype INT(2) UNSIGNED NOT NULL,
	packets INT UNSIGNED NOT NULL,
	bytes BIGINT UNSIGNED NOT NULL,
	stamp_inserted DATETIME NOT NULL,
	stamp_updated DATETIME,
	PRIMARY KEY (vlan, iface_in, iface_out, etype, stamp_inserted)
); 

To grant default pmacct user permission to write into the database look at the
file sql/pmacct-grant-db.mysql

IIIe. Historical accounting
Enabling historical accounting allows to aggregate data over time (ie. 5 mins, hourly,
daily) in a flexible and fully configurable way. Timestamps are lodged into two fields:
'stamp_inserted' which represents the basetime of the timeslot and 'stamp_updated' which
says when a given timeslot was updated for the last time. Following there is a pretty
standard configuration fragment to slice data into nicely aligned (or rounded-off) 5
minutes timeslots:

sql_history: 5m 
sql_history_roundoff: m

IIIf. INSERTs-only 
UPDATE queries are demanding in terms of resources; this is why, even if they are 
supported by pmacct, a savy approach is to cache data for longer times in memory and
write them off once per timeslot (sql_history): this produces a much lighter INSERTs-
only environemnt. This is an example based on 5 minutes timeslots:

sql_refresh_time: 300
sql_history: 5m
sql_history_roundoff: m
sql_dont_try_update: true

Note that sql_refresh_time is always expressed in seconds. An alternative approach
for cases where sql_refresh_time must be kept shorter than sql_history (for example
because a) of long sql_history periods, ie. hours or days, and/or because b) near
real-time data feed is a requirement) is to set up a synthetic auto-increment 'id'
field: it successfully prevents duplicates but comes at the expenses of GROUP BY
queries when retrieving data.


IV. Running the libpcap-based daemon (pmacctd) 
All deamons including pmacctd can be run with commandline options, using a
config file or a mix of the two. Sample configuration files are in examples/
tree. Note also  that most of the new features are available only as config
directives. To be aware of the existing configuration directives, please
read the CONFIG-KEYS document. 

Show all available pmacctd commandline switches:
shell> pmacctd -h

Run pmacctd reading configuration from a specified file (see examples/ tree
for a brief list of some commonly useed keys; divert your eyes to CONFIG-KEYS
for the full list). This example applies to all daemons:
shell> pmacctd -f pmacctd.conf

Daemonize the process; listen on eth0; aggregate data by src_host/dst_host;
write to a MySQL server; filter in only traffic with source prefix 10.0.0.0/16;
note that filters work the same as tcpdump. So, refer to libpcap/tcpdump man
pages for examples and further reading. 

shell> pmacctd -D -c src_host,dst_host -i eth0 -P mysql src net 10.0.0.0/16

Or written the configuration way:
!
daemonize: true
plugins: mysql
aggregate: src_host, dst_host
pcap_interface: eth0
pcap_filter: src net 10.0.0.0/16
! ...

Print collected traffic data aggregated by src_host/dst_host over the screen;
refresh data every 30 seconds and listen on eth0. 

shell> pmacctd -P print -r 30 -i eth0 -c src_host,dst_host

Or written the configuration way:
!
plugins: print
print_refresh_time: 30
aggregate: src_host, dst_host
pcap_interface: eth0
! ...

Print collected traffic data aggregated by src_host/dst_host over the screen;
refresh data every 30 seconds and listen on eth0 and eth1, listed in the file
pointed by pcap_interfaces_map (see 'examples/pcap_interfaces.map.example' for
more advanced uses of the map):

!
plugins: print
print_refresh_time: 30
aggregate: src_host, dst_host
pcap_interfaces_map: /path/to/pcap_interfaces.map
! ...

Then in /path/to/pcap_interfaces.map:

!
ifname=eth0
ifname=eth1
! ...

Daemonize the process; let pmacct aggregate traffic in order to show in vs out
traffic for network 192.168.0.0/16; send data to a PostgreSQL server. This
configuration is not possible via commandline switches; the corresponding
configuration follows: 

! 
daemonize: true
plugins: pgsql[in], pgsql[out]
aggregate[in]: dst_host
aggregate[out]: src_host
aggregate_filter[in]: dst net 192.168.0.0/16
aggregate_filter[out]: src net 192.168.0.0/16
sql_table[in]: acct_in
sql_table[out]: acct_out
! ...

The previous example looks nice! But how to make data historical ? Simple
enough, let's suppose you want to split traffic by hour and write data into
the DB every 60 seconds. 

!
daemonize: true
plugins: pgsql[in], pgsql[out]
aggregate[in]: dst_host
aggregate[out]: src_host
aggregate_filter[in]: dst net 192.168.0.0/16
aggregate_filter[out]: src net 192.168.0.0/16
sql_table[in]: acct_in
sql_table[out]: acct_out
sql_refresh_time: 60
sql_history: 1h
sql_history_roundoff: h
! ...

Let's now translate the same example in the memory plugin world. It's use
is valuable expecially when it's required to feed bytes/packets/flows
counters to external programs. Examples about the client program will
follow later in this document. Now, note that each memory table need its
own pipe file in order to get correctly contacted by the client:

!
daemonize: true
plugins: memory[in], memory[out]
aggregate[in]: dst_host
aggregate[out]: src_host
aggregate_filter[in]: dst net 192.168.0.0/16
aggregate_filter[out]: src net 192.168.0.0/16
imt_path[in]: /tmp/pmacct_in.pipe
imt_path[out]: /tmp/pmacct_out.pipe
! ...

As a further note, check CONFIG-KEYS document about more imt_* directives
as they will support in the task of fine tuning the size and boundaries
of memory tables, if default values are not ok for your setup. 

Now, fire multiple instances of pmacctd, each on a different interface;
again, because each instance will have its own memory table, it will
require its own pipe file for client queries aswell (as explained in the
previous examples):

shell> pmacctd -D -i eth0 -m 8 -s 65535 -p /tmp/pipe.eth0 
shell> pmacctd -D -i ppp0 -m 0 -s 32768 -p /tmp/pipe.ppp0 

Run pmacctd logging what happens to syslog and using "local2" facility:
shell> pmacctd -c src_host,dst_host -S local2

NOTE: superuser privileges are needed to execute pmacctd correctly. 


V. Running the NetFlow/IPFIX and sFlow daemons (nfacctd/sfacctd) 
All examples about pmacctd are also valid for nfacctd and sfacctd with the exception
of directives that apply exclusively to libpcap. If you've skipped examples in the
previous section, please read them before continuing. All config keys available are
in the CONFIG-KEYS document. Some examples:

Run nfacctd reading configuration from a specified file.
shell> nfacctd -f nfacctd.conf

Daemonize the process; aggregate data by sum_host (by host, summing inbound + outbound
traffic); write to a local MySQL server. Listen on port 5678 for incoming Netflow
datagrams (from one or multiple NetFlow agents). Let's make pmacct refresh data each
two minutes and let's make data historical, divided into timeslots of 10 minutes each.
Finally, let's make use of a SQL table, version 4.
shell> nfacctd -D -c sum_host -P mysql -l 5678 

And now written the configuration way:
!
daemonize: true
plugins: mysql
aggregate: sum_host
nfacctd_port: 5678
sql_refresh_time: 120
sql_history: 10m
sql_history_roundoff: mh
sql_table_version: 4
! ...

Va. NetFlow daemon & accounting NetFlow v9/IPFIX options 
NetFlow v9/IPFIX can send option records other than flow ones, typically used to send
to a collector mappings among interface SNMP ifIndexes to interface names or VRF ID's
to VRF names. nfacctd_account_options enables accounting of option records then these
should be split from regular flow records. Below is a sample config:

nfacctd_time_new: true
nfacctd_account_options: true
!
plugins: print[data], print[data_options]
!
pre_tag_filter[data]: 100
aggregate[data]: peer_src_ip, in_iface, out_iface, tos, vrf_id_ingress, vrf_id_egress
print_refresh_time[data]: 300
print_history[data]: 300
print_history_roundoff[data]: m
print_output_file_append[data]: true
print_output_file[data]: /path/to/flow_%s
print_output[data]: csv
!
pre_tag_filter[data_options]: 200
aggregate[data_options]: vrf_id_ingress, vrf_name
print_refresh_time[data_options]: 300
print_history[data_options]: 300
print_history_roundoff[data_options]: m
print_output_file_append[data_options]: true
print_output_file[data_options]: /path/to/options_%s
print_output[data_options]: event_csv
!
aggregate_primitives: /path/to/primitives.lst
pre_tag_map: /path/to/pretag.map
maps_refresh: true

Below is the referenced pretag.map:

set_tag=100     ip=0.0.0.0/0    sample_type=flow
set_tag=200     ip=0.0.0.0/0    sample_type=option

Below is the referenced primitives.lst:

name=vrf_id_ingress     field_type=234  len=4   semantics=u_int
name=vrf_id_egress      field_type=235  len=4   semantics=u_int
name=vrf_name           field_type=236  len=32  semantics=str


VI. Running the NFLOG-based daemon (uacctd)
All examples about pmacctd are also valid for uacctd with the exception of directives
that apply exclusively to libpcap. If you've skipped examples in section 'IV', please
read them before continuing. All configuration keys available are in the CONFIG-KEYS
document.

The daemon depends on the package libnetfilter-log-dev (in Debian/Ubuntu or equivalent
in the prefered Linux distribution). The Linux NFLOG infrastructure requires a couple
parameters in order to work properly: the NFLOG multicast group (uacctd_group) to
which captured packets have to be sent to and the Netlink buffer size (uacctd_nl_size).
The default buffer settings (128KB) typically works OK for small environments. The
traffic is captured with an iptables rule. For example in one of the following ways:

* iptables -t mangle -I POSTROUTING -j NFLOG --nflog-group 5
* iptables -t raw -I PREROUTING -j NFLOG --nflog-group 5 

Apart from determining how and what traffic to capture with iptables, which is topic
outside the scope of this document, the most relevant point is the "--nflog-nlgroup"
iptables setting has to match with the "uacctd_group" uacctd one.

A couple examples follow:

Run uacctd reading configuration from a specified file.
shell> uacctd -f uacctd.conf

Daemonize the process; aggregate data by sum_host (by host, summing inbound + outbound
traffic); write to a local MySQL server. Listen on NFLOG multicast group #5. Let's make
pmacct divide data into historical time-bins of 5 minutes. Let's disable UPDATE queries
and hence align refresh time with the timeslot length. Finally, let's make use of a SQL
table, version 4:
!
uacctd_group: 5
daemonize: true
plugins: mysql
aggregate: sum_host
sql_refresh_time: 300
sql_history: 5m
sql_history_roundoff: mh
sql_table_version: 4
sql_dont_try_update: true
! ...


VII. Running the pmacct client (pmacct)
The pmacct client is used to retrieve data from memory tables. Requests and answers
are exchanged via a pipe file: authorization is strictly connected to permissions on
the pipe file. Note: while writing queries commandline, it may happen to write chars
with a special meaning for the shell itself (ie. ; or *). Mind to either escape ( \;
or \* ) them or put in quotes ( " ).

Show all available pmacct client commandline switches:
shell> pmacct -h

Fetch data stored into the memory table:
shell> pmacct -s 

Match data between source IP 192.168.0.10 and destination IP 192.168.0.3 and return
a formatted output; display all fields (-a), this way the output is easy to be parsed
by tools like awk/sed; each unused field will be zero-filled: 
shell> pmacct -c src_host,dst_host -M 192.168.0.10,192.168.0.3 -a

Similar to the previous example; it is requested to reset data for matched entries;
the server will return the actual counters to the client, then will reset them:
shell> pmacct -c src_host,dst_host -M 192.168.0.10,192.168.0.3 -r

Fetch data for IP address dst_host 10.0.1.200; we also ask for a 'counter only' output
('-N') suitable, this time, for injecting data in tools like MRTG or RRDtool (sample
scripts are in the examples/ tree). Bytes counter will be returned (but the '-n' switch
allows also select which counter to display). If multiple entries match the request (ie
because the query is based on dst_host but the daemon is actually aggregating traffic
as "src_host, dst_host") their counters will be summed:
shell> pmacct -c dst_host -N 10.0.1.200

Another query; this time let's contact the server listening on pipe file /tmp/pipe.eth0:
shell> pmacct -c sum_port -N 80 -p /tmp/pipe.eth0 

Find all data matching host 192.168.84.133 as either their source or destination address.
In particular, this example shows how to use wildcards and how to spawn multiple queries
(each separated by the ';' symbol). Take care to follow the same order when specifying
the primitive name (-c) and its actual value ('-M' or '-N'):
shell> pmacct -c src_host,dst_host -N "192.168.84.133,*;*,192.168.84.133"

Find all web and smtp traffic; we are interested in have just the total of such traffic
(for example, to split legal network usage from the total); the output will be a unique
counter, sum of the partial (coming from each query) values.
shell> pmacct -c src_port,dst_port -N "25,*;*,25;80,*;*,80" -S 

Show traffic between the specified hosts; this aims to be a simple example of a batch
query; note that as value of both '-N' and '-M' switches it can be supplied a value like:
'file:/home/paolo/queries.list': actual values will be read from the specified file (and
they need to be written into it, one per line) instead of commandline:
shell> pmacct -c src_host,dst_host -N "10.0.0.10,10.0.0.1;10.0.0.9,10.0.0.1;10.0.0.8,10.0.0.1"
shell> pmacct -c src_host,dst_host -N "file:/home/paolo/queries.list"


VIII. Running the RabbitMQ/AMQP plugin
The Advanced Message Queuing Protocol (AMQP) is an open standard for passing business
messages between applications. RabbitMQ is a messaging broker, an intermediary for
messaging, which implementes AMQP. pmacct RabbitMQ/AMQP plugin is designed to send
aggregated network traffic data, in JSON or Avro format, through a RabbitMQ server
to 3rd party applications (typically, but not limited to, noSQL databases like
ElasticSearch, InfluxDB, etc.). Requirements to use the plugin are:

* A working RabbitMQ server: http://www.rabbitmq.com/
* RabbitMQ C API, rabbitmq-c: https://github.com/alanxz/rabbitmq-c/
* Libjansson to cook JSON objects: http://www.digip.org/jansson/

Additionally, the Apache Avro C library (http://avro.apache.org/) needs to be
installed to be able to send messages packed using Avro (you will also need to
pass --enable-avro to the configuration script).

Once these elements are installed, pmacct can be configured for compiling. pmacct
makes use of pkg-config for finding libraries and headers location and checks some
"typical" default locations, ie. /usr/local/lib and /usr/local/include. So all
you should do is just:

./configure --enable-rabbitmq --enable-jansson

But, for example, should you have installed RabbitMQ in /usr/local/rabbitmq and
pkg-config is unable to help, you can supply this non-default location as follows 
(assuming you are running the bash shell):

export RABBITMQ_LIBS="-L/usr/local/rabbitmq/lib -lrabbitmq" 
export RABBITMQ_CFLAGS="-I/usr/local/rabbitmq/include"
./configure --enable-rabbitmq --enable-jansson

You can check further information on how to compile pmacct with JSON/libjansson
support in the section "Compiling pmacct with JSON support" of this document.

You can check further information on how to compile pmacct with Avro support in
the section "Compiling pmacct with Apache Avro support" of this document.

Then "make; make install" as usual. Following a configuration snippet showing a
basic RabbitMQ/AMQP plugin configuration (assumes: RabbitMQ server is available
at localhost; look all configurable directives up in the CONFIG-KEYS document):

! ..
plugins: amqp
!
aggregate: src_host, dst_host, src_port, dst_port, proto, tos
amqp_output: json
amqp_exchange: pmacct
amqp_routing_key: acct
amqp_refresh_time: 300
amqp_history: 5m
amqp_history_roundoff: m
! ..

pmacct will only declare a message exchange and provide a routing key, ie. it
will not get involved with queues at all. A basic consumer script, in Python,
is provided as sample to: declare a queue, bind the queue to the exchange and
show consumed data on the screen or post to a REST API. The script is located
in the pmacct default distribution tarball in 'examples/amqp/amqp_receiver.py'
and requires the 'pika' Python module installed. Should this not be available,
installation instructions are available at the following page:

http://www.rabbitmq.com/tutorials/tutorial-one-python.html


IX. Running the Kafka plugin
Apache Kafka is a distributed streaming platform. Its qualities being: fast,
scalable, durable and distributed by design. pmacct Kafka plugin is designed
to send aggregated network traffic data, in JSON or Avro format, through a
Kafka broker to 3rd party applications (typically, but not limited to, noSQL
databases like ElasticSearch, InfluxDB, etc.). Requirements to use the plugin
are:

* A working Kafka broker (and Zookeper server): http://kafka.apache.org/
* Librdkafka: https://github.com/edenhill/librdkafka/
* Libjansson to cook JSON objects: http://www.digip.org/jansson/

Additionally, the Apache Avro C library (http://avro.apache.org/) needs to be
installed to be able to send messages packed using Avro (you will also need to
pass --enable-avro to the configuration script).

Once these elements are installed, pmacct can be configured for compiling.
pmacct makes use of pkg-config for finding libraries and headers location and
checks some default locations, ie. /usr/local/lib and /usr/local/include. If
this is satisfactory, all you should do is just:

./configure --enable-kafka --enable-jansson

But, for example, should you have installed Kafka in /usr/local/kafka and pkg-
config is unable to help, you can supply this non-default location as follows
(assuming you are running the bash shell):

export KAFKA_LIBS="-L/usr/local/kafka/lib -lrdkafka"
export KAFKA_CFLAGS="-I/usr/local/kafka/include"
./configure --enable-kafka --enable-jansson

You can check further information on how to compile pmacct with JSON/libjansson
support in the section "Compiling pmacct with JSON support" of this document.

You can check further information on how to compile pmacct with Avro support in
the section "Compiling pmacct with Apache Avro support" of this document.

Then "make; make install" as usual. Following a configuration snippet showing a
basic Kafka plugin configuration (assumes: Kafka broker is available at 127.0.0.1
on port 9092; look all configurable directives up in the CONFIG-KEYS document):

! ..
plugins: kafka
!
aggregate: src_host, dst_host, src_port, dst_port, proto, tos
kafka_output: json
kafka_topic: pmacct.acct
kafka_refresh_time: 300
kafka_history: 5m
kafka_history_roundoff: m
! ..

A basic script, in Python, is provided as sample to consume JSON/Avro data from
a given topic and perform some simple actions (ie. post data to a new Kafka topic,
post to a URL or print to screen). The script is located in the pmacct distributed
code in 'examples/kafka/kafka_consumer.py' and requires the confluent-kafka-python
Python module installed (among the others, check script header). Should this not
be available you can read on the following page how to get it installed:

https://github.com/confluentinc/confluent-kafka-python

This is a pointer to the quick start guide to Kafka:

https://kafka.apache.org/quickstart

Some notes:
1) When using Kafka over a dedicated node or VM, you will have to update the
default Kafka server configuration. Edit with your favorite text editor the file
named server.properties under the config folder of your kafka installation.
Uncomment the following parameters:

* listeners,
* advertised.listeners,
* listener.security.protocol.map

and configure it according to your Kafka design. Taking a simple example where
there is one single Kafka node used for both Zookeeper and Kafka and this node
is using and ip address like 172.16.2.1. Those three parameters will look like
this:

listeners=PLAINTEXT://172.16.2.1:9092
advertised.listeners=PLAINTEXT://172.16.2.1:9092
listener.security.protocol.map=PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL

2) When the amount of data published to Kafka is substantial, ie. in the order
of thousands of entries per second, batching is needed in order to avoid every
single entry originating a produce call to Kafka. Two strategies are being
available: a) pmacct batching via the kafka_multi_values feature or b) librdkafka
batching via, as per the lib documentation, "The two most important configuration
properties for performance tuning are:

* batch.num.messages : the minimum number of messages to wait for to accumulate
  in the local queue before sending off a message set.
* queue.buffering.max.ms : how long to wait for batch.num.messages to fill up
  in the local queue."

Also, intuitively, queue.buffering.max.messages, the "Maximum number of messages
allowed on the producer queue", should be kept greater than the batch.num.messages.
These knobs can all be supplied to librdkafka through pmacct via a file pointed
by kafka_config_file, as global settings, ie.:
 
global, queue.buffering.max.messages, 8000000
global, batch.num.messages, 100000

3) Configuring statistics.interval.ms to a positive value in kafka_config_file
will make librdkafka log plenty of internal metrics - as documented at the
following wiki page: https://github.com/edenhill/librdkafka/wiki/Statistics


X. Internal buffering and queueing
Two options are provided for internal buffering and queueing: 1) a home-grown circular
queue implementation available since day one of pmacct (configured via plugin_pipe_size
and documented in docs/INTERNALS) and 2) a ZeroMQ queue (configured via plugin_pipe_zmq
and plugin_pipe_zmq_* directives).

For a quick comparison: while relying on a ZeroMQ queue does introduce an external
dependency, ie. libzmq, it reduces the amount of trial and error needed to fine
tune plugin_buffer_size and plugin_pipe_size directives needed by the home-grown
queue implementation.

The home-grown cicular queue has no external dependencies and is configured, for
example, as:

plugins: print[blabla]
plugin_buffer_size[blabla]: 10240
plugin_pipe_size[blabla]: 1024000
 
For more information about the home-grown circular queue, consult plugin_buffer_size
and plugin_pipe_size entries in CONFIG-KEYS and docs/INTERNALS "Communications between
core process and plugins" chapter. 

ZeroMQ, from 0MQ The Guide, "looks like an embeddable networking library but acts like
a concurrency framework. It gives you sockets that carry atomic messages across various
transports like in-process, inter-process, TCP, and multicast. You can connect sockets
N-to-N with patterns like fan-out, pub-sub, task distribution, and request-reply. It's
fast enough to be the fabric for clustered products. Its asynchronous I/O model gives
you scalable multicore applications, built as asynchronous message-processing tasks.
[ .. ]". pmacct integrates ZeroMQ using a pub-sub queue architecture, using ephemeral
TCP ports and implementing plain authentication (username and password, auto-generated
at runtime).

The only requirement to use a ZeroMQ queue is to have the latest available stable
release of libzmq installed on the system (http://zeromq.org/intro:get-the-software ,
https://github.com/zeromq/libzmq/releases). Once this is installed, pmacct can be
configured for compiling. pmacct makes use of pkg-config for finding libraries and
headers location and checks some "typical" default locations, ie. /usr/local/lib and
/usr/local/include. So all you should do is just:

./configure --enable-zmq

But, for example, should you have installed ZeroMQ in /usr/local/zeromq and should also
pkg-config be unable to help, the non-default location can be supplied as follows (bash
shell assumed):

export ZMQ_LIBS="-L/usr/local/zeromq/lib -lzmq"
export ZMQ_CFLAGS="-I/usr/local/zeromq/include"
./configure --enable-zmq

Then "make; make install" as usual. Following a configuration snippet showing how easy
is to leverage ZeroMQ for queueing (see CONFIG-KEYS for all ZeroMQ-related options):

plugins: print[blabla]
plugin_pipe_zmq[blabla]: true 
plugin_pipe_zmq_profile[blabla]: micro

Please review the standard buffer profiles, plugin_pipe_zmq_profile, in CONFIG-KEYS;
Q21 of FAQS describes how to estimate the amount of flows/samples per second of your
deployment.


XI. Quickstart guide to packet classification
Packet classification is a feature available for pmacctd (libpcap-based daemon),
uacctd (NFLOG-based daemon), NetFlow v9/IPFIX IE 315 (dataLinkFrameSection) and
the sFlow v5 raw header sample. The current approach is to leverage the popular
free, open-source nDPI library. To enable the feature please follow these
steps:

1) Download pmacct from its webpage (http://www.pmacct.net/) or from its GitHub
   repository (https://github.com/pmacct/pmacct).

2) Download nDPI from its GitHub repository (https://github.com/ntop/nDPI).
   pmacct code is tested against the latest stable version of the nDPI library
   and hence that is the recommended download. 

3) Configure for compiling, compile and install the downloaded nDPI library, ie.
   inside the nDPI directory:

   shell> ./autogen.sh; ./configure; make; make install 

3b) Starting with nDPI 2.2, several users have reported an error in the following
   step, that is, step #4: compiling pmacct fails with the following error (exact
   line numbers can differ basing on pmacct and nDPI version):

   In file included from /usr/local/include/libndpi-2.2.0/libndpi/ndpi_main.h:30:0,
		from ./../pmacct.h:93,
		from common.h:30,
		from nfprobe_plugin.c:53:
   /usr/local/include/libndpi-2.2.0/libndpi/ndpi_typedefs.h:28:49: \
   	fatal error: ../lib/third_party/include/libcache.h: No such file or directory 

   It seems a required file that is present in the original distribution package
   never gets installed by nDPI 'make install'. While searching for the issue on
   Google and GitHub returns many results, it does not bring a conclusive answer.
   To mitigate the issue, the following extra step helps:

   host:/usr/local/include/libndpi-2.2.0# mkdir -p lib/third_party/include
   host:/usr/local/include/libndpi-2.2.0# cp -p /path/to/nDPI-2.2/src/lib/third_party/include/* lib/third_party/include

   That is, in "/usr/local/include/libndpi-2.2.0" create the expected directory
   tree "lib/third_party/include" then copy into it the content of the directory
   "src/lib/third_party/include/" in the nDPI distribution tarball.

4) Configure for compiling pmacct with the --enable-ndpi switch. Then compile and
   install, ie.:

   If downloading a release from http://www.pmacct.net , from inside the pmacct
   directory:

   shell> ./configure --enable-ndpi; make; make install

   If downloading code from https://github.com/pmacct/pmacct , from inside the
   pmacct directory:

   shell> ./autogen.sh; ./configure --enable-ndpi; make; make install

   If using a nDPI library that is not installed (or not installed in a default
   location) on the system, then NDPI_LIBS and NDPI_CFLAGS should be set to the
   location where nDPI headers and dynamic library are lying. Additionally, the
   configure switch --with-ndpi-static-lib allows to specify the location for the
   static version of the library:

   shell> NDPI_LIBS=-L/path/to/nDPI/src/lib/.libs  
   shell> NDPI_CFLAGS=-I/path/to/nDPI/src/include
   shell> export NDPI_LIBS NDPI_CFLAGS
   shell> ./configure --enable-ndpi --with-ndpi-static-lib=/path/to/nDPI/src/lib/.libs
   shell> make; make install

5) Configure pmacct. The following sample configuration is based on pmacctd and
   the print plugin with formatted output to stdout: 

   daemonize: true
   pcap_interface: eth0
   snaplen: 700
   !
   plugins: print
   !
   aggregate: src_host, dst_host, src_port, dst_port, proto, tos, class

   What enables packet classification is the use of the 'class' primitive as part
   of the supplied aggregation method. Further classification-related options, 
   such as timers, attempts, etc., are documented in the CONFIG-KEYS document
   (classifier_* directives). 

6) Execute pmacct as:

   shell> pmacctd -f /path/to/pmacctd.conf


XII. Quickstart guide to setup a NetFlow/IPFIX agent/probe
pmacct is able to export traffic data through both NetFlow and sFlow protocols. This
section covers NetFlow/IPFIX and next one covers sFlow. While NetFlow v5 is fixed by
nature, v9 adds (to v5) flexibility allowing to transport custom information (ie.
classification information or custom tags to remote collectors) and IPFIX adds (to
v9) the chance to transport private information (PEN) and variable-length elements.
Below the configuration guide:

a) usual initial steps: download pmacct, unpack it, compile it.

b) build NetFlow probe configuration, using pmacctd:
!
daemonize: true
pcap_interface: eth0
aggregate: src_host, dst_host, src_port, dst_port, proto, tos
plugins: nfprobe
nfprobe_receiver: 1.2.3.4:2100
nfprobe_version: 9
! nfprobe_engine: 1:1
! nfprobe_timeouts: tcp=120:maxlife=3600
!
! networks_file: /path/to/networks.lst
!...

   This is a basic working configuration. Additional probe features include:

   1) generate ASNs by using a networks_file pointing to a valid Networks File (see
   examples/ directory) and adding src_as, dst_as primitives to the 'aggregate'
   directive; alternatively, it is possible to generate ASNs from the pmacctd BGP
   thread. The following fragment can be added to the config above:

pmacctd_as: bgp
bgp_daemon: true
bgp_daemon_ip: 127.0.0.1
bgp_agent_map: /path/to/bgp_agent.map
bgp_daemon_port: 17917

   The bgp_daemon_port can be changed from the standard BGP port (179/TCP) in order to
   co-exist with other BGP routing software which might be running on the same host.
   Furthermore, they can safely peer each other by using 127.0.0.1 as bgp_daemon_ip. 
   In pmacctd, bgp_agent_map does the trick of mapping 0.0.0.0 to the IP address of
   the BGP peer (ie. 127.0.0.1: 'set_tag=127.0.0.1 ip=0.0.0.0'); this setup, while
   generic, was tested working in conjunction with Quagga 0.99.14. Following a relevant
   fragment of the Quagga configuration:

router bgp Y 
 bgp router-id X.X.X.X
 neighbor 127.0.0.1 remote-as Y 
 neighbor 127.0.0.1 port 17917
 neighbor 127.0.0.1 update-source X.X.X.X
!

   NOTE: if configuring a BGP neighbor over localhost via Quagga CLI the following
   message is returned: "% Can not configure the local system as neighbor". This
   is not returned when configuring the neighborship directly in the bgpd config
   file.

   2) encode flow classification information in NetFlow v9 like Cisco does with its
   NBAR/NetFlow v9 integration. This can be done by introducing the 'class' primitive
   to the afore mentioned 'aggregate' and add the extra configuration directive:

aggregate: class, src_host, dst_host, src_port, dst_port, proto, tos
snaplen: 700

   Further information on this topic can be found in the 'Quickstart guide to packet
   classification' section of this document.

   3) add direction (ingress, egress) awareness to measured IP traffic flows. Direction
   can be defined statically (in, out) or inferred dinamically (tag, tag2) via the use
   of the nfprobe_direction directive. Let's look at a dynamic example using tag2;
   first, add the following lines to the daemon configuration:

nfprobe_direction[plugin_name]: tag2
pre_tag_map: /path/to/pretag.map

   then edit the tag map as follows. A return value of '1' means ingress while '2' is
   translated to egress. It is possible to define L2 and/or L3 addresses to recognize
   flow directions. The 'set_tag2' primitive (tag2) will be used to carry the return
   value:

set_tag2=1 filter='dst host XXX.XXX.XXX.XXX'
set_tag2=2 filter='src host XXX.XXX.XXX.XXX'

set_tag2=1 filter='ether src XX:XX:XX:XX:XX:XX'
set_tag2=2 filter='ether dst XX:XX:XX:XX:XX:XX'

   Indeed in such a case, the 'set_tag' primitive (tag) can be leveraged to other uses
   (ie. filter sub-set of the traffic for flow export);

   4) add interface (input, output) awareness to measured IP traffic flows. Interfaces
   can be defined only in addition to direction. Interface can be either defined
   statically (<1-4294967295>) or inferred dynamically (tag, tag2) with the use of the
   nfprobe_ifindex directive. Let's look at a dynamic example using tag; first add the
   following lines to the daemon config:

nfprobe_direction[plugin_name]: tag
nfprobe_ifindex[plugin_name]: tag2
pre_tag_map: /path/to/pretag.map 

   then edit the tag map as follows:

set_tag=1 filter='dst net XXX.XXX.XXX.XXX/WW' jeq=eval_ifindexes
set_tag=2 filter='src net XXX.XXX.XXX.XXX/WW' jeq=eval_ifindexes
set_tag=1 filter='dst net YYY.YYY.YYY.YYY/ZZ' jeq=eval_ifindexes
set_tag=2 filter='src net YYY.YYY.YYY.YYY/ZZ' jeq=eval_ifindexes
set_tag=1 filter='ether src YY:YY:YY:YY:YY:YY' jeq=eval_ifindexes
set_tag=2 filter='ether dst YY:YY:YY:YY:YY:YY' jeq=eval_ifindexes
set_tag=999 filter='net 0.0.0.0/0'
!
set_tag2=100 filter='dst host XXX.XXX.XXX.XXX' label=eval_ifindexes
set_tag2=100 filter='src host XXX.XXX.XXX.XXX'
set_tag2=200 filter='dst host YYY.YYY.YYY.YYY'
set_tag2=200 filter='src host YYY.YYY.YYY.YYY'
set_tag2=200 filter='ether src YY:YY:YY:YY:YY:YY'
set_tag2=200 filter='ether dst YY:YY:YY:YY:YY:YY'

  The set_tag=999 works as a catch all for undefined L2/L3 addresses so
  to prevent searching further in the map. In the example above direction
  is set first then, if found, interfaces are set, using the jeq/label
  pre_tag_map construct.

c) build NetFlow collector configuration, using nfacctd:
!
daemonize: true
nfacctd_ip: 1.2.3.4
nfacctd_port: 2100
plugins: memory[display]
aggregate[display]: src_host, dst_host, src_port, dst_port, proto
! aggregate[display]: class, src_host, dst_host, src_port, dst_port, proto

d) Ok, we are done ! Now fire both daemons:

   shell a> pmacctd -f /path/to/configuration/pmacctd-nfprobe.conf
   shell b> nfacctd -f /path/to/configuration/nfacctd-memory.conf


XIII. Quickstart guide to setup a sFlow agent/probe
pmacct can export traffic data via sFlow; such protocol is different from NetFlow/
IPFIX: in short, it works by exporting portions of sampled packets rather than
caching and building uni-directional flows as it happens in NetFlow; this not
stateful approach makes sFlow a light export protocol well-tailored for high-
speed networks. Furthermore, sFlow v5 can be extended much like NetFlow v9: meaning
classification information (if nDPI is compiled in, see 'Quickstart guide to packet
classification' section of this document), tags or basic Extended Gateway info
(ie. src_as, dst_as) can be easily included in the record structure being exported.
Below a quickstarter guide:

b) build sFlow probe configuration, using pmacctd:
!
daemonize: true
pcap_interface: eth0
plugins: sfprobe
sampling_rate: 20
sfprobe_agentsubid: 1402
sfprobe_receiver: 1.2.3.4:6343
!
! networks_file: /path/to/networks.lst
! snaplen: 700
!...


XIV. Quickstart guide to setup the BGP daemon
BGP can be run as a stand-alone collector daemon (pmbgpd, from 1.6.1) or as a
thread within one of the traffic accounting daemons (ie. nfacctd). The stand-
alone daemon is suitable for the Looking-Glass use-case, building BGP xconnects
and consuming BGP data, real-time or at regular intervals; the thread solution
is suitable for correlation of BGP with other data sources, ie. NetFlow, IPFIX,
sFlow, etc. The thread implementation idea is to receive data-plane information,
ie. via NetFlow, sFlow, etc., and control plane information, ie. full routing
tables via BGP, from edge routers. Per-peer BGP RIBs are maintained to ensure
local views of the network, a behaviour close to that of a BGP route-server.
In case of routers with default-only or partial BGP views, the default route
can be followed up (bgp_default_follow); also it might be desirable in certain
situations, for example trading-off resources to accuracy, to map one or a set
of flow agents to a BGP peer (bgp_agent_map). 

The following configuration snippet shows how to set up a BGP thread (ie. part
of the NetFlow/IPFIX collector, nfacctd) which will bind to an IP address and
will support up to a maximum number of 100 peers. Once PE routers start sending
flow telemetry data and peer up, it should be possible to see the BGP-related
fields, ie. as_path, peer_as_dst, local_pref, med, etc., correctly populated
while querying the memory table:

bgp_daemon: true
bgp_daemon_ip: X.X.X.X
bgp_daemon_max_peers: 100
! bgp_daemon_as: 65555
nfacctd_as: bgp
[ ... ]
plugins: memory
aggregate: src_as, dst_as, local_pref, med, as_path, peer_dst_as 

Setting up the stand-alone BGP collector daemon, pmbgpd, is not very different
at all from the configuration above:

bgp_daemon_ip: X.X.X.X
bgp_daemon_max_peers: 100
! bgp_daemon_as: 65555
bgp_table_dump_file: /path/to/spool/bgp-$peer_src_ip-%H%M.log
bgp_table_dump_refresh_time: 300

Essentially: the 'bgp_daemon: true' line is not required and there is no need
to instantiate plugins. On the other hand, the BGP daemon is instructed to dump
BGP tables to disk every 300 secs with file names embedding the BGP peer info
($peer_src_ip) and time reference (%H%M).

The BGP implementation, by default, reads the remote ASN upon receipt of a BGP
OPEN message and dynamically presents itself as part of the same ASN - this is
to ensure an iBGP relationship is established even in multi ASN scenarios. As
of 1.6.2, it is possible to put pmacct in a specific ASN of choice by using the
bgp_daemon_as configuration directive, for example, to establish an eBGP kind
of relationship. Also, the daemon acts as a passive BGP neighbor and hence will
never try to re-establish a fallen peering session. For debugging purposes
related to the BGP feed(s), bgp_daemon_msglog_* configuration directives can be
enabled in order to log BGP messaging.

XIVa. Limiting AS-PATH and BGP community attributes length
AS-PATH and BGP communities can get easily long when represented as strings.
Sometimes only a small portion of their content is of interest and hence a
simple filtering layer was developed in order to take special care of these
BGP attributes. bgp_aspath_radius cuts the AS-PATH down after a specified
amount of AS hops; whereas the bgp_stdcomm_pattern does a simple sub-string
matching against standard BGP communities, filtering in only those that match
(optionally, for better precision, a pre-defined number of characters can be
wildcarded by employing the '.' symbol, like in regular expressions). See an
example below:

bgp_aspath_radius: 3
bgp_stdcomm_pattern: 12345:

A detailed description of these configuration directives is, as usual, included in
the CONFIG-KEYS document. 

XIVb. The source peer AS case 
The peer_src_as primitive adds useful insight in understanding where traffic enters
the observed routing domain; but asymmetric routing impacts accuracy delivered by
devices configured with either NetFlow or sFlow and the peer-as feature (as it only
performs a reverse lookup, ie. a lookup on the source IP address, in the BGP table
hence saying where it would route such traffic). pmacct offers a few ways to perform
some mapping to tackle this issue and easily model both private and public peerings,
both bi-lateral or multi-lateral. Find below how to use a map, reloadable at runtime,
and its contents (for full syntax guide lines, please see the 'peers.map.example'
file within the examples section):

bgp_peer_src_as_type: map
bgp_peer_src_as_map: /path/to/peers.map

[/path/to/peers.map]
set_tag=12345 ip=A.A.A.A in=10 bgp_nexthop=X.X.X.X
set_tag=34567 ip=A.A.A.A in=10

set_tag=45678 ip=B.B.B.B in=20 src_mac=00:11:22:33:44:55
set_tag=56789 ip=B.B.B.B in=20 src_mac=00:22:33:44:55:66

Even though all this mapping is static, it can be auto-provisioned to a good degree
by means of external scripts running at regular intervals and, for example, querying
relevant routers via SNMP. In this sense, the bgpPeerTable MIB is a good starting
point. Alternatively pmacct also offers the option to perform reverse BGP lookups.

NOTES:
* When using maps, the peer_src_as primitive should be used with care if egress
  NetFlow/IPFIX/sFlow is in use as it mainly relies on either the input interface
  index (ifIndex), the source MAC address, a reverse BGP next-hop lookup or a
  combination of these. For example, egress NetFlow enabled on edge devices on
  core interfaces may work as the input ifIndex would still be visible; egress
  NetFlow enabled on edge devices on edge interfaces may not work as, unless
  traffic is locally switched, it may be sampled upon exiting the observed netowrk.
* "Source" MED, local preference, communities and AS-PATH have all been allocated
  aggregation primitives. Each carries its own peculiarities but the general concepts
  highlighed in this chapter apply to these aswell. Check CONFIG-KEYS out for the
  src_[med|local_pref|as_path|std_comm|ext_comm|lrg_comm]_[type|map] configuration
  directives.

XIVc. Tracking entities on the own IP address space
It might happen that not all entities connected to the observed network are
running BGP but rather they get assigned provider IP prefixes redistributed
into iBGP (different routing protocols, statics, directly connected, etc.).
These can be private IP addresses or segments of the SP public address space.
The common factor to all of them is that while being present in iBGP, these
prefixes can't be distinguished any further due to the lack of attributes like
AS-PATH or an ASN. One simple solution, although costly, could be to account
on IP prefixes (other than BGP attributes). Another simple solution, especially
if the enity is dominated by outbound traffic (ingress in the observed network)
could be to use a bgp_peer_src_as_map directive, described previously (ie. make
use of interface descriptions as a possible way to automate the process).
Alterntively, the bgp_stdcomm_pattern_to_asn directive was developed to fit in
this scenario: assuming procedures of a SP are (or can be changed) to label
every relevant non-BGP speaking entity IP prefixes uniquely with BGP standard
communities, this directive then allows to map the community to a peer AS/
origin AS couple as per the following example: XXXXX:YYYYY => Peer-AS=XXXXX,
Origin-AS=YYYYY. 

XIVd. Preparing the router to BGP peer 
Once the collector is configured and started up the remaining step is to let
routers export traffic samples to the collector and BGP peer with it. By
configuring the same source IP address across both NetFlow and BGP features
allows the collector to perform the required correlations without further
configuration. Also, setting the BGP Router ID accordingly allows for more
clear log messages. On the routers it is adviceable to configure the BGP
session with the collector as a Route-Reflector (RR) client.

A relevant configuration example for a Cisco router follows:

ip flow-export source Loopback12345
ip flow-export version 5
ip flow-export destination X.X.X.X 2100
!
router bgp 12345
 neighbor X.X.X.X remote-as 12345
 neighbor X.X.X.X update-source Loopback12345
 neighbor X.X.X.X version 4
 neighbor X.X.X.X send-community
 neighbor X.X.X.X route-reflector-client
 neighbor X.X.X.X description nfacctd 

A relevant configuration example for a Juniper router follows:

forwarding-options {
    sampling {
        output {
            cflowd X.X.X.X {
                port 2100;
                source-address Y.Y.Y.Y;
                version 5;
            }
        }
    }
}
protocols bgp {
    group rr-netflow {
        type internal;
        local-address Y.Y.Y.Y;
        family inet {
            any;
        }
        cluster Y.Y.Y.Y;
        neighbor X.X.X.X {
            description "nfacctd";
        }
    }
}

Contribution of further configuration examples for Cisco and Juniper devices
and/or other relevant vendors is more than welcome. 

XIVe. Example: writing flows augmented by BGP to a MySQL database
The following setup is a realistic example for collecting an external traffic
matrix to the ASN level (ie. no IP prefixes collected) for a MPLS-enabled IP
carrier network. Samples are aggregated in a way which is suitable to get an
overview of traffic trajectories, collecting much information where these enter
the AS and where they get out. 

daemonize: true
nfacctd_port: 2100
nfacctd_time_new: true

plugins: mysql[5mins], mysql[hourly]

sql_optimize_clauses: true
sql_dont_try_update: true
sql_multi_values: 1024000

sql_history_roundoff[5mins]: m
sql_history[5mins]: 5m
sql_refresh_time[5mins]: 300
sql_table[5mins]: acct_bgp_5mins

sql_history_roundoff[hourly]: h
sql_history[hourly]: 1h
sql_refresh_time[hourly]: 3600
sql_table[hourly]: acct_bgp_1hr

bgp_daemon: true
bgp_daemon_ip: X.X.X.X
bgp_daemon_max_peers: 100
bgp_aspath_radius: 3
bgp_follow_default: 1 
nfacctd_as: bgp
bgp_peer_src_as_type: map
bgp_peer_src_as_map: /path/to/peers.map

plugin_buffer_size: 10240
plugin_pipe_size: 1024000
aggregate: tag, src_as, dst_as, peer_src_as, peer_dst_as, peer_src_ip, peer_dst_ip, local_pref, as_path

pre_tag_map: /path/to/pretag.map
maps_refresh: true
maps_entries: 3840

The content of the maps (bgp_peer_src_as_map, pre_tag_map) is meant to be pretty
standard and will not be shown. As it can be grasped from the above configuration,
the SQL schema was customized. Below a suggestion on how this can be modified for
more efficiency - with additional INDEXes, to speed up specific queries response
time, remaining to be worked out:

create table acct_bgp_5mins (
        id INT(4) UNSIGNED NOT NULL AUTO_INCREMENT,
        agent_id INT(4) UNSIGNED NOT NULL,
        as_src INT(4) UNSIGNED NOT NULL,
        as_dst INT(4) UNSIGNED NOT NULL,
        peer_as_src INT(4) UNSIGNED NOT NULL,
        peer_as_dst INT(4) UNSIGNED NOT NULL,
        peer_ip_src CHAR(15) NOT NULL,
        peer_ip_dst CHAR(15) NOT NULL,
        as_path CHAR(21) NOT NULL,
        local_pref INT(4) UNSIGNED NOT NULL,
        packets INT UNSIGNED NOT NULL,
        bytes BIGINT UNSIGNED NOT NULL,
        stamp_inserted DATETIME NOT NULL,
        stamp_updated DATETIME,
        PRIMARY KEY (id),
        INDEX ...
) TYPE=MyISAM AUTO_INCREMENT=1;

create table acct_bgp_1hr (
        id INT(4) UNSIGNED NOT NULL AUTO_INCREMENT,
        agent_id INT(4) UNSIGNED NOT NULL,
        as_src INT(4) UNSIGNED NOT NULL,
        as_dst INT(4) UNSIGNED NOT NULL,
        peer_as_src INT(4) UNSIGNED NOT NULL,
        peer_as_dst INT(4) UNSIGNED NOT NULL,
        peer_ip_src CHAR(15) NOT NULL,
        peer_ip_dst CHAR(15) NOT NULL,
        as_path CHAR(21) NOT NULL,
        local_pref INT(4) UNSIGNED NOT NULL,
        packets INT UNSIGNED NOT NULL,
        bytes BIGINT UNSIGNED NOT NULL,
        stamp_inserted DATETIME NOT NULL,
        stamp_updated DATETIME,
        PRIMARY KEY (id),
        INDEX ...
) TYPE=MyISAM AUTO_INCREMENT=1;

Although table names are fixed in this example, ie. acct_bgp_5mins, it can be
highly adviceable in real-life to run dynamic SQL tables, ie. table names that
include time-related variables (see sql_table, sql_table_schema in CONFIG-KEYS). 

XIVf. Example: exporting BGP tables or messaging to files or AMQP/Kafka brokers.
Both the stand-alone BGP collector daemon (pmbgpd) and the BGP thread within one
of the traffic accounting daemons can: a) export/dump routing tables for all BGP
peers at regular time intervals and b) log BGP messaging, real-time, with each
of the BGP peers. Both features are useful for producing data useful for
analytics, for troubleshooting and debugging. The former is beneficial to gain
visibility in extra BGP data while providing event compression; the latter
enables BGP analytics and BGP event management, for example spot unstable
routes, trigger alarms on route hijacks, etc. 

Both features export data formatted as JSON messages, hence compiling pmacct
against libjansson is a requirement. See how to compile pmacct with JSON/
libjansson support in the section "Compiling pmacct with JSON support" of this
document. If writing to AMQP or Kafka brokers compiling against RabbitMQ or
Kafka libraries is required; read more in respectively the "Running the
RabbitMQ/AMQP plugin" or "Running the Kafka plugin" sections of this document.

A basic dump of BGP tables at regular intervals (60 secs) to plain-text files,
split by BGP peer and time of the day, is configured as follows:

bgp_table_dump_file: /path/to/spool/bgp/bgp-$peer_src_ip-%H%M.txt
bgp_table_dump_refresh_time: 60

A basic log of BGP messaging in near real-time to a plain-text file (which can
be rotated by an external tool/script) is configured as follows:

bgp_daemon_msglog_file: /path/to/spool/bgp/bgp-$peer_src_ip.log

A basic dump of BGP tables at regular intervals (60 secs) to a Kafka broker,
listening on the localost and default port, is configured as follows:

bgp_table_dump_kafka_topic: pmacct.bgp
bgp_table_dump_refresh_time: 60

The equivalent bgp_table_dump_amqp_routing_key config directive can be used to
make the above example work against a RabbitMQ broker.

A basic log of BGP messaging in near real-time to a Kafka broker, listening on
the localhost and default port, is configured as follows:

bgp_daemon_msglog_kafka_topic: pmacct.bgp

The equivalent bgp_daemon_msglog_amqp_routing_key config directive can be used
to make the above example work against a RabbitMQ broker.

A sample of both the BGP msglog and dump formats are captured in the following
document: docs/MSGLOG_DUMP_FORMATS

XIVg. Example: querying the BGP daemon via the Looking Glass server.
Starting with release 1.7.1 pmbgpd, the pmacct BGP standalone daemon, includes
a Looking Glass server to query available BGP RIBs. The server is asyncronous
and uses ZeroMQ as transport layer to serve incoming queries. The LG server can
be configured as follows:

bgp_daemon_lg: true
bgp_daemon_lg_user: pmacct
bgp_daemon_lg_passwd: arealsmartpwd 

This configuration will enable plain authentication and will make the server
listen on all interfaces on port 17900/TCP. Following an example of querying
with the Python client available in 'examples/lg':

Get the list of available BGP peers:

shell> examples/lg/pmbgp.py -g
{"results": 1, "query_type": 2}
{"peer_ip_src": "192.168.1.1", "peer_id": "192.168.1.1", "peer_tcp_port": 47248, "peer_as": 65500}
 
Lookup IP prefix 192.168.2.0/24 for BGP peer 192.168.1.1:

shell> examples/lg/pmbgp.py -a 192.168.2.0/24 -r 192.168.1.1
{"peer_ip_src": "192.168.1.1", "event_type": "lglass", "afi": 1, "safi": 1, "ip_prefix": "192.168.2.0/24", "bgp_nexthop": "192.168.1.254", "as_path": "65500 65501 65502", "comms": "65500:1 65500:100 65500:65500", "origin": 0, "local_pref": 100}

Request/Reply Looking Glass formats are documented in 'docs/LOOKING_GLASS_FORMAT'.

XIVh. Example: BGP Xconnects 
Starting with release 1.7.1 pmbgpd, the pmacct BGP standalone daemon, includes
a new BGP xconnect feature to map BGP peers (ie. PE routers) to BGP collectors
(ie. nfacctd, sfacctd). The aim is to facilitate operations when re-sizing/re-
balancing the collection infrastructure without impacting (ie. re-configuring)
BGP peers. A few caveats apply: 1) mapping works only against the IP source
address and not the BGP Router ID, 2) only 1:1 relationships can be formed
(ie. this is about cross-connecting, not replication) and 3) only one session
per BGP peer is supported (ie. multiple BGP agents are running on the same IP
address or NAT traversal scenarios are not supported [yet]). The feature can
be configured as follows:

bgp_daemon_xconnect_map: /path/to/bgp_xconnects.map

And the content of the map can be defined as follows:

bgp_dst=10.0.0.1:17901  bgp_src=192.168.0.1
bgp_dst=10.0.0.1:17902  bgp_src=192.168.0.2
bgp_dst=10.0.0.1:17910  bgp_src=192.168.10.0/24

Where bgp_dst is the IPv4/IPv6 address and port of the BGP collector to cross-
connect incoming (bgp_src) BGP session to and bgp_src is compared against the
IPv4/IPv6 address (not BGP Router ID) of an incoming BGP session from a BGP
peer. At the collector end one should set tmp_bgp_lookup_compare_ports (read
more about this knob in CONFIG-KEYS) to true. 

XIVg. BGP daemon implementation concluding notes
The implementation supports 4-bytes ASN, IPv4, IPv6, VPNv4 and VPNv6 (MP-BGP)
address families and several IETF drafts and RFCs, ie. ADD-PATH, Shutdown
Message and Large BGP Communities among the others; IPv4, IPv6 transports for
BGP sessions are supported. When storing data via SQL, BGP primitives can be
freely mix-and-matched with other primitives (ie. L2/L3/L4) when customizing
the SQL table (sql_optimize_clauses: true). Environments making use of BGP
Multi-Path should make use of ADD-PATH to advertise known paths in which case
the correct BGP info is linked to traffic data using BGP next-hop (or IP next-
hop if use_ip_next_hop is set to true) as selector among the paths available
(on the assumption that ADD-PATH is used for route diversity; all checked
implementations seem to tend to not advertise paths with the same next-hop).
TCP MD5 signature for BGP messages is also supported. For a review of all knobs
and features see the CONFIG-KEYS document. 


XV. Quickstart guide to setup a NetFlow/IPFIX/sFlow replicator
The 'tee' plugin is meant to replicate NetFlow/sFlow data to remote collectors.
The plugin can act transparently, by preserving the original IP address of the
datagrams, or as a proxy. Basic configuration of up a replicator is very easy:
all is needed is where to listen to for incoming packets, where to replicate
them to and optionally a filtering layer, if required. Filtering bases on the
standard pre_tag_map infrastructure; here is presented only coarse-grained
filtering against the NetFlow/sFlow source IP address (see next section for
finer-grained filtering). 

nfacctd_port: 2100
nfacctd_ip: X.X.X.X
!
plugins: tee[a], tee[b]
tee_receivers[a]: /path/to/tee_receivers_a.lst
tee_receivers[b]: /path/to/tee_receivers_b.lst
! tee_transparent: true
!
! pre_tag_map: /path/to/pretag.map
!
plugin_buffer_size: 10240
plugin_pipe_size: 1024000
nfacctd_pipe_size: 1024000

An example of content of a tee_receivers map, ie. /path/to/tee_receivers_a.lst,
is as follows ('id' is the pool ID and 'ip' a comma-separated list of receivers
for that pool):

id=1	ip=W.W.W.W:2100
id=2	ip=Y.Y.Y.Y:2100,Z.Z.Z.Z:2100
! id=1	ip=W.W.W.W:2100			tag=0
! id=2	ip=Y.Y.Y.Y:2100,Z.Z.Z.Z:2100	tag=100

Number of tee_receivers map entries (by default 384) can be modified via
maps_entries. Content can be reloaded at runtime by sending the daemon a
SIGUSR2 signal (ie. "killall -USR2 nfacctd").

Selective teeing allows to filter which pool of receivers has to receive which
datagrams. Tags are applied via a pre_tag_map, the one illustrated below applies
tag 100 to packets exported from agents A.A.A.A, B.B.B.B and C.C.C.C; in case
there was also an agent D.D.D.D exporting towards the replicator, its packets
would intuitively remain untagged. Tags are matched by a tee_receivers map, see
above the two pool definitions commented out containing the 'tag' keyword: the
definition would cause untagged packets (tag=0) to be replicated only to pool
#1 whereas packets tagged as 100 (tag=100) to be replicated only to pool #2.
More examples in the pretag.map.example and tee_receivers.lst.example files in
the examples/ sub-tree:

set_tag=100	ip=A.A.A.A
set_tag=100	ip=B.B.B.B
set_tag=100	ip=C.C.C.C

To enable the transparent mode, the tee_transparent should be commented out. It
preserves the original IP address of the NetFlow/sFlow sender while replicating
by essentially spoofing it. This feature is not global and can be freely enabled
only on a subset of the active replicators. It requires super-user permissions
in order to run.

Concluding note: 'tee' plugin is not compatible with different plugins - within
the same daemon instance. So if in the need of using pmacct for both collecting
and replicating data, two separate instances must be used (intuitively with the
replicator instance feeding the collector one).

XVa. Splitting and dissecting sFlow flow samples
Starting with pmacct 1.6.2, it is possible to perform finer-grained filtering,
ie. against flow-specific primitives, when replicating. For example: replicate
flows from or to MAC address X1, X2 .. Xn to receiver Y or replicate flows in
VLAN W to receiver Z. The feature works by inspecting the original packet and
dissecting it as needed, the most popular use-case being IXPs replicating flows
back to the members originating and/or receiving them. Some of the supported
primitives are: source and destination MAC addresses, input/output interfaces
ifindex; the full list is available in examples/pretag.map.example (look for
"sfacctd, nfacctd when in 'tee' mode").

The feature is configured just like selective teeing shown in the previous
section. Incoming packets are tagged with a pre_tag_map and then matched to a
receiver in tee_receivers. Also, setting tee_dissect_send_full_pkt to true (by
default false) the original full frame is sent over to the tee plugin. For
example: replicate flows from/to MAC address XX:XX:XX:XX:XX:XX to receiver Y,
replicate flows from/to MAC address WW:WW:WW:WW:WW:WW to receiver Z, replicate
any remaining flows plus original frames to receiver J.

This is the pre_tag_map map:

set_tag=100     ip=0.0.0.0/0	src_mac=XX:XX:XX:XX:XX:XX
set_tag=100     ip=0.0.0.0/0	dst_mac=XX:XX:XX:XX:XX:XX
set_tag=200	ip=0.0.0.0/0	src_mac=WW:WW:WW:WW:WW:WW
set_tag=200	ip=0.0.0.0/0	dst_mac=WW:WW:WW:WW:WW:WW
set_tag=999	ip=0.0.0.0/0

This is the tee_receivers map:

id=100	ip=Y.Y.Y.Y:2100	tag=100
id=200	ip=Z.Z.Z.Z:2100	tag=200
id=999	ip=J.J.J.J:2100	tag=999

This is the relevant section from sfacctd.conf:

[ .. ]
!
tee_transparent: true
maps_index: true
!
plugins: tee[a]
!
tee_receivers[a]: /path/to/tee_receivers.lst
pre_tag_map[a]: /path/to/pretag.map
tee_dissect_send_full_pkt[a]: true

There are a few restrictions to the feature: 1) only sFlow v5 is supported, ie.
no NetFlow/IPFIX and no sFlow v2-v4; 2) only sFlow flow samples are supported,
ie. no counter samples. There are also a few known limitations all boiling down
to non-contextual replication: 1) once split, flows are not muxed back together,
ie. in case multiple samples part of the same packet are to be replicated to the
same receiver; 2) sequence numbers are untouched: the most obvious cases being
receivers may detect non-contiguous sequencing progressions or false duplicates.
If you are negatively affected by any of these restrictions or limitations or
you need other primitives to be supported by this feature, please do get in
touch.


XVI. Quickstart guide to setup the IS-IS daemon
pmacct integrates an IS-IS daemon as part of the IP accounting collectors. Such
daemon is run as a thread within the collector core process. The idea is to
receive data-plane information, ie. via NetFlow, sFlow, etc., and control-plane
information via IS-IS. Currently a single L2 P2P neighborship, ie. over a GRE
tunnel, is supported. The daemon is currently used for the purpose of route
resolution. A sample scenario could be that more specific internal routes might
be configured to get summarized in BGP while crossing cluster boundaries.  

Pre-requisite for the use of the IS-IS daemon is that the pmacct package has to
be configured for compilation with threads, this line will do it:

shell> ./configure

XVIa. Preparing the collector for the L2 P2P IS-IS neighborship
It's assumed the collector sits on an Ethernet segment and has not direct link
(L2) connectivity to an IS-IS speaker, hence the need to establish a GRE tunnel. 
While extensive literature and OS specific examples exist on the topic, a brief
example for Linux, consistent with rest of the chapter, is provided below:

ip tunnel add gre2 mode gre remote 10.0.1.2 local 10.0.1.1 ttl 255
ip link set gre2 up

The following configuration fragment is sufficient to set up an IS-IS daemon
which will bind to a network interface gre2 configured with IP address 10.0.1.1
in an IS-IS area 49.0001 and a CLNS MTU set to 1400:

isis_daemon: true
isis_daemon_ip: 10.0.1.1
isis_daemon_net: 49.0001.0100.0000.1001.00
isis_daemon_iface: gre2
isis_daemon_mtu: 1400
! isis_daemon_msglog: true

XVIb. Preparing the router for the L2 P2P IS-IS neighborship 
Once the collector is ready, the remaining step is to configure a remote router
for the L2 P2P IS-IS neighborship. The following bit of configuration (based on
Cisco IOS) will match the above fragment of configuration for the IS-IS daemon:

interface Tunnel0
 ip address 10.0.1.2 255.255.255.252
 ip router isis
 tunnel source FastEthernet0
 tunnel destination XXX.XXX.XXX.XXX
 clns mtu 1400
 isis metric 1000
!
router isis
 net 49.0001.0100.0000.1002.00
 is-type level-2-only
 metric-style wide
 log-adjacency-changes
 passive-interface Loopback0
!


XVII. Quickstart guide to setup the BMP daemon
BMP can be run as a stand-alone collector daemon (pmbmpd, from 1.6.1) or as a
thread within one of the traffic accounting daemons (ie. nfacctd). The stand-
alone daemon is suitable for consuming BMP data only, real-time or at regular
intervals; the thread solution is suitable for correlation of BMP with other
data sources, ie. NetFlow, IPFIX, sFlow, etc.. The implementation bases on
rfc7854 and adds elements from both draft-ietf-grow-bmp-adj-rib-out and
draft-ietf-grow-bmp-adj-loc-rib IETF documents. If unfamiliar with BMP, to
quote rfc7854: "BMP is intended to provide a more convenient interface for
obtaining route views for research purpose than the screen-scraping approach
in common use today. The design goals are to keep BMP simple, useful, easily
implemented, and minimally service-affecting.".

The BMP daemon currently supports BMP data, events and stats, ie. initiation,
termination, peer up, peer down, stats and route monitoring messages (that is
no route mirroring messages; please get in touch if an implementation is
wanted in this sense). The daemon enables to write BMP messages to files, AMQP
and Kafka brokers, real-time (msglog) or at regular time intervals (dump).
Also, route monitoring messages are saved in a RIB structure for IP prefix
lookup.

All features export data formatted as JSON messages, hence compiling pmacct
against libjansson is a requirement. See how to compile pmacct with JSON/
libjansson support in the section "Compiling pmacct with JSON support" of this
document. If writing to AMQP or Kafka brokers compiling against RabbitMQ or
Kafka libraries is required; read more in respectively the "Running the
RabbitMQ/AMQP plugin" or "Running the Kafka plugin" sections of this document.

Following a simple example on how to configure nfacctd to enable the BMP thread
to a) log, in real-time, BGP stats, events and routes received via BMP to a
text-file (bmp_daemon_msglog_file) and b) dump the same (ie. BGP stats and
events received via BMP) to a text-file and at regular time intervals
(bmp_dump_refresh_time, bmp_dump_file):

bmp_daemon: true
!
bmp_daemon_msglog_file: /path/to/bmp-$peer_src_ip.log
!
bmp_dump_file: /path/to/bmp-$peer_src_ip-%H%M.dump
bmp_dump_refresh_time: 60

Following a simple example on how to configure nfacctd to enable the BMP thread
to a) log, in real-time, BGP stats, events and routes received via BMP to a
Kafka broker (bmp_daemon_msglog_kafka_topic) and b) dump the same (ie. BGP stats
and events received via BMP) to a text-file and at regular time intervals
(bmp_dump_refresh_time, bmp_dump_kafka_topic):

bmp_daemon: true
!
bmp_daemon_msglog_kafka_topic: pmacct.bmp-msglog
!
bmp_dump_kafka_topic: pmacct.bmp-dump
bmp_dump_refresh_time: 60

The equivalent bmp_daemon_msglog_amqp_routing_key and bmp_dump_amqp_routing_key
config directives can be used to make the above example work against a RabbitMQ
broker.

A sample of both the BMP msglog and dump formats are captured in the following
document: docs/MSGLOG_DUMP_FORMATS

Setting up the stand-alone BMP collector daemon, pmbmpd, is the exact same as
the configuration above except the 'bmp_daemon: true' line can be skipped.

Following is an example how a Cisco router running IOS/IOS-XE should be
configured in order to export BMP data to a collector:

router bgp 64512
 bmp server 1
  address X.X.X.X port-number 1790
  initial-delay 60
  failure-retry-delay 60
  flapping-delay 60
  stats-reporting-period 300
  activate
 exit-bmp-server-mode
 !
 neighbor Y.Y.Y.Y remote-as 64513
 neighbor Y.Y.Y.Y bmp-activate all
 neighbor Z.Z.Z.Z remote-as 64514
 neighbor Z.Z.Z.Z bmp-activate all

Following is an example how a Cisco router running IOS-XR should be configured
in order to export BMP data to a collector:

router bgp 64512
 neighbor Y.Y.Y.Y
  bmp-activate server 1
 neighbor Z.Z.Z.Z
  bmp-activate server 1
 !
!
bmp server 1
 host X.X.X.X port 1790
 initial-delay 60
 initial-refresh delay 60
 stats-reporting-period 300
!

Following is an example how a Juniper router should be configured in order to
export BMP data to a collector:

routing-options {
	bmp {
		station FQDN {
			connection-mode active;
       			monitor enable;
			route-monitoring {
				pre-policy;
				post-policy;
			}
			station-address X.X.X.X;
			station-port 1790;
		}
	}
}

Any equivalent examples for other vendor implementing BMP are welcome.
 

XVIII. Quickstart guide to setup Streaming Telemetry collection
Quoting Cisco IOS-XR Telemetry Configuration Guide at the time of this writing:
"Streaming telemetry lets users direct data to a configured receiver. This 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. The data is used by development and operations (DevOps)
personnel who plan to optimize networks by collecting analytics of the network
in real-time, locate where problems occur, and investigate issues in a
collaborative manner.". Streaming telemetry support comes in pmacct in two
flavours: 1) a telemetry thread can be started in existing daemons, ie. sFlow,
NetFlow/IPFIX, etc. for the purpose of data correlation and 2) a new daemon
pmtelemetryd for standalone consumpton of data. Streaming telemetry data can
be logged real-time and/or dumped at regular time intervals to flat-files,
RabbitMQ or Kafka brokers.

All features export data formatted as JSON messages, hence compiling pmacct
against libjansson is a requirement. See how to compile pmacct with JSON/
libjansson support in the section "Compiling pmacct with JSON support" of this
document. If writing to AMQP or Kafka brokers compiling against RabbitMQ or
Kafka libraries is required; read more in respectively the "Running the
RabbitMQ/AMQP plugin" or "Running the Kafka plugin" sections of this document.

From a configuration standpoint both the thread (ie. telemetry configured part
of nfacctd) and the daemon (pmtelemetryd) are configured the same way except the
thread must be explicitely enabled with a 'telemetry_daemon: true' config line.
Hence the following examples hold for both the thread and the daemon setups.  

Following is a config example to receive telemetry data in JSON format over UDP
port 1620 and log it real-time to flat-files:

! Telemetry thread configuration
! telemetry_daemon: true 
!
telemetry_daemon_port_udp: 1620
telemetry_daemon_decoder: json
!
telemetry_daemon_msglog_file: /path/to/spool/telemetry-msglog-$peer_src_ip.txt
! telemetry_daemon_msglog_amqp_routing_key: telemetry-msglog
! telemetry_daemon_msglog_kafka_topic: telemetry-msglog

Following is a config example to receive telemetry data with Cisco proprietary
header (12 bytes), in compressed JSON format over TCP port 1620 and dump it at
60 secs time intervals to flat-files:

! Telemetry thread configuration
! telemetry_daemon: true
!
telemetry_daemon_port_tcp: 1620
telemetry_daemon_decoder: cisco_zjson
!
telemetry_dump_file: /path/to/spool/telemetry-dump-$peer_src_ip-%Y%m%d-%H%M.txt
telemetry_dump_latest_file: /path/to/spool/telemetry-dump-$peer_src_ip.latest
! telemetry_dump_amqp_routing_key: telemetry-dump
! telemetry_dump_kafka_topic: telemetry-dump
!
telemetry_dump_refresh_time: 60

A sample of both the Streaming Telemetry msglog and dump formats are captured in
the following document: docs/MSGLOG_DUMP_FORMATS


XIX. Running the print plugin to write to flat-files
pmacct can also output to files via the 'print' plugin. Dynamic filenames are
supported. Output is either text-based using JSON, CSV or formatted outputs, or
binary-based using the Apache Avro file container ('print_output' directive).
Interval between writes can be configured via the 'print_refresh_time'
directive. An example follows on how to write to files on a 15 mins basis in
CSV format:

print_refresh_time: 900
print_history: 15m
print_output: csv
print_output_file: /path/to/file-%Y%m%d-%H%M.txt
print_history_roundoff: m
 
Which, over time, would produce a would produce a series of files as follows:

-rw-------  1 paolo paolo   2067 Nov 21 00:15 blabla-20111121-0000.txt
-rw-------  1 paolo paolo   2772 Nov 21 00:30 blabla-20111121-0015.txt
-rw-------  1 paolo paolo   1916 Nov 21 00:45 blabla-20111121-0030.txt
-rw-------  1 paolo paolo   2940 Nov 21 01:00 blabla-20111121-0045.txt

JSON output requires compiling pmacct against Jansson library. See how to
compile pmacct with JSON/libjansson support in the section "Compiling pmacct
with JSON support" of this document.

Avro output requires compiling pmacct against libavro library. See how to
compile pmacct with Avro support in the section "Compiling pmacct with Apache
Avro support" of this document.

Splitting data into time bins is supported via print_history directive. When
enabled, time-related variable substitutions of dynamic print_output_file names
are determined using this value. It is supported to define print_refresh_time
values shorter than print_history ones by setting print_output_file_append to
true (which is generally also recommended to prevent that unscheduled writes to
disk, ie. due to caching issues, overwrite existing file content). A sample
config follows:

print_refresh_time: 300
print_history: 5m
print_output: csv
print_output_file: /path/to/%Y/%Y-%m/%Y-%m-%d/file-%Y%m%d-%H%M.txt
print_history: 15m
print_history_roundoff: m
print_output_file_append: true 

Writing to flat-files is also a suitable method to ingest data into 3rd
party applications (typically, but not limited to, noSQL databases like
ElasticSearch, InfluxDB, etc.). An example is the pmacct-to-elasticsearch
project https://github.com/pierky/pmacct-to-elasticsearch . 


XX. Quickstart guide to setup GeoIP lookups
pmacct can perform GeoIP country lookups against a Maxmind DB v1 (--enable-geoip)
and against a Maxmind DB v2 (--enable-geoipv2). A v1 database enables resolution
of src_host_country and dst_host_country primitives only. A v2 database enables
resolution of presently supported GeoIP-related primitives, ie. src_host_country,
src_host_pocode, dst_host_country, dst_host_pocode. Pre-requisite for the feature
to work are: a) a working installed Maxmind GeoIP library and headers and b) a
Maxmind GeoIP database (freely available). Two steps to quickly start with GeoIP
lookups in pmacct:
 
GeoIP v1 (libGeoIP):
* Have libGeoIP library and headers available to compile against; have a GeoIP
  database also available: http://dev.maxmind.com/geoip/legacy/install/country/ 

* To compile the pmacct package with support for GeoIP lookups, the code must
  be configured for compilation as follows:

  ./configure --enable-geoip [ ... ]

  But, for example, should you have installed libGeoIP in /usr/local/geoip and
  pkg-config is unable to help, you can supply this non-default location as
  follows (assuming you are running the bash shell):

  export GEOIP_LIBS="-L/usr/local/geoip/lib -lgeoip"
  export GEOIP_CFLAGS="-I/usr/local/geoip/include"
  ./configure --enable-geoip [ ... ]

* Include as part of the pmacct configuration the following fragment:

  ...
  geoip_ipv4_file: /path/to/GeoIP/GeoIP.dat  
  aggregate: src_host_country, dst_host_country, ...
  ...

GeoIP v2 (libmaxminddb):
* Have libmaxminddb library and headers to compile against, available at:
  https://github.com/maxmind/libmaxminddb/releases ; have also a database
  available: https://dev.maxmind.com/geoip/geoip2/geolite2/ . Only the
  database binary format is supported.

* To compile the pmacct package with support for GeoIP lookups, the code must
  be configured for compilation as follows:

  ./configure --enable-geoipv2 [ ... ]

  But, for example, should you have installed libmaxminddb in /usr/local/geoipv2
  and pkg-config is unable to help, you can supply this non-default location
  as follows (assuming you are running the bash shell):

  export GEOIPV2_LIBS="-L/usr/local/geoipv2/lib -lmaxminddb"
  export GEOIPV2_CFLAGS="-I/usr/local/geoipv2/include"
  ./configure --enable-geoipv2 [ ... ]

* Include as part of the pmacct configuration the following fragment:

  ...
  geoipv2_file: /path/to/GeoIP/GeoLite2-Country.mmdb
  aggregate: src_host_country, dst_host_country, ...
  ...

Concluding notes: 1) The use of --enable-geoip is mutually exclusive with
--enable-geoipv2; 2) more fine-grained GeoIP lookup primitives (ie. cities,
states, counties, metro areas, zip codes, etc.) are not yet supported: should
you be interested into any of these, please get in touch.  


XXI. Using pmacct as traffic/event logger
pmacct was originally conceived as a traffic aggregator. It is now possible
to use pmacct as a traffic/event logger as well, such development had been 
fostered particularly by the use of NetFlow/IPFIX as generic transport,
see for example Cisco NEL and Cisco NSEL. Key to logging are time-stamping
primitives, timestamp_start and timestamp_end: the former records the likes
of libpcap packet timestamp, sFlow sample arrival time, NetFlow observation
time and flow first switched time; timestamp_end currently only makes sense
for logging flows via NetFlow. Still, the exact boundary between aggregation
and logging can be defined via the aggregation method, ie. no assumptions are
made. An example to log traffic flows follows:

! ...
!
plugins: print[traffic] 
!
aggregate[traffic]: src_host, dst_host, peer_src_ip, peer_dst_ip, in_iface, out_iface, timestamp_start, timestamp_end, src_port, dst_port, proto, tos, src_mask, dst_mask, src_as, dst_as, tcpflags
print_output_file[traffic]: /path/to/traffic-%Y%m%d_%H%M.txt
print_output[traffic]: csv
print_history[traffic]: 5m
print_history_roundoff[traffic]: m
print_refresh_time[traffic]: 300
! print_cache_entries[traffic]: 9999991
print_output_file_append[traffic]: true
!
! ...

An example to log specifically CGNAT (Carrier Grade NAT) events from a
Cisco ASR1K box follows:

! ...
!
plugins: print[nat]
!
aggregate[nat]: src_host, post_nat_src_host, src_port, post_nat_src_port, proto, nat_event, timestamp_start
print_output_file[nat]: /path/to/nat-%Y%m%d_%H%M.txt
print_output[nat]: json
print_history[nat]: 5m
print_history_roundoff[nat]: m
print_refresh_time[nat]: 300
! print_cache_entries[nat]: 9999991
print_output_file_append[nat]: true
!
! ...

The two examples above can intuitively be merged in a single configuration
so to log down in parallel both traffic flows and events. To split flows
accounting from events, ie. to different files, a pre_tag_map and two print
plugins can be used as follows:

! ...
!
pre_tag_map: /path/to/pretag.map
!
plugins: print[traffic], print[nat]
!
pre_tag_filter[traffic]: 10
aggregate[traffic]: src_host, dst_host, peer_src_ip, peer_dst_ip, in_iface, out_iface, timestamp_start, timestamp_end, src_port, dst_port, proto, tos, src_mask, dst_mask, src_as, dst_as, tcpflags
print_output_file[traffic]: /path/to/traffic-%Y%m%d_%H%M.txt
print_output[traffic]: csv
print_history[traffic]: 5m 
print_history_roundoff[traffic]: m 
print_refresh_time[traffic]: 300
! print_cache_entries[traffic]: 9999991
print_output_file_append[traffic]: true
!
pre_tag_filter[nat]: 20
aggregate[nat]: src_host, post_nat_src_host, src_port, post_nat_src_port, proto, nat_event, timestamp_start 
print_output_file[nat]: /path/to/nat-%Y%m%d_%H%M.txt
print_output[nat]: json
print_history[nat]: 5m 
print_history_roundoff[nat]: m 
print_refresh_time[nat]: 300
! print_cache_entries[nat]: 9999991
print_output_file_append[nat]: true
!
! ...

In the above configuration both plugins will log their data in 5 mins files
basing on the 'print_history[<plugin name>]: 5m' configuration directive, ie.
traffic-20130802-1345.txt traffic-20130802-1350.txt traffic-20130802-1355.txt
etc. Granted appending to output file is set to true, data can be refreshed
at shorter intervals than 300 secs. This is a snippet from /path/to/pretag.map
referred above:

set_tag=10      ip=A.A.A.A	sample_type=flow
set_tag=20      ip=A.A.A.A	sample_type=event
set_tag=10      ip=B.B.B.B	sample_type=flow
set_tag=20      ip=B.B.B.B	sample_type=event
!
! ...


XXII. Miscellaneous notes and troubleshooting tips
This chapter will hopefully build up to the point of providing a taxonomy of
popular cases to troubleshoot by daemon and what to do. Although that is the
plan, the current format is sparse notes.  

When reporting a bug: please report in all cases the pmacct version that you
are experiencing your issue against; the CLI option -V of the daemon you are
using returns all the info needed (daemon, version, specific release and
options compiled in). Do realise that if using a pre-packaged version from
your OS and/or old code (ie. not master code on GitHub or latest official
release), you may be very possibly asked to try one of these first. Finally,
please refrain to open issues on GitHub if not using master code (use the
pmacct-discussion mailing list or unicast email instead). 

a) Here are recap some popular issues when compiling pmacct or linking it at
runtime against shared libraries:

  1) /usr/local/sbin/pmacctd: error while loading shared libraries:
     librabbitmq.so.4: cannot open shared object file: No such file or directory 

     This can happen at runtime and, especially in case of freshly downloaded
     and compiled libraries, it is a symptom that after installing the shared
     library, ldconfig was not called. Or alternatively that the directory
     where the library is located is not inserted in /etc/ld.so.conf or in any
     files included it includes. When not having super-user privileges, this
     can be fixed in the own environment setting the LD_LIBRARY_PATH variable.

  2) json_array_foreach(json_list, key, value) {
                                               ^
     nfv9_template.c: In function ‘nfacctd_offline_read_json_template’:
     nfv9_template.c:572:53: error: expected ‘;’ before ‘{’ token

     This can happen at compile time and and is a bit tricky to hint. In this
     example the function json_array_foreach() is not being recognized, in
     other words while the library could be located, it does not contain the
     specific function. This is a symptom that the library version in use is
     too old. Typical situation is when using a packaged library rather than
     a freshly downloaded and compiled latest stable release. 

  3) /usr/local/lib/libpcap.so: undefined reference to `pcap_lex'
     collect2: error: ld returned 1 exit status
     make[2]: *** [pmacctd] Error 1

     This can happen at compile time and it is a symptom that the needed
     library could not be located by the linker. This is a symptom that the 
     library could be in some non-standard location and the linked need an
     hint. For libpcap --with-pcap-libs knob is available at configure time;
     for all other libraries the library_LIBS and library_CFLAGS environment
     variables are available. See examples in the "Configuring pmacct for
     compilation and installing" section of this document.

b) In case of crashes of an any process, regardless if predictable or not, the
advice is to run the daemon with "ulimit -c unlimited" so to generate a core
dump. The core dump file location, on Linux, is determined by the following
file: /proc/sys/kernel/core_pattern : if the value is "core", then the file is
placed in the directory where the daemon is started so it is good to take care
of that. pmacct developers will then ask for one or both of the following: 1)
the core file along with the crashing executable and its configuration be made
available for further inspection and/or 2) a backtrace in GDB obtained via the
following two steps:

shell> gdb /path/to/executable /path/to/core

Then once in the gdb console the backtrace output can be obtained with the
following command:

gdb> bt

If the dmesg command or system logs reveal a line like the following one:

Jan 01 00:00:00 xxxx kernel: [4075819.569587] nfacctd[51817]: segfault at 10 ip 00007f77f448ad44 sp 00007ffc6974ed70 error 4 ..

In certain cases, ie. if the crash is not inside a shared library, this can
return useful information for debugging when examined with addr2line; using
the example above:

shell> addr2line /path/to/nfacctd 00007f77f448ad44

Optionally, especially if the issue can be easily reproduced, the daemon can
be re-configured for compiling with the --enable-debug flag so to produce
extra info suitable for troubleshooting. 

c) In case of (suspected) memory leaks, the advice is to: 1) re-compile pmacct
with "./configure --enable-debug <other flags already in use>"; --enable-debug
sets as CFLAGS -O0 -g -Wall where especially -O0 is capital since it disables
any code optimizations the compiler may introduce; 2) run the resulting daemon
under valgrind, ie. "valgrind --leak-check=yes <pmacct command-line>". A memory
leak is confirmed if the amount of "definitely lost" bytes keeps increasing
over time. 

d) In the two cases of nfacctd/sfacctd or nfprobe/sfprobe not showing signs of
input/output data: 1) check with tcpdump, ie. "tcpdump -i <interface> -n port
<sfacctd/nfacctd listening port>", that packets are emitted/received. Optionally
Wireshark (or its commandline counterpart tshark) can be used, in conjunction
with decoders ('cflow' for NetFlow/IPFIX and 'sflow' for sFlow), to validate
packets are consistent; this proofs there is no filtering taking place in
between exporters and collector; 2) check firewall settings on the collector
box, ie. "iptables -L -n" on Linux (disable or do appropriate holes): tcpdump
may see packets hitting the listening port as, in normal kernel operations, the
filtering happens after the raw socket (the one used by tcpdump) is served; you
can additionally certainly check with 3rd party equivalent applications or, say,
'netcat' that the same behaviour is obtained as with pmacct ones 3) especially
in case of copy/paste of configs or if using a config from a production system
in lab, disable or double-check values for internal buffering: if set too high
they will likely retain data internally to the daemon; 4) if multiple interfaces
are configured on a system, try to disable (at least for a test) rp_filtering.
See http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html for more info
on RP filtering. The value of rp_filter files in /proc must be set to zero in
order to disable RP filtering. This appears a popular issue when replicating
flow data with tee_transparent feature enabled (that is, packet spoofing);
5) in case aggregate_filter is in use: the feature expects a libpcap-style
filter as value. BPF filters are sensible to both VLAN tags and MPLS labels:
if, for example, the traffic is VLAN tagged and the value of aggregate_filter
is 'src net X.X.X.X/Y', there will be no match for VLAN-tagged traffic from src
net X.X.X.X/Y; the filter should be re-written as 'vlan and src net X.X.X.X/Y';
6) in case of NetFlow v9/IPFIX collection, two protocols that are template-based,
the issue may be with templates not being received by nfacctd (in which case by
enabling debug you may see "Discarded NetFlow v9/IPFIX packet (R: unknown
template [ .. ]" messages in your logs); you can confirm whether templates are
being exported/replicated/received with a touch of "tshark -d udp.port==<NFv9/
IPFIX port>,cflow -R cflow.template_id". 

e) In the case of inconsistent output - inconsistent defined as replaying the
same set of data, output produced by the daemon differs - of nfacctd/sfacctd:
1) check the basics: whether another nfacctd/sfacctd is listening on the very
same port; this is legit behaviour due to behaviour of SO_REUSEPORT, in brief:
share load among multiple sockets listening on the same port, and SO_REUSEADDR,
in brief: don't wait for a closing socket to be closed in order to bind a new
one to the same port, options used on the listening socket; 2) check all tips
about buffering provided slightly later in this document.

f) Replay packets can be needed, for example, to troubleshoot the behaviour
of one of the pmacct daemons. A capture in libpcap format, suitable for
replay, can be produced with tcpdump, ie. for NetFlow/IPFIX/sFlow via the
"tcpdump -i <interface> -n -s 0 -w <output file> port <sfacctd/nfacctd
listening port>" command-line. The output file can be replayed by using the
pcap_savefile (-I) and, optionally, the pcap_savefile_wait (-W) directives,
ie.: "nfacctd -I <pcap savefile> <.. >". For more advanced use-cases, ie.
loop indefinitely through the pcap file and run it with a speed multiplicator
in order to stress test the daemon, the tcpreplay tool can be used for the
purpose. In this case, before replaying NetFlow/IPFIX/sFlow, L2/L3 of
captured packets must be adjusted to reflect the lab environment; this can
be done with the tcprewrite tool of the tcpreplay package, ie.: "tcprewrite
--enet-smac=<src MAC address> --enet-dmac= <dst MAC address> -S <src IP
address rewrite> -D <dst IP address rewrite> --fixcsum --infile= <input
file, ie. output from tcpdump> --outfile=<output file>". Then the output
file from tcprewrite can be supplied to tcpreplay for the actual replay to
the pmacct daemon, ie.: "tcpreplay -x <speed multiplicator> -i <output
interface> <input file>". 

g) Buffering is often an element to tune. While buffering internal to pmacct, 
configured with plugin_buffer_size and plugin_pipe_size, returns warning
messages in case of data loss and brings solid queueing alterantives like
ZeroMQ (plugin_pipe_zmq), buffering between pmacct and the kernel, configured
with nfacctd_pipe_size and its equivalents, is more tricky and issues with it
can only be inferred by symptoms like sequence number checks failing (and
only for protocols like NetFlow v9/IPFIX supporting this feature). Two
commands useful to check this kind of buffering on Linux systems are:
1) "cat /proc/net/udp" or "cat /proc/net/udp6" ensuring that "drops" value
is not increasing and 2) "netstat -s" ensuring, under the section UDP, that
errors are not increasing (since this command returns system-wide counters,
the counter-check would be: stop the pmacct daemon running and, granted the
counter was increasing, verify it does not increase anymore). As suggested
in CONFIG-KEYS description for the nfacctd_pipe_size configuration directive,
any lift in the buffering must be also supported by the kernel, adjusting
/proc/sys/net/core/rmem_max.

h) packet classification using the nDPI library is among the new features of
pmacct 1.7. As with any major and complex feature, it is expected that not
everything may work great and smooth at the first round of implementation.
In this section you will find a few tips on how to help providing meaningful
report of issues you may be experiencing in this area. 1) Please follow
guidelines in the section "Quickstart guide to packet classification" of this
document; 2) avoid generic reporting a-la "it doesn't work" or "there is too
much unknown traffic" or "i know protocol X is in my traffic mix but it's not
being classified properly"; 3) it is OK to contact the author directly given
sensitiveness of data may be involved; 4) it is OK to compare classification
results achieved with a 3rd party tool also using nDPI for classification; in
case of different results, show the actual results when reporting the issue
and please elaborate as much as possible how the comparison was done (ie.
say how it is being ensured that the two data- sets are the same or as much
as possible similar); 5) remember that the most effective way troubleshoot
any issue related to packet classification is by the author being able to
reproduce the issue or for him to verify first hand the problem: whenever
possible please share a traffic capture in pcap format or grant remote-access
to your testbed; 6) excluded from these guidelines are problems related to
nDPI but unrelated to classification, ie. memory leaks, performance issues,
crashes, etc. for which you can follow the other guide lines in this
"Miscellaneous notes and troubleshooting tips" section.
