SUPPORTED CONFIGURATION KEYS
Both configuration directives and commandline switches are listed below. 
A configuration consists of key/value pairs, separated by the ':' char.
Starting a line with the '!' symbol, makes the whole line to be ignored
by the interpreter, making it a comment. Please also refer to QUICKSTART 
document and the 'examples/' sub-tree for some examples.

Directives are sometimes grouped, like sql_table and print_output_file:
this is to stress if multiple plugins are running as part of the same
daemon instance, such directives must be casted to the plugin they refer
to - in order to prevent undesired inheritance effects. In other words,
grouped directives share the same field in the configuration structure.


LEGEND of flags:

GLOBAL		Can't be configured on individual plugins
NO_GLOBAL	Can't be configured globally
NO_PMACCTD	Does not apply to 'pmacctd'
NO_UACCTD	Does not apply to 'uacctd' 
NO_NFACCTD	Does not apply to 'nfacctd'
NO_SFACCTD	Does not apply to 'sfacctd' 
ONLY_PMACCTD	Applies only to pmacctd
ONLY_UACCTD	Applies only to uacctd
ONLY_NFACCTD	Applies only to nfacctd
ONLY_SFACCTD	Applies only to sfacctd
MAP		Indicates the input file is a map


LIST OF DIRECTIVES:

KEY: 		debug (-d)
VALUES:		[ true | false ]
DESC:		Enables debug (default: false).

KEY:            debug_internal_msg
VALUES:         [ true | false ]
DESC:           Extra flag to enable debug of internal messaging between Core process
		and plugins. It has to be enabled on top of 'debug' (default: false).

KEY:		daemonize (-D) [GLOBAL]
VALUES:		[ true | false ]
DESC:		Daemonizes the process (default: false).

KEY:		aggregate (-c)
VALUES:		[ src_mac, dst_mac, vlan, cos, etype, src_host, dst_host, src_net, dst_net,
		 src_mask, dst_mask, src_as, dst_as, src_port, dst_port, tos, proto, none,
		 sum_mac, sum_host, sum_net, sum_as, sum_port, flows, tag, tag2, label,
		 class, tcpflags, in_iface, out_iface, std_comm, ext_comm, as_path,
		 peer_src_ip, peer_dst_ip, peer_src_as, peer_dst_as, local_pref, med,
		 src_std_comm, src_ext_comm, src_as_path, src_local_pref, src_med, mpls_vpn_rd,
		 mpls_label_top, mpls_label_bottom, mpls_stack_depth, sampling_rate,
		 src_host_country, dst_host_country, pkt_len_distrib, nat_event,
		 post_nat_src_host, post_nat_dst_host, post_nat_src_port, post_nat_dst_port,
		 fw_event, timestamp_start, timestamp_end, timestamp_arrival ]
FOREWORDS:	Individual IP packets are uniquely identified by their header field values (a
		rather large set of primitives!). Same applies to uni-directional IP flows, as
		they have at least enough information to discriminate where packets are coming
		from and going to. Aggregates are instead used for the sole purpose of IP
		accounting and hence can be identified by an arbitrary set of primitives.
		The process to create an aggregate starting from IP packets or flows is: (a)
		select only the primitives of interest (generic aggregation), (b) optionally
		cast certain primitive values into broader logical entities, ie. IP addresses
		into network prefixes or Autonomous System Numbers (spatial aggregation) and
		(c) sum aggregate bytes/flows/packets counters when a new tributary IP packet
		or flow is captured (temporal aggregation).
DESC:		Aggregate captured traffic data by selecting the specified set of primitives.
		sum_<primitive> are compound primitives which sum ingress/egress traffic in a
		single aggregate; current limit of sum primitives: each sum primitive is mutual
		exclusive with any other, sum and non-sum, primitive. The 'none' primitive
		allows to make an unique aggregate which  accounts for the grand total of
		traffic flowing through a specific interface. 'tag', 'tag2' and 'label' enable
		generation of tags when tagging engines (pre_tag_map, post_tag) are in use.
		'class' enables L7 traffic classes when Packet/Flow Classification engine
		(classifiers) is in use.
NOTES:		* Some primitives (ie. tag2, timestamp_start, timestamp_end) are not part of
		  any default SQL table schema shipped. Always check out documentation related
		  to the RDBMS in use (ie. 'sql/README.mysql') which will point you to extra
		  primitive-related documentation, if required.
		* List of the aggregation primitives available to each specific pmacct daemon
		  is available via -a command-line option, ie. "pmacctd -a". 
		* sampling_rate: if counters renormalization (ie. sfacctd_renormalize) is
		  enabled this field will report a value of one (1); otherwise it will report
		  the rate that is passed by the protocol or sampling_map. A value of zero (0)
		  means 'unknown' and hence no rate is applied to original counter values.
		* src_std_comm, src_ext_comm, src_as_path are based on reverse BGP lookups;
		  peer_src_as, src_local_pref and src_med are by default based on reverse BGP
		  lookups but can be alternatively based on other methods, for example maps
		  (ie. bgp_peer_src_as_type). Internet traffic is by nature asymmetric hence
		  reverse BGP lookups must be used with caution (ie. against own prefixes).
		* Communities (ie. std_comm, ext_comm) and AS-PATHs (ie. as_path) are fixed
		  size (96 and 128 chars respectively at time of writing). Directives like
		  bgp_stdcomm_pattern and bgp_aspath_radius are aimed to keep length of these
		  strings under control but sometimes this is not enough. While the longer
		  term approach will be to define these primitives as varchar, the short-term
		  approach is to re-define default size, ie. MAX_BGP_STD_COMMS MAX_BGP_ASPATH
		  in network.h, to the desired size (blowing extra memory). This will require
		  recompiling the binary.
		* timestamp_start, timestamp_end and timestamp_arrival should not be mixed
		  with pmacct support for historical accounting, ie. breakdown of traffic in
		  time-bins via the sql_history feature; these primitives have the effect of
		  letting pmacct act as a logger up to the msec level (if reported by the
		  capturing method). timestamp_start records NetFlow/IPFIX flow start time or
		  observation; timestamp_end records NetFlow/IPFIX flow end time; finally,
		  timestamp_arrival records libpcap packet timestamp and sFlow/NetFlow/IPFIX
		  packet arrival time at the collector.
DEFAULT:	src_host

KEY:		aggregate_primitives [GLOBAL, MAP]
DESC:		Expects full pathname to a file containing custom-defined primitives. Once
		defined in this file, primitives can be used in 'aggregate' statements. The
		feature is currently available only in nfacctd, for NetFlow v9/IPFIX, pmacctd
		and uacctd. Examples are available in 'examples/primitives.lst.example'. 
DEFAULT:	none

KEY:		aggregate_filter [NO_GLOBAL]
DESC:		Per-plugin filtering applied against the original packet or flow. Aggregation
		is performed slightly afterwards, upon successful match of this filter.
		By binding a filter, in tcpdump syntax, to an active plugin, this directive
		allows to select which data has to be delivered to the plugin and aggregated
		as specified by the plugin 'aggregate' directive. See the following example:

		...
		aggregate[inbound]: dst_host
		aggregate[outbound]: src_host
		aggregate_filter[inbound]: dst net 192.168.0.0/16
		aggregate_filter[outbound]: src net 192.168.0.0/16
		plugins: memory[inbound], memory[outbound]
		...

		This directive can be used in conjunction with 'pre_tag_filter' (which, in
		turn, allows to filter tags). You will also need to force fragmentation handling
		in the specific case in which a) none of the 'aggregate' directives is including
		L4 primitives (ie. src_port, dst_port) but b) an 'aggregate_filter' runs a filter
		which requires dealing with L4 primitives. For further information, refer to the
		'pmacctd_force_frag_handling' directive.
DEFAULT:	none

KEY:		pcap_filter [GLOBAL, PMACCTD_ONLY]
DESC:		This filter is global and applied to all incoming packets. It's passed to libpcap
		and expects libpcap/tcpdump filter syntax. Being global it doesn't offer a great
		flexibility but it's the fastest way to drop unwanted traffic. It applies only to
		pmacctd.
DEFAULT:	none

KEY:		snaplen (-L) [GLOBAL, PMACCTD_ONLY]
DESC:		Specifies the maximum number of bytes to capture for each packet. This directive has
		key importance when enabling both classification and connection tracking engines. In
		fact, some protocols (mostly text-based eg.: RTSP, SIP, etc.) benefit of extra bytes
		because they give more chances to successfully track data streams spawned by control 
		channel. But it must be also noted that capturing larger packet portion require more 
		resources. The right value need to be traded-off. In case classification is enabled, 
		values under 200 bytes are often meaningless. 500-750 bytes are enough even for text
		based protocols. Default snaplen values are ok if classification is disabled.
		For uacctd daemon, this option doesn't apply to packet snapshot length but rather to
		the Netlink socket read buffer size. This should be reasonably large - at least 4KB,
		which is the default value. For large uacctd_nl_size values snaplen could be further
		increased.
DEFAULT:	68 bytes; 128 bytes if compiled with --enable-ipv6

KEY:		plugins (-P)
VALUES:		[ memory | print | mysql | pgsql | sqlite3 | mongodb | nfprobe | sfprobe | tee ]
DESC:		Plugins to be enabled. SQL plugins are available only if configured and compiled.
		'memory' enables the use of a memory table as backend; then, a client tool, 'pmacct',
		can fetch its content; mysql, pgsql and sqlite3 enable the use of respectively MySQL,
		PostgreSQL and SQLite 3.x (or BerkeleyDB 5.x with the SQLite API compiled-in) tables
		to store data. 'mongodb' enables use of the noSQL document-oriented database MongoDB
		(requires installation of MongoDB API C driver which is shipped separatedly from the
		main package). 'print' prints aggregates to flat-files or stdout in CSV or formatted.
		'nfprobe' acts as a NetFlow/IPFIX agent and exports collected data via NetFlow v1/v5/
		v9 and IPFIX datagrams to a remote collector. 'sfprobe' acts as a sFlow agent and
		exports collected data via sFlow v5 datagrams to a remote collector. Both 'nfprobe'
		and 'sfprobe' apply only to 'pmacctd' and 'uacctd' daemons. 'tee' acts as a replicator
		for NetFlow/IPFIX/ sFlow data (also transparent); it applies to 'nfacctd' and 'sfacctd'
		daemons only. Plugins can be either anonymous or named; configuration directives can
		be either global or bound to a specific named plugin. An anonymous plugin is declared
		as 'plugins: mysql' whereas a named plugin is declared as 'plugins: mysql[name]'.
		Then, directives can be bound to such named plugin as: 'directive[name]: value'.
DEFAULT:	memory

KEY:		[ nfacctd_pipe_size | sfacctd_pipe_size | pmacctd_pipe_size | tee_pipe_size ]
DESC:		Defines the size of the kernel socket to read (ie. daemons) and write (ie. tee plugin)
		traffic data. The socket is highlighted below with "XXXX": 

                                         XXXX 
                [network] ----> [kernel] ----> [core process] ----> [plugin] ----> [backend]
					       [__________pmacct___________]

		On Linux systems, if this configuration directive is not specified default socket size
		awarded is defined in /proc/sys/net/core/[rw]mem_default ; the maximum configurable
		socket size is defined in /proc/sys/net/core/[rw]mem_max instead. Still on Linux, the
		"drops" field of /proc/net/udp can be checked to ensure its value  is not increasing.
DEFAULT:	Operating System default 

KEY:            [ bgp_daemon_pipe_size | bmp_daemon_pipe_size ] [GLOBAL]
DESC:           Defines the size of the kernel socket used for BGP and BMP messaging. The socket is
		highlighted below with "XXXX":

                                         XXXX
                [network] ----> [kernel] ----> [core process] ----> [plugin] ----> [backend]
                                               [__________pmacct___________]

		On Linux systems, if this configuration directive is not specified default socket size
		awarded is defined in /proc/sys/net/core/rmem_default ; the maximum configurable socket
		size (which can be changed via sysctl) is defined in /proc/sys/net/core/rmem_max
		instead.
DEFAULT:	Operating System default

KEY:		plugin_pipe_size
DESC:		Core Process and each of the plugin instances are run into different processes. To
		exchange data, they set up a circular queue (home-grown implementation, referred to
		as 'pipe') and highlighted below with "XXXX":

							      XXXX
		[network] ----> [kernel] ----> [core process] ----> [plugin] ----> [backend]
					       [__________pmacct___________]

		This directive sets the total size, in bytes, of such queue. Its default size is set
		to 4MB. Whenever facing heavy traffic loads, this size can be adjusted to hold more
		data. In the following example, the queue between the Core process and the plugin
		'test' is set to 10MB:

		...
		plugins: memory[test]
		plugin_pipe_size[test]: 10240000 
		...

		When enabling debug, log messages about obtained and target pipe sizes are printed.
		If obtained is less than target, it could mean the maximum socket size granted by
		the Operating System has to be increased. On Linux systems default socket size awarded
		is defined in /proc/sys/net/core/[rw]mem_default ; the maximum configurable socket
		size (which can be changed via sysctl) is defined in /proc/sys/net/core/[rw]mem_max
		instead.

		In case of data loss messages containing the "We are missing data" string will be
		logged - indicating the plugin affected and current settings.
DEFAULT:	4MB

KEY:		plugin_pipe_amqp
VALUES:         [ true | false ]
DESC:		By defining this directive to 'true', a RabbitMQ broker is used for queueing and
		data exchange between the Core Process and the plugins. This is in alternative to
		the home-grown circular queue implementation (see plugin_pipe_size description).
		This directive, along with all other plugin_pipe_amqp_* directives, can be set
		globally or apply on a per plugin basis (ie. it is a valid scenario, if multiple
		plugins are instantiated, that some make use of home-grown queueing, while others
		use RabbitMQ based queueing). For a quick comparison: while relying on a RabbitMQ
		broker for queueing introduces an external dependency (rabbitmq-c library, RabbitMQ
		server, etc.), it reduces the amount of setting needed by the home-grown circular
		queue implementation. See QUICKSTART for some examples.
DEFAULT:	false

KEY:            plugin_pipe_kafka
VALUES:         [ true | false ]
DESC:           By defining this directive to 'true', a Kafka broker is used for queueing and data
		exchange between the Core Process and the plugins. This is in alternative to the
		home-grown circular queue implementation (see plugin_pipe_size description). This
		directive, along with all other plugin_pipe_kafka_* directives, can be set globally
		or apply on a per plugin basis (ie. it is a valid scenario, if multiple plugins are
		instantiated, that some make use of home-grown queueing, while others use Kafka
		based queueing). For a quick comparison: using a Kafka broker gives the same
		benefits as using a RabbitMQ broker (read plugin_pipe_amqp); plus, Kafka scales
		more than RabbitMQ. See QUICKSTART for some examples.
NOTES:		librdkafka does not currently expose the file descriptor(s) used internally so to
		allow an external poll() or select() against it/them. This is being worked on as
		part of librdkafka issue #429: https://github.com/edenhill/librdkafka/issues/429 .
		As a result of that, the plugin_pipe_kafka feature is limited to 'print' plugin as
		a proof of concept.
DEFAULT:        false

KEY:		plugin_buffer_size 
DESC:		By defining the transfer buffer size, in bytes, this directive enables buffering of
		data transfers between core process and active plugins. Once a buffer is filled, it
		is delivered to the plugin. Setting a larger value may improve throughput (ie. amount
		of CPU cycles required to transfer data); setting a smaller value may improve latency,
		especially in scenarios with little data influx. It is disabled by default. If used
		with the home-grown circular queue implemetation, the value has to be minor/equal to
		the size defined by 'plugin_pipe_size' and keeping a ratio of 1:1000 among the two is
		considered good practice; the circular queue of plugin_pipe_size size is partitioned
		in chunks of plugin_buffer_size; if used with the RabbitMQ broker based queueing (ie.
		'plugin_pipe_amqp: true') this directive sets the frame_max allowed by the underlying
		RabbitMQ session. 
DEFAULT:	Set to the size of the smallest element to buffer 

KEY:            plugin_pipe_backlog
VALUES:         [0 <= value < 100]
DESC:           Expects the value to be a percentage. It creates a backlog of buffers on the pipe
		before actually releasing them to the plugin. The strategy helps optimizing inter
		process communications where plugins are quicker handling data than the Core process.
		By default backlog is disabled; as with buffering in general, this feature should be
		enabled with caution in lab and low-traffic environments.
DEFAULT:	0

KEY:		plugin_pipe_check_core_pid
VALUES:		[ true | false ]
DESC:		When enabled (default), validates the sender of data at the plugin side. The check
		consists in verifying that the sender PID matches the PID of the plugin parent
		process. This is useful when plugin_pipe_amqp or plugin_pipe_kafka are enabled and
		hence a broker sits between the daemon Core Process and the Plugins. The feature is
		not inteded to be a security one; instead its objective is to limit impact of such
		things like mis-configurations, daemons started twice with the same configuration,
		etc. 
DEFAULT:	true

KEY:		files_umask 
DESC:		Defines the mask for newly created files (log, pid, etc.) and their related directory
		structure. A mask less than "002" is not accepted due to security reasons.
DEFAULT:	077

KEY:            files_uid
DESC:           Defines the system user id (UID) for files opened for writing (log, pid, etc.); this
		is indeed possible only when running the daemon as super-user; by default this is left
		untouched. This is also applied to any intermediary directory structure which might be
		created. 
DEFAULT:	Operating System default (current user UID)

KEY:            files_gid
DESC:           Defines the system group id (GID) for files opened for writing (log, pid, etc.); this
		is indeed possible only when running the daemon as super-user; by default this is left
		untouched. This is also applied to any intermediary directory structure which might be
		created. 
DEFAULT:	Operating System default (current user GID)

KEY:		interface (-i) [GLOBAL, PMACCTD_ONLY]
DESC:		Interface on which 'pmacctd' listens. If such directive isn't supplied, a libpcap
		function is used to select a valid device. [ns]facctd can catch similar behaviour by
		employing the [ns]facctd_ip directives; also, note that this directive is mutually
		exclusive with 'pcap_savefile' (-I). 
DEFAULT:	Interface is selected by by the Operating System

KEY:		pcap_savefile (-I) [GLOBAL, PMACCTD_ONLY]
DESC:		File in libpcap savefile format from which read data (this is in alternative to binding
		to an intervace). The file has to be correctly finalized in order to be read. As soon
		as 'pmacctd' is finished with the file, it exits (unless the 'savefile_wait' option is
		in place). The directive doesn't apply to [ns]facctd; to replay original NetFlow/sFlow
		streams, a tool like TCPreplay can be used instead. The directive is mutually exclusive
		with 'interface' (-i). 
DEFAULT:	none

KEY:		interface_wait (-w) [GLOBAL, PMACCTD_ONLY]
VALUES:		[ true | false ]
DESC:		If set to true, this option causes 'pmacctd' to wait for the listening device to become
		available; it will try to open successfully the device each few seconds. Whenever set to
		false, 'pmacctd' will exit as soon as any error (related to the listening interface) is
		detected.
DEFAULT:	false

KEY:            savefile_wait (-W) [GLOBAL, PMACCTD_ONLY]
VALUES:         [ true | false ]
DESC:           If set to true, this option will cause 'pmacctd' to wait indefinitely for a signal (ie.
		CTRL-C when not daemonized or 'killall -9 pmacctd' if it is) after being finished with
		the supplied libpcap savefile (pcap_savefile). It's particularly useful when inserting
		fixed amounts of data into memory tables by keeping the daemon alive.
DEFAULT:        false

KEY:		promisc (-N) [GLOBAL, PMACCTD_ONLY]
VALUES:		[ true | false ]
DESC:		If set to true, puts the listening interface in promiscuous mode. It's mostly useful when
		running 'pmacctd' in a box which is not a router, for example, when listening for traffic
		on a mirroring port.
DEFAULT:        true

KEY:		imt_path (-p)
DESC:		Specifies the full pathname where the memory plugin has to listen for client queries.
		When multiple memory plugins are active, each one has to use its own file to communicate
		with the client tool. Note that placing these files into a carefully protected directory
		(rather than /tmp) is the proper way to control who can access the memory backend.
DEFAULT:	/tmp/collect.pipe

KEY:		imt_buckets (-b)
DESC:		Defines the number of buckets of the memory table which is organized as a chained hash
		table. A prime number is highly recommended. Read INTERNALS 'Memory table plugin' chapter
		for further details. 
DEFAULT:	32771

KEY:		imt_mem_pools_number (-m)
DESC:		Defines the number of memory pools the memory table is able to allocate; the size of each
		pool is defined by the 'imt_mem_pools_size' directive. Here, a value of 0 instructs the
		memory plugin to allocate new memory chunks as they are needed, potentially allowing the
		memory structure to grow undefinitely. A value > 0 instructs the plugin to not try to 
		allocate more than the specified number of memory pools, thus placing an upper boundary
		to the table size.
DEFAULT:	16

KEY:		imt_mem_pools_size (-s)
DESC:		Defines the size of each memory pool. For further details read INTERNALS 'Memory table
		plugin'. The number of memory pools is defined by the 'imt_mem_pools_number' directive.
DEFAULT:	8192

KEY:		syslog (-S)
VALUES:		[ auth | mail | daemon | kern | user | local[0-7] ]
DESC:		Enables syslog logging, using the specified facility.
DEFAULT:	none (console logging)

KEY:		logfile 
DESC:           Enables logging to a file (bypassing syslog); expected value is a pathname
DEFAULT:	none (console logging)

KEY:		[ amqp_host | plugin_pipe_amqp_host ]
DESC:           Defines the AMQP/RabbitMQ broker IP. amqp_* directives refer to the broker used by an
		AMQP plugin to purge data out; plugin_pipe_amqp_* directives refer to the broker used
		by the core process to send data to plugins. 
DEFAULT:        localhost

KEY:		[ bgp_daemon_msglog_amqp_host | bgp_table_dump_amqp_host | bmp_dump_amqp_host |
		  bmp_daemon_msglog_amqp_host ] [GLOBAL]
DESC:		See amqp_host. bgp_daemon_msglog_amqp_* directives refer to the broker used by the BGP
		thread to stream data out; bgp_table_dump_amqp_* directives refer to the broker used
		by the BGP thread to dump data out at regular time intervals; bmp_daemon_msglog_amqp_*
		directives refer to the broker used by the BMP thread to stream data out; bmp_dump_amqp_*
		directives refer to the broker used by the BMP thread to dump data out at regular time
		intervals.
DEFAULT:	See amqp_host	

KEY:            [ amqp_vhost | plugin_pipe_amqp_vhost ]
DESC:           Defines the AMQP/RabbitMQ server virtual host; see also amqp_host.
DEFAULT:        "/"

KEY:		[ bgp_daemon_msglog_amqp_vhost | bgp_table_dump_amqp_vhost | bmp_dump_amqp_vhost |
		  bmp_daemon_msglog_amqp_vhost ] [GLOBAL]
DESC:           See amqp_vhost; see also bgp_daemon_msglog_amqp_host.
DEFAULT:	See amqp_vhost 

KEY:		[ amqp_user | plugin_pipe_amqp_user ]
DESC:           Defines the username to use when connecting to the AMQP/RabbitMQ server; see also
		amqp_host.
DEFAULT:        guest

KEY:		[ bgp_daemon_msglog_amqp_user | bgp_table_dump_amqp_user | bmp_dump_amqp_user |
		  bmp_daemon_msglog_amqp_user ] [GLOBAL]
DESC:		See amqp_user; see also bgp_daemon_msglog_amqp_host.
DEFAULT:	See amqp_user

KEY:		[ amqp_passwd | plugin_pipe_amqp_passwd ]
DESC:           Defines the password to use when connecting to the server; see also amqp_host.
DEFAULT:        guest

KEY:		[ bgp_daemon_msglog_amqp_passwd | bgp_table_dump_amqp_passwd |
		  bmp_dump_amqp_passwd | bmp_daemon_msglog_amqp_passwd ] [GLOBAL]
DESC:		See amqp_passwd; see also bgp_daemon_msglog_amqp_host.
DEFAULT: 	See amqp_passwd

KEY:		amqp_routing_key
DESC:           Name of the AMQP routing key to attach to published data. Dynamic names are supported
		through the use of variables, which are computed at the moment when data is purged to
		the backend. The list of variables supported is:

                $peer_src_ip    Value of the peer_src_ip primitive of the record being processed.

                $pre_tag        Value of the tag primitive of the record being processed.

                $post_tag       Configured value of post_tag.

                $post_tag2      Configured value of post_tag2.

		See also amqp_host.

DEFAULT:	'acct'

KEY:		[ bgp_daemon_msglog_amqp_routing_key | bgp_table_dump_amqp_routing_key |
		  bmp_daemon_msglog_amqp_routing_key | bmp_dump_amqp_routing_key ] [GLOBAL]
DESC:		See amqp_routing_key; see also bgp_daemon_msglog_amqp_host. Variables supported by
		bgp_daemon_msglog_amqp_routing_key, bgp_table_dump_amqp_routing_key,
		bmp_daemon_msglog_amqp_routing_key, bmp_dump_amqp_routing_key:

		$peer_src_ip    Value of the peer_src_ip primitive of the record being processed.

DEFAULT:	none

KEY:            [ amqp_routing_key_rr | kafka_topic_rr ]
DESC:           Performs round-robin load-balancing over a set of AMQP routing keys or Kafka topics.
		The base name for the string is defined by amqp_routing_key or kafka_topic. This key
		accepts a positive int value. If, for example, amqp_routing_key is set to 'blabla'
		and amqp_routing_key_rr to 3 then the AMQP plugin will round robin as follows:
		message #1 -> blabla_0, message #2 -> blabla_1, message #3 -> blabla_2, message #4
		-> blabla_0 and so forth. This works in the same fashion for kafka_topic. By default
		the feature is disabled, meaning all messages are sent to the base AMQP routing key
		or Kafka topic (or the default one, if no amqp_routing_key or kafka_topic is being
		specified).
DEFAULT:        0

KEY:		[ bgp_daemon_msglog_amqp_routing_key_rr | bgp_table_dump_amqp_routing_key_rr |
		  bmp_daemon_msglog_amqp_routing_key_rr | bmp_dump_amqp_routing_key_rr ] [GLOBAL]
DESC:		See amqp_routing_key_rr; see also bgp_daemon_msglog_amqp_host.
DEFAULT:	See amqp_routing_key_rr

KEY:            [ amqp_exchange | plugin_pipe_amqp_exchange ]
DESC:           Name of the AMQP exchange to publish data; see also amqp_host.
DEFAULT:	pmacct

KEY:		[ bgp_daemon_msglog_amqp_exchange | bgp_table_dump_amqp_exchange |
		  bmp_daemon_msglog_amqp_exchange | bmp_dump_amqp_exchange ] [GLOBAL]
DESC:           See amqp_exchange
DEFAULT:	See amqp_exchange; see also bgp_daemon_msglog_amqp_host.

KEY:            amqp_exchange_type
DESC:           Type of the AMQP exchange to publish data. Currently only 'direct' and 'fanout' types are
                supported; see also amqp_host.
DEFAULT:	direct

KEY:		[ bgp_daemon_msglog_amqp_exchange_type | bgp_table_dump_amqp_exchange_type |
		  bmp_daemon_msglog_amqp_exchange_type | bmp_dump_amqp_exchange_type ] [GLOBAL]
DESC:           See amqp_exchange_type; see also bgp_daemon_msglog_amqp_host.
DEFAULT:	See amqp_exchange_type

KEY:            amqp_persistent_msg
VALUES:         [ true | false ]
DESC:           Marks messages as persistent so that a queue content does not get lost if RabbitMQ restarts.
                Note from RabbitMQ docs: "Marking messages as persistent doesn't fully guarantee that a
                message won't be lost. Although it tells RabbitMQ to save message to the disk, there is
                still a short time window when RabbitMQ has accepted a message and hasn't saved it yet.
                Also, RabbitMQ doesn't do fsync(2) for every message -- it may be just saved to cache and
                not really written to the disk. The persistence guarantees aren't strong, but it is more
                than enough for our simple task queue."; see also amqp_host.
DEFAULT:        false

KEY:		[ bgp_daemon_msglog_amqp_persistent_msg  | bgp_table_dump_amqp_persistent_msg |
		  bmp_daemon_msglog_amqp_persistent_msg | bmp_dump_amqp_persistent_msg ] [GLOBAL]
VALUES:         See amqp_persistent_msg; see also bgp_daemon_msglog_amqp_host.
DESC:		See amqp_persistent_msg
DEFAULT:	See amqp_persistent_msg

KEY:		amqp_frame_max
DESC:		Defines the maximum size, in bytes, of an AMQP frame on the wire to request of the broker
		for the connection. 4096 is the minimum size, 2^31-1 is the maximum; see also amqp_host.
DEFAULT:	131072

KEY:		[ bgp_daemon_msglog_amqp_frame_max | bgp_table_dump_frame_max |
		  bmp_daemon_msglog_amqp_frame_max | bmp_dump_frame_max ] [GLOBAL]
DESC:		See amqp_frame_max; see also bgp_daemon_msglog_amqp_host.
DEFAULT:	See amqp_frame_max

KEY:            amqp_heartbeat_interval
DESC:           Defines the heartbeat interval in order to detect general failures of the RabbitMQ server.
                The value is expected in seconds. By default the heartbeat mechanism is disabled with a
		value of zero. According to RabbitMQ C API, detection takes place only upon publishing a
		JSON message, ie. not at login or if idle. The maximum value supported is INT_MAX (or
		2147483647); see also amqp_host.
DEFAULT:	0

KEY:		[ bgp_daemon_msglog_amqp_heartbeat_interval | bgp_table_dump_heartbeat_interval |
		  bmp_daemon_msglog_amqp_heartbeat_interval | bmp_dump_heartbeat_interval ] [GLOBAL]
DESC:           See amqp_heartbeat_interval; see also bgp_daemon_msglog_amqp_host.
DEFAULT:	See amqp_heartbeat_interval

KEY:            plugin_pipe_amqp_routing_key 
DESC:           Name of the AMQP routing key to use to send data to a plugin. Currently each plugin
		must bind to a different routing key in order to avoid duplications. Dynamic names
		are supported through the use of variables, which are computed at startup. The list
		of variables supported is:

                $core_proc_name	Configured core_proc_name.

                $plugin_name	Configured plugin name (ie. 'foo' if 'plugins: print[foo]') 

                $plugin_type	Plugin type (ie. memory, print, amqp, etc.)

DEFAULT:        '$core_proc_name-$plugin_name-$plugin_type'

KEY:		plugin_pipe_amqp_retry
DESC:           Defines the interval of time, in seconds, after which a connection to the RabbitMQ server
                should be retried after a failure is detected; see also amqp_host.
DEFAULT:	60

KEY:		[ bgp_daemon_msglog_amqp_retry | bmp_daemon_msglog_amqp_retry ] [GLOBAL]
DESC:		See plugin_pipe_amqp_retry; see also bgp_daemon_msglog_amqp_host.
DEFAULT: 	See plugin_pipe_amqp_retry	

KEY:		kafka_topic
DESC:           Name of the Kafka topic to attach to published data. Dynamic names are supported by
                kafka_topic through the use of variables, which are computed at the moment when data
                is purged to the backend. The list of variables supported by amqp_routing_key:

                $peer_src_ip    Value of the peer_src_ip primitive of the record being processed.

                $pre_tag        Value of the tag primitive of the record being processed.

                $post_tag       Configured value of post_tag.

                $post_tag2      Configured value of post_tag2.

DEFAULT:        kafka_topic: 'pmacct.acct'

KEY:            plugin_pipe_kafka_topic
DESC:           Name of the Kafka topic to use to send data to a plugin. Currently each plugin must
		bind to a different routing key in order to avoid duplications. Dynamic names are
		supported through the use of variables, which are computed at startup. The list of
		variables supported is:

                $core_proc_name Configured core_proc_name.

                $plugin_name    Configured plugin name (ie. 'foo' if 'plugins: print[foo]')

                $plugin_type    Plugin type (ie. memory, print, amqp, etc.)

DEFAULT:        '$core_proc_name-$plugin_name-$plugin_type'

KEY:            plugin_pipe_kafka_retry
DESC:           Defines the interval of time, in seconds, after which a connection to the Kafka
		broker should be retried after a failure is detected.
DEFAULT:        60

KEY:            [ kafka_broker_host | plugin_pipe_broker_host ]
DESC:           Defines the Kafka broker IP address. kafka_* directives refer to the broker used by
		a kafka plugin to purge data out; plugin_pipe_kafka_* directives refer to the broker
		used by the core process to send data to plugins.
DEFAULT:        127.0.0.1

KEY:            [ kafka_broker_port | plugin_pipe_broker_port ]
DESC:           Defines the Kafka broker port. See also kafka_broker_host.
DEFAULT:        9092

KEY:		[ kafka_partition | plugin_pipe_kafka_partition ]
DESC:		Defines the Kafka broker topic partition ID. RD_KAFKA_PARTITION_UA or ((int32_t)-1)
		is to define the configured or default partitioner (slower than sending to a fixed
		partition). See also kafka_broker_host. 
DEFAULT:	0

KEY:            [ bgp_daemon_msglog_kafka_broker_host | bgp_table_dump_kafka_broker_host |
                  bmp_daemon_msglog_kafka_broker_host | bmp_dump_kafka_broker_host ] [GLOBAL]
DESC:           See kafka_broker_host
DEFAULT:        See kafka_broker_host

KEY:            [ bgp_daemon_msglog_kafka_broker_port | bgp_table_dump_kafka_broker_port |
                  bmp_daemon_msglog_kafka_broker_port | bmp_dump_kafka_broker_port ] [GLOBAL]
DESC:           See kafka_broker_port
DEFAULT:        See kafka_broker_port

KEY:            [ bgp_daemon_msglog_kafka_topic | bgp_table_dump_kafka_topic |
                  bmp_daemon_msglog_kafka_topic | bmp_dump_kafka_topic ] [GLOBAL]
DESC:           See kafka_topic
DEFAULT:        none

KEY:            [ bgp_daemon_msglog_kafka_topic_rr | bgp_table_dump_kafka_topic_rr |
                  bmp_daemon_msglog_kafka_topic_rr | bmp_dump_kafka_topic_rr ] [GLOBAL]
DESC:           See kafka_topic_rr
DEFAULT:        See kafka_topic_rr

KEY:            [ bgp_daemon_msglog_kafka_partition | bgp_table_dump_kafka_partition |
                  bmp_daemon_msglog_kafka_partition | bmp_dump_kafka_partition ] [GLOBAL]
DESC:           See kafka_partition
DEFAULT:        See kafka_partition

KEY:            [ bgp_daemon_msglog_kafka_retry | bmp_daemon_msglog_kafka_retry ] [GLOBAL]
DESC:           See plugin_pipe_kafka_retry
DEFAULT:        See plugin_pipe_kafka_retry

KEY:		pidfile (-F) [GLOBAL]
DESC:		Writes PID of Core process to the specified file. PIDs of the active plugins are written
		aswell by employing the following syntax: 'path/to/pidfile-<plugin_type>-<plugin_name>'.
		This gets particularly useful to recognize which process is which on architectures where
		pmacct does not support the setproctitle() function.
DEFAULT:	none

KEY:		networks_file (-n)
DESC:		Full pathname to a file containing a list of networks - and optionally ASN information,
		BGP next-hop (peer_dst_ip) and IP prefix labels (read more about the file syntax in
		examples/networks.lst.example). Purpose of the feature is to act as a resolver when
		network, next-hop and/or peer/origin ASN information is not available through other
		means (ie. BGP, IGP, telemetry protocol) or for the purpose of overriding such
		information with custom/self-defined one. IP prefix labels rewrite the resolved
		source and/or destination IP prefix into the supplied label; labels can be up to 15
		characters long.
DEFAULT:	none

KEY:		networks_file_filter
VALUES          [ true | false ]
DESC:           Makes networks_file work as a filter in addition to its basic resolver functionality:
		networks and hosts not belonging to defined networks are zeroed out.
DEFAULT:        false

KEY:		networks_file_no_lpm
VALUES          [ true | false ]
DESC:		Makes a matching IP prefix defined in a networks_file win always, even if it is not
		the longest. It applies when the aggregation method includes src_net and/or dst_net
		and nfacctd_net (or equivalents) and/or nfacctd_as (or equivalents) configuration
		directives are set to 'longest' (or 'fallback'). For example we receive the following
		PDU via NetFlow: 

		SrcAddr: 10.0.8.29 (10.0.8.29)
		DstAddr: 192.168.5.47 (192.168.5.47)
		[ .. ]
		SrcMask: 24 (prefix: 10.0.8.0/24)
		DstMask: 27 (prefix: 192.168.5.32/27)

		a BGP peering is available and BGP contains the following prefixes: 192.168.0.0/16 and
		10.0.0.0/8. Such a scenario is typical when more specifics are not re-distributed in
		BGP but are only available in the IGP. A networks_file contains the prefixes 10.0.8.0/24
		and 192.168.5.0/24. 10.0.8.0/24 is the same as in NetFlow; but 192.168.5.0/24 (say,
		representative of a range dedicated to a specific customer across several locations and
		hence composed of several sub-prefies) would not be the longest match and hence the
		prefix from NetFlow, 192.168.5.32/27, would be the outcome of the network aggregation
		process; setting networks_file_no_lpm to true makes 192.168.5.0/24, coming from the
		networks_file, win instead. 
DEFAULT:        false

KEY:            networks_mask
DESC:           Specifies the network mask - in bits - to apply to IP address values in L3 header. The
		mask is applied sistematically and before evaluating the 'networks_file' content (if
		any is specified).
DEFAULT:	none

KEY:		networks_cache_entries
DESC:		Networks Lookup Table (which is the memory structure where the 'networks_file' data is
		loaded) is preeceded by a Network Lookup Cache where lookup results are saved to speed
		up later searches. NLC is structured as an hash table, hence, this directive is aimed to
		set the number of buckets for the hash table. The default value should be suitable for
		most common scenarios, however when facing with large-scale network definitions, it is 
		quite adviceable to tune this parameter to improve performances. A prime number is highly
		recommended.
DEFAULT:	IPv4: 99991; IPv6: 32771	

KEY:		ports_file
DESC:		Full pathname to a file containing a list of (known/interesting/meaningful) ports (one
		for each line, read more about the file syntax into examples/ tree). The directive allows
		to rewrite as zero port numbers not matching any port defined in the list. Indeed, this
		makes sense only if aggregating on either 'src_port' or 'dst_port' primitives.
DEFAULT:	none

KEY:		sql_db
DESC:		Defines the SQL database to use. Remember that when using the SQLite3 plugin, this
		directive refers to the full path to the database file
DEFAULT:	'pmacct'; SQLite 3.x: '/tmp/pmacct.db' 

KEY:            [ sql_table | print_output_file | mongo_table ]
DESC:           In SQL and mongodb plugins this defines the table to use; in print plugin it defines the
		file to write output to. Dynamic names are supported through the use of variables, which
		are computed at the moment when data is purged to the backend. The list of supported
		variables follows: 

		%d		The day of the month as a decimal number (range 01 to 31).

		%H		The hour as a decimal number using a 24 hour clock (range 00 to 23).

		%m		The month as a decimal number (range 01 to 12).

		%M		The minute as a decimal number (range 00 to 59).

		%s      	The number of seconds since Epoch, ie., since 1970-01-01 00:00:00 UTC.

		%w		The day of the week as a decimal, range 0 to 6, Sunday being 0.

		%W		The week number of the current year as a decimal number, range
				00 to 53,  starting  with the first Monday as the first day of
				week 01.

		%Y		The year as a decimal number including the century.

		$ref		Configured refresh time value for the plugin.

		$hst		Configured sql_history value, in seconds, for the plugin.

		$peer_src_ip	Record value for peer_src_ip primitive (if primitive is not part of
				the aggregation method then this will be set to a null value).

		$tag		Record value for tag primitive ((if primitive is not part of the
				aggregation method then this will be set to a null value).

		$tag2		Record value for tag2 primitive ((if primitive is not part of the
				aggregation method then this will be set to a null value).

		SQL plugins notes:
		Time-related variables require 'sql_history' to be specified in order to work correctly
		(see 'sql_history' entry in this in this document for further information) and that the
		'sql_refresh_time' setting is aligned with the 'sql_history', ie.:

			sql_history: 5m
			sql_refresh_time: 300

		Furthermore, if the 'sql_table_schema' directive is not specified, tables are expected
		to be already in place. This is an example on how to split accounted data among multiple
		tables basing on the day of the week:

			sql_history: 1h
			sql_history_roundoff: h
			sql_table: acct_v4_%w

		The above directives will account data on a hourly basis (1h). Also the above sql_table
		definition will make: Sunday data be inserted into the 'acct_v4_0' table, Monday into
		the 'acct_v4_1' table, and so on. The switch between the tables will happen each day at
		midnight: this behaviour is ensured by the use of the 'sql_history_roundoff' directive. 

		Ideally sql_refresh_time and sql_history values should be aligned for the dynamic tables
		to work; sql_refresh_time with a value smaller than sql_history is also supported; whereas
		the feature does not support values of sql_refresh_time greater than sql_history. The
		maximum table name length is 64 characters.

		Print plugin notes:
		If a non-dynamic filename is selected, content is overwritten to the existing one in
		case print_output_file_append is set to false (default). Are supported scenarios where
		multiple level of directories need to be created in order to create the target file,
		ie. "/path/to/%Y/%Y-%m/%Y-%m-%d/blabla-%Y%m%d-%H%M.txt". Shell replacements are not
		supported though, ie. '~' symbol to denote the user home directory. print_history
		values are used for time-related variables substitution of dynamic print_output_file
		names. 

		MongoDB plugin notes:
		The table name is expected as <database>.<collection> . Default table is test.acct

		Common notes:
		The maximum number of variables it may contain is 32.
DEFAULT:	see notes

KEY:		print_output_file_append
VALUES:         [ true | false ]
DESC:		If set to true, print plugin will append to existing files instead of overwriting. If
		appending, and in case of an output format requiring a title, ie. csv, formatted, etc.,
		intuitively the title is not re-printed.
DEFAULT:	false

KEY:            print_latest_file
DESC:		Defines the full pathname to pointer(s) to latest file(s). Dynamic names are supported
		through the use of variables, which are computed at the moment when data is purged to the
		backend: refer to print_output_file for a full listing of supported variables; time-based
		variables are not allowed. Three examples follow:

		#1:
                print_output_file: /path/to/spool/foo-%Y%m%d-%H%M.txt
                print_latest_file: /path/to/spool/foo-latest

		#2:
		print_output_file: /path/to/spool/%Y/%Y-%m/%Y-%m-%d/foo-%Y%m%d-%H%M.txt
		print_latest_file: /path/to/spool/latest/foo

		#3:
		print_output_file: /path/to/$peer_src_ip/foo-%Y%m%d-%H%M.txt
		print_latest_file: /path/to//spool/latest/blabla-$peer_src_ip

NOTES:		Update of the latest pointer is done evaluating files name. For correct working of the
		feature, responsibility is put on the user. A file is reckon as latest if it is
		lexicographically greater than an existing one: this is generally fine but requires
		dates to be in %Y%m%d format rather than %d%m%Y. Also, upon restart of the daemon, if
		print_output_file is modified to a different location good practice would be to 1)
		manually delete latest pointer(s) or 2) move existing print_output_file files to the
		new targer location. Finally, if upgrading from pmacct releases before 1.5.0rc1, it is
		recommended to delete existing symlinks.
DEFAULT:	none

KEY:		sql_table_schema
DESC:		Full pathname to a file containing a SQL table schema. It allows to create the SQL table
		if it does not exist; this directive makes sense only if a dynamic 'sql_table' is in use.  
		A configuration example where this directive could be useful follows:

			sql_history: 5m
			sql_history_roundoff: h
			sql_table: acct_v4_%Y%m%d_%H%M 
			sql_table_schema: /usr/local/pmacct/acct_v4.schema

		In this configuration, the content of the file pointed by 'sql_table_schema' should be:

			CREATE TABLE acct_v4_%Y%m%d_%H%M (
				[ ... PostgreSQL/MySQL specific schema ... ]
			);

		This setup, along with this directive, are mostly useful when the dynamic tables are not
		closed in a 'ring' fashion (e.g., the days of the week) but 'open' (e.g., current date).  
DEFAULT:	none

KEY:		sql_table_version (-v)
VALUES		[ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ]
DESC:		Defines the version of the SQL table. SQL table versioning was introduced to achieve two
		goals: a) make tables work out-of-the-box for the SQL beginners, smaller installations
		and quick try-outs; and in this context b) to allow introduction of new features over
		time without breaking backward compatibility. For the SQL experts, the alternative to
		versioning is 'sql_optimize_clauses' which allows custom mix-and-match of primitives:
		in such a case you have to build yourself custom SQL schemas and indexes. Check in the
		'sql/' sub-tree the SQL table profiles which are supported by the pmacct version you are
		currently using. It is always adviced to explicitely define a sql_table_version in
		order to predict which primitive will be written to which column. All versioning rules
		are captured in sql/README.[mysql|sqlite3|pgsql] documents.
DEFAULT:	1	

KEY:		sql_table_type 
VALUES		[ original | bgp ]
DESC:		BGP-related primitives are divided in legacy and non-legacy. Legacy are src_as, dst_as;
		non-legacy are all the rest. Up to "original" tables v5 src_as and dst_as were written
		in the same field as src_host and dst_host. From "original" table v6 and if sql_table_type
		"bgp" is selected, src_as and dst_as are written in their own field (as_src and as_dst
		respectively). sql_table_type is by default set to "original" and is switched to "bgp"
		automatically if any non-legacy primitive is in use, ie. peer_dst_ip, as_path, etc. This
		directive allows to make the selection explicit and/or circumvent default behaviour.
		Apart from src_as and dst_as, regular table versioning applies to all non-BGP related
		fields, for example: a) if "sql_table_type: bgp" and "sql_table_version: 1" then the "tag"
		field will be written in the "agent_id" column whereas; b) if "sql_table_type: bgp" and
		"sql_table_version: 9" instead, then the "tag" field will be written in the "tag" column.
		All versioning rules are captured in sql/README.[mysql|sqlite3|pgsql] documents.
DEFAULT:	original

KEY:		sql_data
VALUES:		[ typed | unified ]
DESC:		This switch makes sense only when using PostgreSQL plugin and supplied default tables
		up to v5: the pgsql scripts in the sql/ tree, up to v5, will in fact create a 'unified'
		table along with multiple 'typed' tables. The 'unified' table has IP and MAC addresses
		specified as standard CHAR strings, slower and not space savy but flexible; 'typed'
		tables sport PostgreSQL own types (inet, mac, etc.), resulting in a faster but more
		rigid structure. Since v6 unified mode is being discontinued leading to simplification.
		The supplied 'typed' schema can still be customized, ie. to write IP addresses in CHAR
		fields because making use of IP prefix labels, transparently to pmacct - making this
		configuration switch deprecated.
DEFAULT:	typed

KEY:	 	[ sql_host | mongo_host ]
DESC:		Defines the backend server IP/hostname
DEFAULT:	localhost

KEY:		[ sql_user | mongo_user ]
DESC:		Defines the username to use when connecting to the server. In MongoDB, if both
		mongo_user and mongo_passwd directives are omitted, authentication is disabled;
		if only one of the two is specified, the other is set to its default value.
DEFAULT:	pmacct

KEY:		[ sql_passwd | mongo_passwd ]
DESC:		Defines the password to use when connecting to the server. In MongoDB, if both
                mongo_user and mongo_passwd directives are omitted, authentication is disabled;
		if only one of the two is specified, the other is set to its default value.
DEFAULT:	'arealsmartpwd'

KEY:		[ sql_refresh_time | print_refresh_time | mongo_refresh_time | amqp_refresh_time |
		  kafka_refresh_time ] (-r)
DESC:		Time interval, in seconds, between consecutive executions of the plugin cache scanner. The
		scanner purges data into the plugin backend. Note: internally all these config directives
		write to the same variable; when using multiple plugins it is recommended to bind refresh
		time definitions to specific plugins, ie.:

		plugins: mysql[x], mongodb[y]
		sql_refresh_time[x]: 900
		mongo_refresh_time[y]: 300

		As doing otherwise can originate unexpected behaviours.
DEFAULT:	60

KEY:		[ sql_startup_delay | print_startup_delay | mongo_startup_delay | amqp_startup_delay |
		  kafka_startup_delay ]
DESC:		Defines the time, in seconds, the first cache scan event has to be delayed. This delay
		is, in turn, propagated to the subsequent scans. It comes useful in two scenarios: a) so 
		that multiple plugins can use the same refresh time (ie. sql_refresh_time) value, allowing
		them to spread the writes among the length of the time-bin; b) with NetFlow, when using
		a RDBMS, to keep original flow start time (nfacctd_time_new: false) while enabling the
		sql_dont_try_update feature (for RDBMS efficiency purposes); in such a context,
		sql_startup_delay value should be greater (better >= 2x the value) of the NetFlow active
		flow timeout.
DEFAULT:	0

KEY:		sql_optimize_clauses
VALUES:		[ true | false ]
DESC:		Enables the optimization of the statements sent to the RDBMS essentially allowing to a)
		run stripped-down variants of the default SQL tables or b) totally customized SQL tables
		by a free mix-and-match of the available primitives. Either case, you will need to build
		the custom SQL table schema and indexes. As a rule of thumb when NOT using this directive
		always remember to specify which default SQL table version you intend to stick to by using
		the 'sql_table_version' directive.
DEFAULT:	false

KEY:		[ sql_history | print_history | mongo_history | amqp_history | kafka_history ]
VALUES:		#[s|m|h|d|w|M]
DESC:		Enables historical accounting by placing accounted data into configurable time-bins. It
		will use the 'stamp_inserted' (base time of the time-bin) and 'stamp_updated' (last time
		the time-bin was touched) fields. The supplied value defines the time slot length during
		which counters are accumulated. For a nice effect, it's adviceable to pair this directive
		with 'sql_history_roundoff'. In nfacctd, where a flow can span across multiple time-bins,
		flow counters can be pro-rated (seconds timestamp resolution) over involved time-bins by
		setting nfacctd_pro_rating to true. Note that this value is fully disjoint from the
		*_refresh_time directives which set the time intervals at which data has to be written to
		the backend instead. The final effect is close to time slots in a RRD file. Examples of
		valid values are: '300' or '5m' - five minutes, '3600' or '1h' - one hour, '14400' or '4h'
		- four hours, '86400' or '1d' - one day, '1w' - one week, '1M' - one month).
DEFAULT:	none

KEY:            [ sql_history_offset | print_history_offset | mongo_history_offset | amqp_history_offset |
		  kafka_history_offset ]
DESC:		Sets an offset to timeslots basetime. If history is set to 30 mins (by default creating
		10:00, 10:30, 11:00, etc. time-bins), with an offset of 900 seconds (so 15 mins) it will
		create 10:15, 10:45, 11:15, etc. time-bins. It expects a positive value, in seconds.
DEFAULT:	0

KEY:		[ sql_history_roundoff | print_history_roundoff | mongo_history_roundoff |
		  amqp_history_roundoff | kafka_history_roundoff ]
VALUES		[m,h,d,w,M]
DESC:		Enables alignment of minutes (m), hours (h), days of month (d), weeks (w) and months (M)
		in print (to print_refresh_time) and SQL plugins (to sql_history and sql_refresh_time).
		Suppose you go with 'sql_history: 1h', 'sql_history_roundoff: m' and it's 6:34pm. Rounding
		off minutes gives you an hourly timeslot (1h) starting at 6:00pm; so, subsequent ones will
		start at 7:00pm, 8:00pm, etc. Now, you go with 'sql_history: 5m', 'sql_history_roundoff: m'
		and it's 6:37pm. Rounding off minutes will result in a first slot starting at 6:35pm; next
		slot will start at 6:40pm, and then every 5 minutes (6:45pm ... 7:00pm, etc.). 'w' and 'd'
		are mutually exclusive, that is: you can either reset the date to last Monday or reset the
		date to the first day of the month. 
DEFAULT:	none

KEY:		sql_recovery_logfile
DESC:		Enables recovery mode; recovery mechanism kicks in if the DB fails. It works by checking
		for the successful result of each SQL query. By default it is disabled. By using this key
		aggregates are recovered to the specified logfile. Data may be played later by either
		'pmmyplay' or 'pmpgplay' tools. Each time pmacct package is updated it's good rule not
		continue writing old files but start a new ones. Each plugin instance has to write to a
		different logfile in order to avoid inconsistencies over data. And, finally, the maximum
		size for a logfile is set to 2Gb: if the logfile reaches such size, it's automatically
		rotated (in a way similar to logrotate: old file is renamed, appending a little sequential
		integer to it, and a new file is started). See INTERNALS 'Recovery modes' section for
		details about this topic. SQLite 3.x note: because the database is file-based it's quite
		useless to have a logfile, thus this feature is not supported. However, note that the
		'sql_recovery_backup_host' directive allows to specify an alternate SQLite 3.x database
		file. 
DEFAULT:	none

KEY:            sql_recovery_backup_host
DESC:           Enables recovery mode; recovery mechanism kicks in if DB fails. It works by checking for
		the successful result of each SQL query. By default it is disabled. By using this key
		aggregates are recovered to a secondary DB. See INTERNALS 'Recovery modes' section for 
		details about this topic. SQLite 3.x note: the plugin uses this directive to specify
		a the full path to an alternate database file (e.g., because you have multiple file
		system on a box) to use in the case the primary backend fails.
DEFAULT:	none

KEY:            [ sql_max_writers | print_max_writers | mongo_max_writers | amqp_max_writers |
		  kafka_max_writers ]
DESC:           Sets the maximum number of concurrent writer processes the plugin is allowed to start.
		This setting allows pmacct to degrade gracefully during major backend lock/outages/
		unavailability. The value is split as follows: up to N-1 concurrent processes will
		queue up; the Nth process will go for a recovery mechanism, if configured (like:
		sql_recovery_logfile, sql_recovery_backup_host for SQL plugins), writers beyond Nth
		will stop managing data (so, data will be lost at this stage) and an error message is
		printed out.
DEFAULT:	10

KEY:		[ sql_cache_entries | print_cache_entries | mongo_cache_entries | amqp_cache_entries |
		  kafka_cache_entries ]
DESC:		All plugins have a memory cache in order to store data until next purging event (see
		sql_refresh_time). In case of network traffic data caching allows to accumulate bytes
		and packets counters. This directive sets the number of cache buckets. Default value
		is suitable for most common scenarios, however when facing large-scale networks, it
		is higly recommended to tune this parameter to improve performances. Use a prime
		number of buckets.
NOTES:		all non SQL plugins share the same cache structure: as said, this setting defines the
		amount of cache bucket (ie. not the total among of entries). The default value (16411)
		allows for some 150K entries to fit the cache structure (calculate ten times the
		supplied value).
DEFAULT:	sql_cache_entries: 32771; print_cache_entries, mongo_cache_entries, amqp_cache_entries,
		kafka_cache_entries: 16411

KEY:		sql_dont_try_update
VALUES:         [ true | false ]
DESC:		By default pmacct uses an UPDATE-then-INSERT mechanism to write data to the RDBMS; this
		directive instructs pmacct to use a more efficient INSERT-only mechanism. This directive
		is useful for gaining performances by avoiding UPDATE queries. Using this directive puts
		some timing constraints, specifically sql_history == sql_refresh_time, otherwise it may
		lead to duplicate entries and, potentially, loss of data. When used in nfacctd it also
		requires nfacctd_time_new to be enabled.
DEFAULT:	false

KEY:            sql_use_copy
VALUES:         [ true | false ]
DESC:		Instructs the plugin to build non-UPDATE SQL queries using COPY (in place of INSERT). While
		providing same functionalities of INSERT, COPY is also more efficient. To have effect, this
		directive requires 'sql_dont_try_update' to be set to true. It applies to PostgreSQL plugin
		only.
NOTES:		Error handling of the underlying PostgreSQL API is somewhat limited. During a COPY only
		transmission errors are detected but not syntax/semantic ones, ie. related to the query
		and/or the table schema. 
DEFAULT:        false

KEY:		sql_delimiter
DESC:		If sql_use_copy is true, uses the supplied character as delimiter. This is thought in cases
		where the default delimiter is part of any of the supplied strings to be inserted into the
		database.
DEFAULT:	','

KEY:		[ amqp_multi_values | sql_multi_values | kafka_multi_values ]
DESC:		In SQL plugin, sql_multi_values enables the use of multi-values INSERT statements. The value
		of the directive is intended to be the size (in bytes) of the multi-values buffer. The directive
		applies only to MySQL and SQLite 3.x plugins. Inserting many rows at the same time is much
		faster (many times faster in some cases) than using separate single-row INSERT statements.
		It's adviceable to check the size of this pmacct buffer against the size of the corresponding
		MySQL buffer (max_allowed_packet). In AMQP plugin, amqp_multi_values enables similar feature:
		the value is intended as the amount of elements to pack in each JSON array.
DEFAULT:        0

KEY:		[ sql_trigger_exec | print_trigger_exec | mongo_trigger_exec ]
DESC:		Defines the executable to be launched at fixed time intervals to post-process aggregates;
		in SQL plugins, intervals are specified by the 'sql_trigger_time' directive; if no interval
		is supplied 'sql_refresh_time' value is used instead: this will result in a trigger being
		fired each purging event. A number of environment variables are set in order to allow the
		trigger to take actions; take a look to docs/TRIGGER_VARS to check them out. In the print
		and mongodb plugins a simpler implementation is made: triggers can be fired each time data
		is written to the backend (ie. print_refresh_time) and no environment variables are passed
		over to the executable.
DEFAULT:	none

KEY:		sql_trigger_time
VALUES:		#[s|m|h|d|w|M]
DESC:		Specifies time interval at which the executable specified by 'sql_trigger_exec' has to
		be launched; if no executables are specified, this key is simply ignored. Values need to be 
		in the 'sql_history' directive syntax (for example, valid values are '300' or '5m', '3600'
		or '1h', '14400' or '4h', '86400' or '1d', '1w', '1M'; eg. if '3600' or '1h' is selected,
		the executable will be fired each hour).
DEFAULT:	none

KEY:		[ sql_preprocess | print_preprocess | mongo_preprocess | amqp_preprocess | kafka_preprocess ]
DESC:		Allows to process aggregates (via a comma-separated list of conditionals and checks) while
		purging data to the backend thus resulting in a powerful selection tier; aggregates filtered
		out may be just discarded or saved through the recovery mechanism (if enabled, if supported
		by the backend). The set of available preprocessing directives follows:
		
		KEY: qnum
		DESC: conditional. Subsequent checks will be evaluated only if the number of queries to be
		      created during the current cache-to-DB purging event is '>=' qnum value. SQL plugins
		      only. 

		KEY: minp
		DESC: check. Aggregates on the queue are evaluated one-by-one; each object is marked valid
		      only if the number of packets is '>=' minp value. All plugins. 

		KEY: minf
		DESC: check. Aggregates on the queue are evaluated one-by-one; each object is marked valid
		      only if the number of flows is '>=' minf value. All plugins.

		KEY: minb
		DESC: check. Aggregates on the queue are evaluated one-by-one; each object is marked valid
		      only if the bytes counter is '>=' minb value. An interesting idea is to set its value 
		      to a fraction of the link capacity. Remember that you have also a timeframe reference:
		      the 'sql_refresh_time' seconds. All plugins. 

		      For example, given the following parameters:
		      Link Capacity = 8Mbit/s, THreshold = 0.1%, TImeframe = 60s 
		      minb = ((LC / 8) * TI) * TH -> ((8Mbit/s / 8) * 60s) * 0.1% = 60000 bytes.

		      Given a 8Mbit link, all aggregates which have accounted for at least 60Kb of traffic
		      in the last 60 seconds, will be written to the DB. 

		KEY: maxp
		DESC: check. Aggregates on the queue are evaluated one-by-one; each object is marked valid
		      only if the number of packets is '<' maxp value. SQL plugins only.

		KEY: maxf
		DESC: check. Aggregates on the queue are evaluated one-by-one; each object is marked valid
		      only if the number of flows is '<' maxf value. SQL plugins only.

		KEY: maxb
		DESC: check. Aggregates on the queue are evaluated one-by-one; each object is marked valid
		      only if the bytes counter is '<' maxb value. SQL plugins only. 

		KEY: maxbpp
		DESC: check. Aggregates on the queue are evaluated one-by-one; each object is marked valid
		      only if the number of bytes per packet is '<' maxbpp value. SQL plugins only.

		KEY: maxppf
		DESC: check. Aggregates on the queue are evaluated one-by-one; each object is marked valid
		      only if the number of packets per flow is '<' maxppf value. SQL plugins only.

		KEY: minbpp
		DESC: check. Aggregates on the queue are evaluated one-by-one; each object is marked valid
		      only if the number of bytes per packet is '>=' minbpp value. All plugins. 

		KEY: minppf
		DESC: check. Aggregates on the queue are evaluated one-by-one; each object is marked valid
		      only if the number of packets per flow is '>=' minppf value. All plugins. 

		KEY: fss 
		DESC: check. Enforces flow (aggregate) size dependent sampling, computed against the bytes
		      counter and returns renormalized results. Aggregates which have collected more than the
		      supplied 'fss' threshold in the last time window (specified by the 'sql_refresh_time'
		      configuration key) are sampled. Those under the threshold are sampled with probability
		      p(bytes). The method allows to get much more accurate samples compared to classic 1/N
		      sampling approaches, providing an unbiased estimate of the real bytes counter. It would
		      be also adviceable to hold the the equality 'sql_refresh_time' = 'sql_history'. 
		      For further references: http://www.research.att.com/projects/flowsamp/ and specifically
		      to the papers: N.G. Duffield, C. Lund, M. Thorup, "Charging from sampled network usage",
		      http://www.research.att.com/~duffield/pubs/DLT01-usage.pdf and N.G. Duffield and C. Lund,
		      "Predicting Resource Usage and Estimation Accuracy in an IP Flow Measurement Collection
		      Infrastructure", http://www.research.att.com/~duffield/pubs/p313-duffield-lund.pdf
		      SQL plugins only.

		KEY: fsrc
		DESC: check. Enforces flow (aggregate) sampling under hard resource constraints, computed
		      against the bytes counter and returns renormalized results. The method selects only 'fsrc'
		      flows from the set of the flows collected during the last time window ('sql_refresh_time'),
		      providing an unbiasied estimate of the real bytes counter. It would be also adviceable
		      to hold the equality 'sql_refresh_time' = 'sql_history'.
		      For further references: http://www.research.att.com/projects/flowsamp/ and specifically
		      to the paper: N.G. Duffield, C. Lund, M. Thorup, "Flow Sampling Under Hard Resource
		      Constraints", http://www.research.att.com/~duffield/pubs/DLT03-constrained.pdf 
		      SQL plugins only.

		KEY: usrf 
		DESC: action. Applies the renormalization factor 'usrf' to counters of each aggregate. Its use 
		      is suitable for use in conjunction with uniform sampling methods (for example simple random
		      - e.g. sFlow, 'sampling_rate' directive or simple systematic - e.g. sampled NetFlow by
		      Cisco and Juniper). The factor is applied to recovered aggregates also. It would be also
		      adviceable to hold the equality 'sql_refresh_time' = 'sql_history'. Before using this action
		      to renormalize counters generated by sFlow, take also a read of the 'sfacctd_renormalize'
		      key. SQL plugins only.

		KEY: adjb 
		DESC: action. Adds (or subtracts) 'adjb' bytes to the bytes counter multiplied by the number of
		      packet in each aggregate. This is a particularly useful action when - for example - fixed
		      lower (link, llc, etc.) layer sizes need to be included into the bytes counter (as explained
		      by Q7 in FAQS document). SQL plugins only.

		KEY: recover
		DESC: action. If previously evaluated checks have marked the aggregate as invalid, a positive
		      'recover' value makes the packet to be handled through the recovery mechanism (if enabled).  
		      SQL plugins only.

		For example, during a data purge, in order to filter in only aggregates counting 100KB or more
		the following line can be used to instrument the print plugin: 'print_preprocess: minb=100000'. 
DEFAULT:	none

KEY:		[ sql_preprocess_type | print_preprocess_type | mongo_preprocess_type | amqp_preprocess_type |
		  kafka_preprocess_type ]
VALUES:		[ any | all ]
DESC:		When more checks are to be evaluated, this directive tells whether aggregates on the queue
		are valid if they just match one of the checks (any) or all of them (all).
DEFAULT:	any

KEY:		timestamps_secs
VALUES:		[ true | false ]
DESC:		Sets timestamp (timestamp_start, timestamp_end, timestamp_arrival primitives) resolution to
		seconds, ie. prevents residual time fields like timestamp_start_residual to be populated.
		In nfprobe plugin, when exporting via NetFlow v9 (nfprobe_version: 9), allows to fallback
		to first and last swithed times in seconds.
DEFAULT:        false

KEY:            timestamps_since_epoch
VALUES          [ true | false ]
DESC:           All timestamps (ie. timestamp_start, timestamp_end, timestamp_arrival primitives; sql_history-
		related fields stamp_inserted, stamp_updated; etc.) in the standard seconds since the Epoch
		format. In case the output is to a RDBMS, setting this directive to true will require changes
		to the default types for timestamp fields in the SQL schema.

		MySQL:          DATETIME ==> INT(8) UNSIGNED
                PostgreSQL:     timestamp without time zone ==> bigint
                SQLite3:        DATETIME ==> INT(8)
DEFAULT:        false

KEY:		mongo_insert_batch
DESC:		When purging data in a MongoDB database, defines the amount of elements to be inserted per
		batch. This value depends on available memory: with 8GB RAM a max 35000 value did work OK;
		with 16GB RAM a max 75000 value did work OK instead.
DEFAULT:	10000

KEY:            mongo_indexes_file
DESC:           Full pathname to a file containing a list of indexes to apply to a MongoDB collection with
		dynamic name. If the collection does not exists, it is created. Index names are picked by
		MongoDB. For example, to create collections with two indexes 1) one using as key source/
		destination IP addresses and 2) the other using source/destination TCP/UDP ports compile
		the file pointed by this directive as:

		src_host, dst_host
		src_port, dst_port

KEY:		print_markers
VALUES:		[ true | false ]
DESC:		Enables the use of START/END markers each time data is written to 'stdout'. Start marker returns 
		additional information about current time-bin and configured refresh time.
DEFAULT:	false

KEY:		print_output
VALUES:		[ formatted | csv | json | event_formatted | event_csv ]
DESC:		Defines the print plugin output format. 'formatted' enables tabular output; 'csv' is to enable
		comma-separated values format, suitable for injection into 3rd party tools. 'event' versions of
		the output strips trailing bytes and packets counters. 'json' is to enable JavaScript Object
		Notation format, also suitable for injection into 3rd party tools. Being a self-descriptive
		format (hence not requiring a table title), JSON does not require a event-counterpart; on the
		cons, JSON serialization introduces some lag due to the extensive string manipulation (as an
		example: 10M lines may be written to disk in 30 secs as CSV and 150 secs as JSON). The 'json'
		format requires compiling the package against Jansson library (downloadable at the following
		URL: http://www.digip.org/jansson/)
NOTES:		* Jansson library does not seem to have concept of unsigned integers. integers up to 32 bits
		  are packed as 'I', ie. 64 bits signed integers, working around the issue. No work around is
		  possible for unsigned 64 bits integers instead (ie. tag, tag2, packets, bytes). 
DEFAULT:	formatted

KEY:            print_output_separator
DESC:           Defines the print plugin output separator. Value is expected to be a single character and
		cannot be a spacing (if spacing separator is wanted then 'formatted' output should be the
		natural choice)
DEFAULT:	','

KEY:            [ print_num_protos | sql_num_protos | amqp_num_protos | mongo_num_protos | kafka_num_protos ]
VALUES:         [ true | false ]
DESC:		Defines whether IP protocols (ie. tcp, udp) should be looked up and presented in string format
		or left numerical. The default is to look protocol names up.
DEFAULT:	false

KEY:            sql_num_hosts
VALUES:         [ true | false ]
DESC:           Defines whether IP addresses should be left numerical (in network bytes ordering) or converted
		into human-readable strings. Applies to MySQL and SQLite plugins only and assumes the INET_ATON()
		and INET6_ATON() function are defined in the RDBMS. INET_ATON() is always defined in MySQL whereas
		INET6_ATON() requires MySQL >= 5.6.3. Bothfunctions are not defined by default in SQLite instead.
		The feature is not compatible with making use of IP prefix labels. Default setting is to convert
		IP addresses and prefixes into strings.
DEFAULT:        false

KEY:		[ nfacctd_port | sfacctd_port ] (-l) [GLOBAL, NO_PMACCTD, NO_UACCTD]
DESC:		Defines the UDP port where to bind nfacctd (nfacctd_port) and sfacctd (sfacctd_port) daemons.
DEFAULT:	nfacctd_port: 2100; sfacctd_port: 6343 

KEY:		[ nfacctd_ip | sfacctd_ip ] (-L) [GLOBAL, NO_PMACCTD, NO_UACCTD]
DESC:		Defines the IPv4/IPv6 address where to bind the nfacctd (nfacctd_ip) and sfacctd (sfacctd_ip)
		daemons.
DEFAULT:	all interfaces

KEY:		core_proc_name
DESC:		Defines the name of the core process. This is the equivalent to instantiate named plugins but
		for the core process.
DEFAULT:	'default'

KEY:		proc_priority
DESC:		Redefines the process scheduling priority, equivalent to using the 'nice' tool. Each daemon
		process, ie. core, plugins, etc., can define a different priority.
DEFAULT:	0

KEY:		[ nfacctd_allow_file | sfacctd_allow_file ] [GLOBAL, NO_PMACCTD, NO_UACCTD]
DESC:		Full pathname to a file containing the list of IPv4/IPv6 addresses (one for each line) allowed
		to send packets to the daemon. Current syntax does not implement network masks but individual
		IP addresses only. The Allow List is intended to be small; firewall rules should be preferred
		to long ACLs.
DEFAULT:	none (ie. allow all)

KEY:		nfacctd_time_secs [GLOBAL, NFACCTD_ONLY]
VALUES:		[ true | false ]
DESC:		Makes 'nfacctd' expect times included in NetFlow header to be in seconds rather than msecs. This
		knob makes sense for NetFlow up to v8 - as in NetFlow v9 and IPFIX different fields are reserved
		for secs and msecs timestamps, increasing collector awareness.
DEFAULT:        false

KEY:		nfacctd_time_new [GLOBAL, NFACCTD_ONLY]
VALUES:		[ true | false ]
DESC:		Makes 'nfacctd' to ignore timestamps included in NetFlow header and build new ones. This gets
		particularly useful to assign flows to time-bins based on the flow arrival time at the collector
		rather than the flow start time. An application for it is when historical accounting is enabled
		('sql_history') and an INSERT-only mechanism is in use ('sql_dont_try_update', 'sql_use_copy').
DEFAULT:        false

KEY:		nfacctd_pro_rating [NFACCTD_ONLY]
VALUES:		[ true | false ]
DESC:		If nfacctd_time_new is set to false (default) and historical accounting (ie. sql_history) is
		enabled, this directive enables pro rating of NetFlow/IPFIX flows over time-bins, if needed.
		For example, if sql_history is set to '5m' (so 300 secs), the considered flow duration is 1000
		secs, its bytes counter is 1000 bytes and, for simplicity, its start time is at the base time
		of t0, time-bin 0, then the flow is inserted in time-bins t0, t1, t2 and t3 and its bytes
		counter is proportionally split among these time-bins: 300 bytes during t0, t1 and t2 and
		100 bytes during t3.
NOTES:          If NetFlow sampling is enabled, it is recommended to have counters renormalization enabled
                (nfacctd_renormalize set to true).
DEFAULT:        false

KEY:            [ nfacctd_stitching | sfacctd_stitching | pmacctd_stitching | uacctd_stitching ]
VALUES:         [ true | false ]
DESC:		If set to true adds two new fields, timestamp_min and timestamp_max: given an aggregation
		method ('aggregate' config directive), timestamp_min is the timestamp of the first element
		contributing to a certain aggregate, timestamp_max is the timestamp of the last element. In
		case the export protocol provides time references, ie. NetFlow/IPFIX, these are used; if not
		of if using NetFlow/IPFIX as export protocol and nfacctd_time_new is set to true the current
		time (hence time of arrival to the collector) is used instead. The feature is not compatible
		with pro-rating, ie. nfacctd_pro_rating. Also, the feature is supported on all plugins except
		the 'memory' one (please get in touch if you have a use-case for it).
DEFAULT:        false

KEY:            nfacctd_account_options [GLOBAL, NFACCTD_ONLY]
VALUES:         [ true | false ]
DESC:		If set to true account for NetFlow/IPFIX option records. This will require define custom
		primitives via aggregate_primitives. pre_tag_map offers sample_type value of 'option' in
		order to split option data records from flow or event data ones.
DEFAULT:        false

KEY:		[ nfacctd_as | sfacctd_as | pmacctd_as | uacctd_as ] [GLOBAL]
VALUES:		[ netflow | sflow | file | bgp | longest ]
DESC:		When set to 'netflow' or 'sflow' it instructs nfacctd and sfacctd to populate 'src_as',
		'dst_as', 'peer_src_as' and 'peer_dst_as' primitives from information in NetFlow and sFlow
		datagrams; when set to 'file', it instructs nfacctd and sfacctd to populate 'src_as',
		'dst_as' and 'peer_dst_as' by looking up source and destination IP addresses against a
		supplied networks_file. When 'bgp' is specified, source and destination IP addresses are
		looked up against the BGP RIB of the peer from which the NetFlow (or sFlow) datagram was
		received (see also bgp_agent_map directive for more complex mappings). 'longest' behaves
		in a longest-prefix match wins fashion: in nfacctd and sfacctd lookup is done against a
		networks_file (if specified), sFlow/NetFlow protocol and BGP (if the BGP thread is started)
		with the following logics: networks_file < sFlow/NetFlow < <= BGP.
		In pmacctd and uacctd: 'file' expects a 'networks_file' to be defined; 'bgp' just works
		as described previously for nfacctd and sfacctd; 'longest' lookup is done against a
		networks_file and BGP only (networks_file <= BGP) since no export protocol lookup method
		is available. Read nfacctd_net description for an example of operation of the 'longest'
		method. 

		Unless there is a specific goal do achieve, it is highly recommended that this definition,
		ie. nfacctd_as, is kept in sync with its net equivalent, ie. nfacctd_net.
DEFAULT:        none

KEY:            [ nfacctd_net | sfacctd_net | pmacctd_net | uacctd_net ] [GLOBAL]
VALUES:         [ netflow | sflow | mask | file | igp | bgp | longest ]
DESC:		Determines the method for performing IP prefix aggregation - hence directly influencing 'src_net',
		'dst_net', 'src_mask', 'dst_mask' and 'peer_dst_ip' primitives. 'netflow' and 'sflow' get values
		from NetFlow and sFlow protocols respectively; these keywords are only valid in nfacctd, sfacctd.
		'mask' applies a defined networks_mask; 'file' selects a defined networks_file; 'igp' and 'bgp'
		source values from IGP/IS-IS daemon and BGP daemon respectively. For backward compatibility, the
		default behaviour in pmacctd and uacctd is: 'mask' and 'file' are turned on if a networks_mask and
		a networks_file are respectively specified by configuration. If they are both defined, the outcome
		will be the intersection of their definitions. 'longest' behaves in a longest-prefix match wins
		fashion: in nfacctd and sfacctd lookup is done against a networks list (if networks_file is defined)
		sFlow/NetFlow protocol, IGP (if the IGP thread started) and BGP (if the BGP thread is started) with
		the following logics: networks_file < sFlow/NetFlow < IGP <= BGP; in pmacctd and uacctd lookup is
		done against ia networks list, IGP and BGP only (networks_file < IGP <= BGP). For example we receive
		the following PDU via NetFlow:

                SrcAddr: 10.0.8.29 (10.0.8.29)
                DstAddr: 192.168.5.47 (192.168.5.47)
                [ .. ]
                SrcMask: 24 (prefix: 10.0.8.0/24)
                DstMask: 27 (prefix: 192.168.5.32/27)

                a BGP peering is available and BGP contains the following prefixes: 192.168.0.0/16 and 10.0.0.0/8.
                A networks_file contains the prefixes 10.0.8.0/24 and 192.168.5.0/24. 'longest' would select as
		outcome of the network aggregation process 10.0.8.0/24 for the src_net and src_mask respectively
		and 192.168.5.32/27 for dst_net and dst_mask. 

		Unless there is a specific goal to achieve, it is highly recommended that the definition of this
		configuration directive is kept in sync with its ASN equivalent, ie. nfacctd_as.
DEFAULT:	nfacctd: 'netflow'; sfacctd: 'sflow'; pmacctd and uacctd: 'mask', 'file'

KEY:		use_ip_next_hop [GLOBAL]
VALUES:		[ true | false ] 
DESC:		When IP prefix aggregation (ie. nfacctd_net) is set to 'netflow', 'sflow' or 'longest' (in
		which case longest winning match is via 'netflow' or 'sflow') populate 'peer_dst_ip' field
		from NetFlow/sFlow IP next hop field if BGP next-hop is not available.
DEFAULT:        false

KEY:		[ nfacctd_mcast_groups | sfacctd_mcast_groups ] [GLOBAL, NO_PMACCTD, NO_UACCTD]
DESC:		Defines one or more IPv4/IPv6 multicast groups to be joined by the daemon. If more groups are
		supplied, they are expected comma separated. A maximum of 20 multicast groups may be joined by
		a single daemon instance. Some OS (noticeably Solaris -- seems) may also require an interface
		to bind to which - in turn - can be supplied declaring an IP address ('nfacctd_ip' key). 
DEFAULT:	none

KEY:            [ nfacctd_disable_checks | sfacctd_disable_checks ] [GLOBAL, NO_PMACCTD, NO_UACCTD]
VALUES:         [ true | false ]
DESC:           Both nfacctd and sfacctd check health of incoming NetFlow/sFlow datagrams, ie. sequence
		number checks, protocol version. You may want to disable such feature because of non-
		standard implementations or multiple protocols (accidentally?) pointed to the same port.
DEFAULT:        false

KEY:		pre_tag_map [MAP]
DESC:		Full pathname to a file containing tag mappings. Tags can be internal-only (ie. for filtering
		purposes, see pre_tag_filter configuration directive) or exposed to users (ie. if 'tag', 'tag2'
		and/or 'label' primitives are part of the aggregation method). Take a look to the examples/
		sub-tree for all supported keys and detailed examples (pretag.map.example). Pre-Tagging is
		evaluated in the Core Process and each plugin can be defined a local pre_tag_map. Result of
		evaluation of pre_tag_map overrides any tags passed via NetFlow/sFlow by a pmacct nfprobe/
		sfprobe plugin.  
DEFAULT:	none

KEY:		maps_entries
DESC:		Defines the maximum number of entries a map (ie. pre_tag_map and all directives with the
		'MAP' flag) can contain. The default value is suitable for most scenarios, though tuning it
		could be required either to save on memory or to allow for more entries. Refer to the
		specific map directives documentation in this file to see which are affected by this setting.
DEFAULT:	384

KEY:            maps_row_len
DESC:		Defines the maximum length of map (ie. pre_tag_map and all directives with the 'MAP' flag)
		rows. The default value is suitable for most scenario, though tuning it could be required
		either to save on memory or to allow for more entries.
DEFAULT:	256

KEY:		maps_refresh [GLOBAL]
VALUES:		[ true | false ]
DESC:		When enabled, this directive allows to reload map files (ie. pre_tag_map and all directives
		with the 'MAP' flag) without restarting the daemon instance. For example, it may result
		particularly useful to reload pre_tag_map or networks_file entries in order to reflect some
		change in the network. After having modified the map files, a SIGUSR2 has to be sent (e.g.:
		in the simplest case "killall -USR2 pmacctd") to the daemon to notify the change. If such
		signal is sent to the daemon and this directive is not enabled, the signal is silently
		discarded. The Core Process is in charge of processing the Pre-Tagging map; plugins are
		devoted to Networks and Ports maps instead. Then, because signals can be sent either to the
		whole daemon (killall) or to just a specific process (kill), this mechanism also offers the
		advantage to elicit local reloads.
DEFAULT:        true

KEY:		maps_index [GLOBAL]
VALUES:		[ true | false ]
DESC:		Enables indexing of maps ((ie. pre_tag_map and all directives with the 'MAP' flag) to
		increase lookup speeds on large maps and/or sustained lookup rates. Indexes are automatically
		defined basing on structure and content of the map, up to a maximum of 8. Indexing of
		pre_tag_map, bgp_peer_src_as_map, flows_to_rd_map is supported. Only a sub-set of pre_tag_map
		fields are supported, including: ip, bgp_nexthop, vlan, cvlan, src_mac, mpls_vpn_rd, mpls_pw_id,
		src_as, dst_as, peer_src_as, peer_dst_as, input, output). Only IP addresses, ie. no IP prefixes,
		are supported as part of the 'ip' field. Also, negations are not supported (ie. 'in=-216' match
		all but input interface 216). bgp_agent_map and sampling_map implement a separate caching
		mechanism and hence do not leverage this feature.
DEFAULT:        false

KEY:            pre_tag_filter, pre_tag2_filter [NO_GLOBAL]
VALUES:         [ 0-2^64-1 ]
DESC:		Expects one or more tags (when multiple tags are supplied, they need to be comma separated
		and a logical OR is used in the evaluation phase) as value and allows to filter aggregates
		basing upon their tag value: in case of a match, the aggregate is delivered to the plugin.
		This directive has to be bound to a plugin (that is, it cannot be global) and is suitable,
		for example, to split tagged data among the active plugins. While tags themselves need to be
		positive values, this directive also allows to specify a tag value '0' to intercept untagged
		data, thus allowing to split tagged traffic from untagged one. It also allows negations by
		pre-pending a minus sign to the tag value (ie. '-6' would send everything but traffic tagged
		as '6' to the plugin it is bound to) and ranges (ie. '10-20' would send over traffic tagged
		in the range 10..20) and any combination of these. This directive makes sense if coupled with
		'pre_tag_map'; it could be used in conjunction with 'aggregate_filter'.
DEFAULT:	none

KEY:            pre_tag_label_filter [NO_GLOBAL]
DESC:		Expects one or more labels (when multiple labels are supplied, they need to be comma
		separated and a logical OR is used in the evaluation phase) as value and allows to filter
		aggregates basing upon their label value: only in case of match data is delivered to the
		plugin. This directive has to be bound to a plugin (that is, it cannot be global). Null
		label values (ie. unlabelled data) can be matched using the 'null' keyword. Negations are
		allowed by pre-pending a minus sign to the label value. The use of this directive makes
		sense if coupled with 'pre_tag_map'.
DEFAULT:	none

KEY:            [ post_tag | post_tag2 ] 
VALUES:         [ 1-2^64-1 ]
DESC:           Expects a tag as value. Post-Tagging is evaluated in the plugins. The tag is used as 'tag'
		(post_tag) or 'tag2' (post_tag2) primitive value. Use of these directives hence makes sense
		if tag and/or tag2 primitives are part of the plugin aggregation method.
DEFAULT:	none

KEY:		sampling_rate
VALUES:		[ >= 1 ]
DESC:		Enables packet sampling. It expects a number which is the mean ratio of packets to be sampled
		(1 out of N). The currently implemented sampling algorithm is a simple randomic one. If using 
		any SQL plugin, look also to the powerful 'sql_preprocess' layer and the more advanced sampling
		choices it offers: they will allow to deal with advanced sampling scenarios (e.g. probabilistic
		methods). Finally, note that this 'sampling_rate' directive can be renormalized by using the 
		'usrf' action of the 'sql_preprocess' layer.
DEFAULT:	none

KEY:            sampling_map [GLOBAL, NO_PMACCTD, NO_UACCTD, MAP]
DESC:           Full pathname to a file containing traffic sampling mappings. It is mainly meant to be used
		in conjunction with nfacctd and sfacctd for the purpose of fine-grained reporting of sampling
		rates circumventing bugs and issues in router operating systems. Renormalization must be
		enabled (nfacctd_renormalize or sfacctd_renormalize set to true) in order for the feature to
		work. If a specific router is not defined in the map, the sampling rate advertised by the
		router itself is applied. Take a look to the examples/ sub-tree 'sampling.map.example' for all
		supported keys and detailed examples.
DEFAULT:	none

KEY:		[ pmacctd_force_frag_handling | uacctd_force_frag_handling ] [GLOBAL, NO_NFACCTD, NO_SFACCTD]
VALUES:		[ true | false ]
DESC:		Forces 'pmacctd' to join together IPv4/IPv6 fragments: 'pmacctd' does this only whether any of
		the port primitives are selected (src_port, dst_port, sum_port); in fact, when not dealing with
		any upper layer primitive, fragments are just handled as normal packets. However, available
		filtering rules ('aggregate_filter', Pre-Tag filter rules) will need such functionality enabled
		whether they need to match TCP/UDP ports. So, this directive aims to support such scenarios.
DEFAULT:        false

KEY:		[ pmacctd_frag_buffer_size | uacctd_frag_buffer_size ] [GLOBAL, NO_NFACCTD, NO_SFACCTD]
DESC:		Defines the maximum size of the fragment buffer. In case IPv6 is enabled two buffers of equal
		size will be allocated. The value is expected in bytes.
DEFAULT:	4MB 

KEY:            [ pmacctd_flow_buffer_size | uacctd_flow_buffer_size ] [GLOBAL, NO_NFACCTD, NO_SFACCTD]
DESC:           Defines the maximum size of the flow buffer. This is an upper limit to avoid unlimited growth
		of the memory structure. This value has to scale accordingly to the link traffic rate. In case
		IPv6 is enabled two buffers of equal size will be allocated. The value is expected in bytes.
DEFAULT:	16MB

KEY:            [ pmacctd_flow_buffer_buckets | uacctd_flow_buffer_buckets ] [GLOBAL, NO_NFACCTD, NO_SFACCTD] 
DESC:           Defines the number of buckets of the flow buffer - which is organized as a chained hash table.
		To exploit better performances, the table should be reasonably flat. This value has to scale to
		higher power of 2 accordingly to the link traffic rate. For example, it has been reported that
		a value of 65536 works just fine under full 100Mbit load.
DEFAULT:	256

KEY:            [ pmacctd_conntrack_buffer_size | uacctd_conntrack_buffer_size ] [GLOBAL, NO_NFACCTD, NO_SFACCTD]
DESC:           Defines the maximum size of the connection tracking buffer. In case IPv6 is enabled two buffers
		of equal size will be allocated. The value is expected in bytes.
DEFAULT:	8MB

KEY:            [ pmacctd_flow_lifetime | uacctd_flow_lifetime ] [GLOBAL, NO_NFACCTD, NO_SFACCTD]
DESC:           Defines how long a non-TCP flow could remain inactive (ie. no packets belonging to such flow
		are received) before considering it expired. The value is expected in seconds.
DEFAULT:	60

KEY:            [ pmacctd_flow_tcp_lifetime | uacctd_flow_tcp_lifetime ] [GLOBAL, NO_NFACCTD, NO_SFACCTD]
DESC:           Defines how long a TCP flow could remain inactive (ie. no packets belonging to such flow are
		received) before considering it expired. The value is expected in seconds.
DEFAULT:	60 secs if classification is disabled; 432000 secs (120 hrs) if clssification is enabled

KEY:		[ pmacctd_ext_sampling_rate | uacctd_ext_sampling_rate | nfacctd_ext_sampling_rate |
		  sfacctd_ext_sampling_rate ] [GLOBAL]
		Flags pmacctd that captured traffic is being sampled at the specified rate. Such rate can then
		be renormalized by using 'pmacctd_renormalize' or otherwise is propagated by the NetFlow/sFlow
		probe plugins, if any of them is activated. External sampling might be performed by capturing
		frameworks the daemon is linked against (ie. PF_RING, ULOG) or appliances (ie. sampled packet
		mirroring).
		In nfacctd and sfacctd daemons this directive can be used to tackle corner cases, ie. sampling
		rate reported by the NetFlow/sFlow agent is missing or not correct.
DEFAULT:	none

KEY:		[ sfacctd_renormalize | nfacctd_renormalize | pmacctd_renormalize | uacctd_renormalize ] (-R)
		[GLOBAL]
VALUES:		[ true | false ]
DESC:		Automatically renormalizes byte/packet counters value basing on information acquired from 
		either the NetFlow data unit or sFlow packet. In particular, it allows to deal with scenarios
		in which multiple interfaces have been configured at different sampling rates. The feature also
		calculates an effective sampling rate (sFlow only) which could differ from the configured one -
		expecially at high rates - because of various losses. Such estimated rate is then used for
		renormalization purposes.
DEFAULT:        false

KEY:		pmacctd_nonroot [GLOBAL]
VALUES:		[ true | false ]
DESC:		Allow to run pmacctd from a user with non root privileges. This can be desirable on systems
		supporting a tool like setcap, ie. 'setcap "cap_net_raw,cap_net_admin=ep" /path/to/pmacctd',
		to assign specific system capabilities to unprivileged users.
DEFAULT:	false

KEY:            sfacctd_counter_file [GLOBAL, SFACCTD_ONLY]
DESC:           Enables streamed logging of sFlow counters. Each log entry features a time reference, sFlow
		agent IP address event type and a sequence number (to order events when time reference is not
		granular enough). Currently it is not possible to filter in/out specific counter types (ie.
		generic, ethernet, vlan, etc.). The list of supported filename variables follows:

                $peer_src_ip    sFlow agent IP address.

		Files can be re-opened by sending a SIGHUP to the daemon core process.
DEFAULT:	none

KEY:            sfacctd_counter_output [GLOBAL, SFACCTD_ONLY]
VALUES:         [ json ]
DESC:           Defines output format for the streamed logging of sFlow counters. Only JSON format is currently
		supported and requires compiling against Jansson library (--enable-jansson when configuring for
		compiling).
DEFAULT:	json

KEY:		classifiers [GLOBAL, NO_NFACCTD, NO_SFACCTD]
DESC:		Full path to a spool directory containing the packet classification patterns (expected as .pat
		or .so files; files with different extensions and subdirectories will be just ignored). This
		feature enables packet/flow classification against application layer data (that is, the packet
		payload) and based either over regular expression (RE) patterns (.pat) or external/pluggable C
		modules (.so). Patterns are loaded in filename alphabetic order and will be evaluated in the
		same order while classifying packets. Supported RE patterns are those from the great L7-filter
		project, which is a new packet classifier for Linux kernel, and are avilable for download at:
		http://sourceforge.net/projects/l7-filter/ (then point to the Protocol definitions archive).
		Existing SO patterns are available at: http://www.pmacct.net/classification/ . 
		This configuration directive should be specified whenever the 'class' aggregation method is in
		use (ie. 'aggregate: class'). It's supported only by pmacctd. 
DEFAULT:	none

KEY:		sql_aggressive_classification 
VALUES:		[ true | false ]
DESC:		Usually 5 to 10 packets are required to classify a stream by the 'classifiers' feature. Until
		the flow is not classified, such packets join the 'unknown' class. As soon as classification
		engine is successful identifying the stream, the packets are moved to their correct class if
		they are still cached by the SQL plugin. This directive delays 'unknown' streams - but only
		those which would have still chances to be correctly classified - from being purged to the DB
		but only for a small number of consecutive sql_refresh_time slots. It is incompatible with
		sql_dont_try_update and sql_use_copy directives.
DEFAULT:        false

KEY:		sql_locking_style
VALUES:		[ table | row | none ]
DESC:		Defines the locking style for the SQL table. MySQL supports "table" and "none" values whereas
		PostgreSQL supports "table", "row" and "none" values. With "table" value, the plugin will lock
		the entire table when writing data to the DB with the effect of serializing access to the
		table whenever multiple plugins need to access it simultaneously. Slower but light and safe,
		ie. no risk for deadlocks and transaction-friendly; "row", the plugin will lock only the rows
		it needs to UPDATE/DELETE. It results in better overral performances but has some noticeable
		drawbacks in dealing with transactions and making the UPDATE-then-INSERT mechanism work
		smoothly; "none" disables locking: while this method can help in some cases, ie. when grants
		over the whole database (requirement for "table" locking in MySQL) is not available, it is not
		recommended since serialization allows to contain database load.
DEFAULT:        table

KEY:		classifier_tentatives [GLOBAL, NO_NFACCTD, NO_SFACCTD]
DESC:		Number of tentatives to classify a stream. Usually 5 "full" (ie. carrying payload) packets are
		sufficient to classify an uni-directional flow. This is the default value. However classifiers
		not basing on the payload content may require a different (maybe larger) number of tentatives.
DEFAULT:	5

KEY:		classifier_table_num [GLOBAL, NO_NFACCTD, NO_SFACCTD]
DESC:		The maximum number of classifiers (SO + RE) that could be loaded runtime. The default number is 
		usually ok, but some "dirty" uses of classifiers might require more entries.
DEFAULT:	256

KEY:		nfprobe_timeouts
DESC:		Allows to tune a set of timeouts to be applied over collected packets. The value is expected in
		the following form: 'name=value:name=value:...'. The set of supported timeouts and their default
		values are listed below:

		tcp	(generic tcp flow life)	3600
		tcp.rst (TCP RST flow life)	120
		tcp.fin	(TCP FIN flow life)	300
		udp	(UDP flow life)		300
		icmp	(ICMP flow life)	300
		general	(generic flow life)	3600
		maxlife	(maximum flow life)	604800
		expint	(expiry interval)	60
DEFAULT:	see above

KEY:		nfprobe_hoplimit
VALUES:		[ 1-255 ]
DESC:		Value of TTL for the newly generated NetFlow datagrams.
DEFAULT:	Operating System default

KEY:		nfprobe_maxflows
DESC:		Maximum number of flows that can be tracked simultaneously.
DEFAULT:	8192

KEY:		nfprobe_receiver
DESC:		Defines the remote IP address/hostname and port to which NetFlow dagagrams are to be exported.
		The value is expected to be in the usual form 'address:port'.
DEFAULT:	127.0.0.1:2100

KEY:            nfprobe_source_ip
DESC:           Defines the local IP address from which NetFlow dagagrams are to be exported. Only a numerical
		IPv4/IPv6 address is expected. The supplied IP address is required to be already configured on
		one of the interfaces. This parameter is also required for graceful encoding of NetFlow v9 and
		IPFIX option scoping.
DEFAULT:	IP address is selected by the Operating System

KEY:		nfprobe_version
VALUES:		[ 5, 9, 10 ]
DESC:		Version of outgoing NetFlow datagrams. NetFlow v5/v9 and IPFIX (v10) are supported. NetFlow v5
		features a fixed record structure and if not specifying an 'aggregate' directive it gets
		populated as much as possible; NetFlow v9 and IPFIX feature a dynamic template-based structure
		instead and by default it is populated as: 'src_host, dst_host, src_port, dst_Port, proto, tos'.
DEFAULT:	5

KEY:            nfprobe_engine
DESC:           Allows to define Engine ID and Engine Type fields. It applies only to NetFlow v5/v9 and IPFIX.
		In NetFlow v9/IPFIX, the supplied value fills last two bytes of SourceID field. Expects two
		non-negative numbers, up to 255 each and separated by the ":" symbol. It also allows a collector
		to distinguish between distinct probe instances running on the same box; this is also important
		for letting NetFlow v9/IPFIX templates to work correctly: in fact, template IDs get automatically
		selected only inside single daemon instances.
DEFAULT:	0:0

KEY:		[ nfacctd_peer_as | sfacctd_peer_as | nfprobe_peer_as | sfprobe_peer_as ]
VALUES:         [ true | false ]
DESC:		When applied to [ns]fprobe src_as and dst_as fields are valued with peer-AS rather than origin-AS
		as part of the NetFlow/sFlow export. Requirements to enable this feature on the probes are: a) one
		of the nfacctd_as/sfacctd_as/pmacctd_as/uacctd_as set to 'bgp' and b) a fully functional BGP
		daemon (bgp_daemon). When applied to [ns]facctd instead it uses src_as and dst_as values of the
		NetFlow/sFlow export to populate peer_src_as and peer_dst_as primitives.
DEFAULT:        false

KEY:            [ nfprobe_ipprec | sfprobe_ipprec | tee_ipprec ]
DESC:           Marks self-originated NetFlow (nfprobe) and sFlow (sfprobe) messages with the supplied IP
		precedence value.
DEFAULT:	0

KEY:            [ nfprobe_direction | sfprobe_direction ]
VALUES:		[ in, out, tag, tag2 ]
DESC:           Defines traffic direction. Can be statically defined via 'in' and 'out' keywords. It can also
		be dynamically determined via lookup to either 'tag' or 'tag2' values. Tag value of 1 will be
		mapped to 'in' direction, whereas tag value of 2 will be mapped to 'out'. The idea underlying
		tag lookups is that pre_tag_map supports, among the other features, 'filter' matching against
		a supplied tcpdump-like filter expression; doing so against L2 primitives (ie. source or
		destination MAC addresses) allows to dynamically determine traffic direction (see example at
		'examples/pretag.map.example').
DEFAULT:	none

KEY:            [ nfprobe_ifindex | sfprobe_ifindex ]
VALUES:		[ tag, tag2, <1-4294967295> ]
DESC:           Associates an interface index (ifIndex) to a given nfprobe or sfprobe plugin. This is meant as
		an add-on to [ns]probe_direction directive, ie. when multiplexing mirrored traffic from different
		sources on the same interface (ie. split by VLAN). Can be statically defined via a 32-bit integer
		or semi-dynamically determined via lookup to either 'tag' or 'tag2' values (read full elaboration
		on [ns]probe_direction directive). This definition will be also always overridden whenever the
		ifIndex can be determined dynamically (ie. via ULOG framework).
DEFAULT:	none

KEY:		sfprobe_receiver
DESC:           Defines the remote IP address/hostname and port to which sFlow dagagrams are to be exported.
		The value is expected to be in the usual form 'address:port'.
DEFAULT:	127.0.0.1:6343
		
KEY:		sfprobe_agentip
DESC:		Sets the value of agentIp field inside the sFlow datagram header.
DEFAULT:	none

KEY:		sfprobe_agentsubid
DESC:		Sets the value of agentSubId field inside the sFlow datagram header.
DEFAULT:	none

KEY:            sfprobe_ifspeed
DESC:           Statically associates an interface speed to a given sfprobe plugin. Value is expected in bps.
DEFAULT:	100000000

KEY:		bgp_daemon [GLOBAL]
VALUES:		[ true | false ]
DESC:		Enables the BGP daemon thread. Neighbors are not defined explicitely but a maximum amount
		of peers is specified (bgp_daemon_max_peers); also, for security purposes, the daemon does
		not implement outbound BGP UPDATE messages and acts passively (ie. it never establishes
		a connection to a remote peer but waits for incoming connections); upon receipt of a BGP
		OPEN message, the local daemon presents itself as belonging to the same AS number and
		supporting the same (or a subset of the) BGP capabilities as the remote peer; capabilities
		currently supported are MP-BGP, 4-bytes ASNs, ADD-PATH. Per-peer RIBs are maintained basing
		on the IP address of the peer (and for clarity not its BGP Router-ID). In case of ADD-PATH
		capability, 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.
DEFAULT:	false

KEY:		bmp_daemon [GLOBAL]
VALUES:         [ true | false ]
DESC:           Enables the BMP daemon thread. BMP, BGP Monitoring Protocol, can be used to monitor BGP
		sessions. The current implementation is based on the draft-ietf-grow-bmp-07 IETF draft.
		The BMP daemon currently supports BMP events and stats only, ie. initiation, termination, 
		peer up, peer down and stats reports messages. Route Monitoring is future (upcoming) work
		but routes can be currently sourced via the BGP daemon thread (best path only or ADD-PATH),
		making the two daemons complementary. The daemon enables to write BMP messages to files,
		AMQP and Kafka queues real-time (msglog) or at regular time intervals (dump). For further
		referece see examples in the QUICKSTART document and/or description of the bmp_* config
		keys in this document. The BMP daemon is a separate thread in the NetFlow (nfacctd) and
		sFlow (sfacctd) collectors.
DEFAULT:        false

KEY:		[ bgp_daemon_ip | bmp_daemon_ip ] [GLOBAL]
DESC:		Binds the BGP/BMP daemon to a specific interface. Expects as value an IPv4 address. For the
		BGP daemon the same is value is presented as BGP Router-ID (read more about the BGP Router-ID
		selection process at the bgp_daemon_id config directive description). Setting this directive
		is highly adviced.
DEFAULT:	0.0.0.0

KEY:            bgp_daemon_id [GLOBAL]
DESC:		Defines the BGP Router-ID to the supplied value. Expected value is an IPv4 address. If this
		feature is not used or an invalid IP address is supplied, ie. IPv6, the bgp_daemon_ip value
		is used instead. If also bgp_daemon_ip is not defined or invalid, the BGP Router-ID defaults
		to "1.2.3.4".
DEFAULT:	1.2.3.4

KEY:		[ bgp_daemon_port | bmp_daemon_port ] [GLOBAL] 
DESC:		Binds the BGP/BMP daemon to a port different from the standard port. Default port for BGP is
		179/tcp; default port for BMP is 1790.
DEFAULT:	bgp_daemon_port: 179; bmp_daemon_port: 1790

KEY:		[ bgp_daemon_ipprec | bmp_daemon_ipprec ] [GLOBAL]
DESC:		Marks self-originated BGP/BMP messages with the supplied IP precedence value.
DEFAULT:	0

KEY:		[ bgp_daemon_max_peers | bmp_daemon_max_peers ] [GLOBAL]
DESC:		Sets the maximum number of neighbors the BGP/BMP daemon can peer to. Upon reaching of the
		limit, no more BGP/BMP sessions can be established. BGP/BMP neighbors don't need to be
		defined explicitely one-by-one rather an upper boundary to the number of neighbors applies.
		pmacctd, uacctd daemons are limited to only two BGP peers (in a primary/backup fashion, see
		bgp_agent_map); such hardcoded limit is imposed as the only scenarios supported in conjunction
		with the BGP daemon are as NetFlow/sFlow probes on-board software routers and firewalls.
DEFAULT:	10

KEY:		[ bgp_daemon_batch_interval | bmp_daemon_batch_interval ] [GLOBAL]
DESC:		To prevent all BGP/BMP peers contend resources, this defines the time interval, in seconds,
		between any two BGP/BMP peer batches. The first peer in a batch sets the base time, that is
		the time from which the interval is calculated, for that batch.
DEFAULT:	0

KEY:		[ bgp_daemon_batch | bmp_daemon_batch ] [GLOBAL]
DESC:		To prevent all BGP/BMP peers to contend resources, this defines the number of BGP peers in
		each batch. If a BGP/BMP peer is not allowed by an ACL (ie. bgp_daemon_allow_file), room is
		recovered in the current batch; if a BGP/BMP peer in a batch is replenished (ie. connection
		drops, is reset, etc.) no new room is made in the current batch (rationale being: be a bit
		conservative, batch might have been set too big, let's try to limit flapping).
DEFAULT: 	0

KEY:            [ bgp_daemon_msglog_file | bmp_daemon_msglog_file ] [GLOBAL]
DESC:		Enables streamed logging of BGP/BMP messages/events. Each log entry features a time reference,
		BGP/BMP peer IP address, event type and a sequence number (to order events when time reference
		is not granular enough). BGP UPDATE messages also contain full prefix and BGP attributes
		information. The list of supported filename variables follows:

                $peer_src_ip    BGP/BMP peer IP address.

		Files can be re-opened by sending a SIGHUP to the daemon core process.
DEFAULT:	none

KEY:		[ bgp_daemon_msglog_output | bmp_daemon_msglog_output ] [GLOBAL]
VALUES:         [ json ]
DESC:		Defines output format for the streamed logging of BGP/BMP messages/events. Only JSON format
		is currently supported and requires compiling against Jansson library (--enable-jansson when
		configuring for compiling).
DEFAULT:	json

KEY:		bgp_aspath_radius [GLOBAL]
DESC:		Cuts down AS-PATHs to the specified number of ASN hops. If the same ASN is repeated multiple
		times (ie. as effect of prepending), each of them is regarded as one hop. By default AS-PATHs
		are left intact unless reaching the maximum length of the buffer (128 chars). 
DEFAULT:	none

KEY:		[ bgp_stdcomm_pattern | bgp_extcomm_pattern ] [GLOBAL]
DESC:		Filters BGP standard/extended communities against the supplied pattern. The underlying idea
		is that many communities can be attached to a prefix; some of these can be of little or no
		interest for the accounting task; this feature allows to select only the relevant ones. By
		default the list of communities is left intact until reaching maximum length of the buffer
		(96 chars). The filter does substring matching, ie. 12345:64 will match communities in the
		ranges 64-64, 640-649, 6400-6499 and 64000-64999. The '.' symbol can be used to wildcard a
		pre-defined number of characters, ie. 12345:64... will match community values in the range
		64000-64999 only. Multiple patterns can be supplied comma-separated.
DEFAULT:	none

KEY:            [ bgp_stdcomm_pattern_to_asn ] [GLOBAL]
DESC:           Filters BGP standard communities against the supplied pattern. The algorithm employed is
		the same as for the bgp_stdcomm_pattern directive: read implementation details there. The
		first matching community is taken and split using the ':' symbol as delimiter. The first
		part is mapped onto the peer AS field while the second is mapped onto the origin AS field.
		The aim of this directive is to deal with IP prefixes on the own address space, ie. statics
		or connected redistributed in BGP. Example: BGP standard community XXXXX:YYYYY is mapped as:
		Peer-AS=XXXXX, Origin-AS=YYYYY. Multiple patterns can be supplied comma-separated.
DEFAULT:	none

KEY:		bgp_peer_as_skip_subas [GLOBAL]
VALUES:		[ true | false ]
DESC:		When determining the peer AS (source and destination), skip potential confederated sub-AS
		and report the first ASN external to the routing domain. When enabled if no external ASNs
		are found on the AS-PATH except the confederated sub-ASes, the first sub-AS is reported.
DEFAULT:        false

KEY:		bgp_peer_src_as_type [GLOBAL]
VALUES:		[ netflow | sflow | map | bgp ]
DESC:		Defines the method to use to map incoming traffic to a source peer ASN. "map" selects a
		map, reloadable at runtime, specified by the bgp_peer_src_as_map directive (refer to it for
		further information); "bgp" implements native BGP RIB lookups. BGP lookups assume traffic is
		symmetric, which is often not the case, affecting their accuracy.
DEFAULT:	netflow, sflow

KEY:		bgp_peer_src_as_map [GLOBAL, MAP]
DESC:		Full pathname to a file containing source peer AS mappings. The AS can be mapped to one or
		a combination of: ifIndex, source MAC address and BGP next-hop (query against the BGP RIB
		to look up the source IP prefix). This is sufficient to model popular tecniques for both
		public and private BGP peerings. Number of map entries (by default 384) can be modified via 
		maps_entries. Sample map in 'examples/peers.map.example'.
DEFAULT:	none

KEY:            bgp_src_std_comm_type [GLOBAL]
VALUES:         [ bgp ]
DESC:		Defines the method to use to map incoming traffic to a set of standard communities. Only
		native BGP RIB lookups are currently supported. BGP lookups assume traffic is symmetric,
		which is often not the case, affecting their accuracy.
DEFAULT:	none

KEY:            bgp_src_ext_comm_type [GLOBAL]
VALUES:         [ bgp ]
DESC:           Defines the method to use to map incoming traffic to a set of extended communities. Only
                native BGP RIB lookups are currently supported. BGP lookups assume traffic is symmetric,
                which is often not the case, affecting their accuracy.
DEFAULT:	none

KEY:            bgp_src_as_path_type [GLOBAL]
VALUES:         [ bgp ]
DESC:           Defines the method to use to map incoming traffic to an AS-PATH. Only native BGP RIB lookups
		are currently supported. BGP lookups assume traffic is symmetric, which is often not the
		case, affecting their accuracy.
DEFAULT:	none

KEY:            bgp_src_local_pref_type [GLOBAL]
VALUES:         [ map | bgp ]
DESC:           Defines the method to use to map incoming traffic to a local preference. Only native BGP
		RIB lookups are currently supported. BGP lookups assume traffic is symmetric, which is
		often not the case, affecting their accuracy.
DEFAULT:	none

KEY:            bgp_src_local_pref_map [GLOBAL, MAP]
DESC:           Full pathname to a file containing source local preference mappings. The LP value can be
		mapped to one or a combination of: ifIndex, source MAC address and BGP next-hop (query
		against the BGP RIB to look up the source IP prefix). Number of map entries (by default
		384) can be modified via maps_entries. Sample map in 'examples/lpref.map.example'.
DEFAULT:	none

KEY:            bgp_src_med_type [GLOBAL]
VALUES:         [ map | bgp ]
DESC:           Defines the method to use to map incoming traffic to a MED value. Only native BGP RIB
                lookups are currently supported. BGP lookups assume traffic is symmetric, which is often
		not the case, affecting their accuracy.
DEFAULT:	none

KEY:            bgp_src_med_map [GLOBAL, MAP]
DESC:           Full pathname to a file containing source MED (Multi Exit Discriminator) mappings. The
		MED value can be mapped to one or a combination of: ifIndex, source MAC address and BGP
		next-hop (query against the BGP RIB to look up the source IP prefix). Number of map
		entries (by default 384) can be modified via maps_entries. Sample map in 'examples/
		med.map.example'.
DEFAULT:	none

KEY:		bgp_agent_map [GLOBAL, MAP]
DESC:		Full pathname to a file to map source IP address of NetFlow agents and AgentID of sFlow
		agents to source IP address or Router ID of BGP peers. This is to provide flexibility
		in a number of scenarios, for example and not limited to BGP peering with RRs, hub-and-
		spoke topologies, single-homed networks - but also BGP sessions traversing NAT. pmacctd,
		uacctd daemons are required to use a bgp_agent_map with up to two "catch-all" entries -
		working in a primary/backup fashion (see agent_to_peer.map in the examples section):
		this is because these daemons do not have a NetFlow/sFlow source address to match to.
		Number of map entries (by default 384) can be modified via maps_entries.
DEFAULT:	none

KEY:		flow_to_rd_map [GLOBAL, MAP]
DESC:		Full pathname to a file to map flows (typically, a) ingress router, input interfaces or
		b) MPLS bottom label, BGP next-hop couples) to BGP/MPLS Virtual Private Network (VPN)
		Route Distinguisher (RD), based upon rfc4659. See flow_to_rd.map file in the examples
		section for further info. Number of map entries (by default 384) can be modified via
		maps_entries. 
DEFAULT:	none

KEY:		bgp_follow_default [GLOBAL]
DESC:		Expects positive number value which instructs how many times a default route, if any, can
		be followed in order to successfully resolve source and destination IP prefixes. This is
		aimed at scenarios where neighbors peering with pmacct have a default-only or partial BGP
		view. At each recursion (default route follow-up) the value gets decremented; the process
		stops when one of these conditions is met:

		* both source and destination IP prefixes are resolved
		* there is no available default route
		* the default gateway is not BGP peering with pmacct
		* the the recusion value reaches zero

		As soon as an IP prefix is matched, it is not looked up anymore in case more recursions
		are required (ie. the closer the router is, the most specific the route is assumed to be).
		pmacctd, uacctd daemons are internally limited to only two BGP peers hence this feature
		can't properly work.
DEFAULT:	0

KEY:            bgp_follow_nexthop [GLOBAL]
DESC:		Expects one or more IP prefix(es), ie. 192.168.0.0/16, comma separated. A maximum of 32
		IP prefixes is supported. It follows the BGP next-hop up (using each next-hop as BGP
		source-address for the next BGP RIB lookup), returning the last next-hop part of the
		supplied IP prefix as value for the 'peer_ip_dst' primitive. bgp_agent_map is supported
		at each recursion. This feature is aimed at networks, for example, involving BGP
		confederations; underlying goal being to see the routing-domain "exit-point". The
		The feature is internally protected against routing loops with an hardcoded limit of 20
		lookups; pmacctd, uacctd daemons are internally limited to only two BGP peers hence this
		feature can't properly work.
DEFAULT:	none

KEY:            bgp_neighbors_file [GLOBAL]
DESC:		Writes a list of the BGP neighbors in the established state to the specified file, one
		per line. This gets particularly useful for automation purposes (ie. auto-discovery of
		devices to poll via SNMP).
DEFAULT:	none

KEY:            [ bgp_daemon_allow_file | bmp_daemon_allow_file ] [GLOBAL]
DESC:           Full pathname to a file containing the list of IP addresses (one for each line) allowed
                to establish a BGP/BMP session. Current syntax does not implement network masks but only
		individual IP addresses.
DEFAULT:	none (ie. allow all)

KEY:            bgp_daemon_md5_file [GLOBAL]
DESC:           Full pathname to a file containing the BGP peers (IP address only, one for each line)
		and their corresponding MD5 passwords in CSV format (ie. 10.15.0.1, arealsmartpwd).
		BGP peers not making use of a MD5 password should not be listed. The maximum number
		of peers supported is 8192. For a sample map look in: 'examples/bgp_md5.lst.example'
		The feature was tested working against a 2.6.32 Linux kernel.
DEFAULT:	none

KEY:		bgp_table_peer_buckets [GLOBAL]
VALUES:		[ 1-1000 ]
DESC:		Routing information related to BGP prefixes is kept per-peer in order to simulate a
		multi-RIB environment and is internally structured as an hash with conflict chains.
		This parameter sets the number of buckets of such hash structure; the value is directly
		related to the number of expected BGP peers, should never exceed such amount and: a) if
		only best-path is received this is best set to 1/10 of the expected peers; b) if BGP
		ADD-PATHs is received this is best set to 1/1 of the expected peers. The default value
		proved to work fine up to aprox 100 BGP peers sending best-path only, in lab. More
		buckets means better CPU usage but also increased memory footprint - and vice-versa.
DEFAULT:	13

KEY:		bgp_table_per_peer_buckets [GLOBAL]
VALUE:		[ 1-128 ]
DESC:		With same background information as bgp_table_peer_buckets, this parameter sets the
		number of buckets over which per-peer information is distributed (hence effectively
		creating a second dimension on top of bgp_table_peer_buckets, useful when much BGP
		information per peer is received, ie. in case of BGP ADD-PATHs). Default proved to
		work fine if BGP sessions are passing best-path only. In case of BGP ADD-PATHs it is
		instead recommended to set this value to 1/3 of the configured maximum number of
		paths per prefix to be exported.
DEFAULT:	1

KEY:            bgp_table_attr_hash_buckets [GLOBAL]
VALUE:          [ 1-1000000 ]
DESC:		Sets the number of buckets of BGP attributes hashes (ie. AS-PATH, communities, etc.).
		Default proved to work fine with BGP sessions passing best-path only and with up to
		25 BGP sessions passing ADD-PATH.
DEFAULT:	65535

KEY:            bgp_table_per_peer_hash [GLOBAL]
VALUE:          [ path_id ]
DESC:		If bgp_table_per_peer_buckets is greater than 1, this parameter allows to set the
		hashing to be used. By default hashing happens against the BGP ADD-PATH path_id field.
		Hashing over other fields or field combinations (hashing over BGP next-hop is on the
		radar) are planned to be supported in future.
DEFAULT:	path_id

KEY:            [ bgp_table_dump_file | bmp_dump_file ] [GLOBAL] 
DESC:           Enables dump of BGP tables/BMP events at regular time intervals (as defined by, for
		example, bgp_table_dump_refresh_time) into files. Each dump event features a time
		reference and BGP/BMP peer IP address along with the rest of BGP/BMP info. The list
		of supported filename variables follows:

                %d              The day of the month as a decimal number (range 01 to 31).

                %H              The hour as a decimal number using a 24 hour clock (range 00 to 23).

                %m              The month as a decimal number (range 01 to 12).

                %M              The minute as a decimal number (range 00 to 59).

                %s              The number of seconds since Epoch, ie., since 1970-01-01 00:00:00 UTC.

                %w              The day of the week as a decimal, range 0 to 6, Sunday being 0.

                %W              The week number of the current year as a decimal number, range
                                00 to 53,  starting  with the first Monday as the first day of
                                week 01.

                %Y              The year as a decimal number including the century.

                $peer_src_ip    BGP peer IP address.
DEFAULT:	none

KEY:            [ bgp_table_dump_output | bmp_dump_output ] [GLOBAL]
VALUES:         [ json ]
DESC:           Defines output format for the dump of BGP/BMP tables. Only JSON format is currently
		supported and requires compiling against Jansson library (--enable-jansson when
		configuring for compiling).
DEFAULT:	json

KEY:		[ bgp_table_dump_refresh_time | bmp_dump_refresh_time ] [GLOBAL]
VALUES:		[ 60 .. 86400 ]
DESC:		Time interval, in seconds, between two consecutive executions of the dump of BGP/BMP
		tables to files.
DEFAULT:	0

KEY:            [ bgp_table_dump_latest_file | bmp_dump_latest_file ] [GLOBAL]
DESC:           Defines the full pathname to pointer(s) to latest file(s). Dynamic names are supported
                through the use of variables, which are computed at the moment when data is purged to the
                backend: refer to bgp_table_dump_file for a full listing of supported variables; time-
		based variables are not allowed. Update of the latest pointer is done evaluating files
		modification time. See print_latest_file for examples.
DEFAULT:        none

KEY:		isis_daemon [GLOBAL]
VALUES:		[ true | false ]
DESC:		Enables the skinny IS-IS daemon thread. This feature requires the package to be supporting
		multi-threading (--enable-threads). It implements P2P Hellos, CSNP and PSNP - and does not
		send any LSP information out. It currently supports a single L2 P2P neighborship. Testing
		has been done over a GRE tunnel.
DEFAULT:        false

KEY:		isis_daemon_ip [GLOBAL]
DESC:		Sets the sub-TLV of the Extended IS Reachability TLV that contains an IPv4 address for the
		local end of a link. No default value is set and a non-zero value is mandatory. It should
		be set to the IPv4 address configured on the interface pointed by isis_daemon_iface. 
DEFAULT:	none

KEY:		isis_daemon_net [GLOBAL]
DESC:		Defines the Network entity title (NET) of the IS-IS daemon. In turn a NET defines the area
		addresses for the IS-IS area and the system ID of the router. No default value is set and
		a non-zero value is mandatory. Extensive IS-IS and ISO literature cover the topic, example
		of the NET value format can be found as part of the "Quickstart guide to setup the IS-IS
		daemon" in the QUICKSTART document.
DEFAULT:	none

KEY:		isis_daemon_iface [GLOBAL]
DESC:		Defines the network interface (ie. gre1) where to bind the IS-IS daemon. No default value
		is set and a non-zero value is mandatory.
DEFAULT:	none

KEY:		isis_daemon_mtu [GLOBAL]
DESC:		Defines the available MTU for the IS-IS daemon. P2P HELLOs will be padded to such length.
		When the daemon is configured to set a neighborship with a Cisco router running IOS, this
		value should match the value of the "clns mtu" IOS directive.
DEFAUT:		1476

KEY:		isis_daemon_msglog [GLOBAL]
VALUES:		[ true | false ]
DESC:	 	Enables IS-IS messages logging: as this can get easily verbose, it is intended for debug
		and troubleshooting purposes only.
DEFAULT:        false

KEY:		[ geoip_ipv4_file | geoip_ipv6_file ] [GLOBAL]
DESC:		If pmacct is compiled with --enable-geoip, this defines full pathname to the Maxmind GeoIP
		Country v1 ( http://dev.maxmind.com/geoip/legacy/install/country/ ) IPv4/IPv6 databases
		to use. pmacct, leveraging the Maxmind API, will detect if the file is updated and reload
		it. The use of --enable-geoip is mutually exclusive with --enable-geoipv2. 
DEFAULT:	none

KEY:            geoipv2_file [GLOBAL]
DESC:           If pmacct is compiled with --enable-geoipv2, this defines full pathname to a Maxmind GeoIP
		database v2 (libmaxminddb, ie. https://dev.maxmind.com/geoip/geoip2/geolite2/ ). Only the
		binary database format is supported (ie. it is not possible to load distinct CSVs for IPv4
		and IPv6 addresses). The use of --enable-geoip is mutually exclusive with --enable-geoipv2. 
		Files can be reloaded at runtime by sending the daemon a SIGUSR signal (ie. "killall -USR2
		nfacctd").

KEY:		uacctd_group [GLOBAL, UACCTD_ONLY]
DESC:		Sets the Linux Netlink ULOG multicast group to be joined.
DEFAULT:	1

KEY:		uacctd_nl_size [GLOBAL, UACCTD_ONLY]
DESC:		Sets ULOG Netlink internal buffer size (specified in bytes). It is 4KB by default, but to
		safely record bursts of high-speed traffic, it could be further increased. For high loads,
		values as large as 2MB are recommended. When modifying this value, it is also recommended
		to reflect the change to the 'snaplen' option.
DEFAULT:	4096

KEY:		tunnel_0 [GLOBAL, NO_NFACCTD, NO_SFACCTD]
DESC:		Defines tunnel inspection, disabled by default. The daemon will then account on tunnelled
		data rather than on the envelope. The implementation approach is stateless, ie. control
		messages are not handled. Up to 4 tunnel layers are supported (ie. <tun proto>, <options>;
		<tun proto>, <options>; ...). Up to 8 tunnel stacks will be supported (ie. configuration
		directives tunnel_0 .. tunnel_8), to be used in a strictly sequential order. First stack
		matched at the first layering, wins. Below tunnel protocols supported and related options:

		GTP, GPRS tunnelling protocol. Expects as option the UDP port identifying the protocol. 
		tunnel_0: gtp, <UDP port> 
DEFAULT:	none

KEY:		tee_receiver 
DESC:           Defines remote IP address and port to which NetFlow/sFlow dagagrams are to be replicated
		to. The value is expected to be in the usual form 'address:port'. Either tee_receiver key
		(legacy) or tee_receivers is mandatory for a 'tee' plugin instance.
DEFAULT:	none

KEY:            tee_receivers [MAP]
DESC:           Defines full pathname to a list of remote IP addresses and ports to which NetFlow/sFlow
		dagagrams are to be replicated to. Examples are available in "examples/tee_receivers.lst.
		example" file. Either tee_receiver key (legacy) or tee_receivers is mandatory for a 'tee'
		plugin instance.
DEFAULT:	none

KEY:		tee_source_ip
DESC:           Defines the local IP address from which NetFlow/sFlow dagagrams are to be replicate from.
		Only a numerical IPv4/IPv6 address is expected. The supplied IP address is required to be
		already configured on one of the interfaces. Value is ignored when transparent replication
		is enabled.
DEFAULT:	IP address is selected by the Operating System

KEY:		tee_transparent
VALUES:         [ true | false ]
DESC:		Enables transparent replication mode. It essentially spoofs the source IP address to the
		original sender of the datagram. It requires super-user permissions.
DEFAULT:        false

KEY:            tee_max_receiver_pools
DESC:           Tee receivers list is organized in pools (for present and future features that require
		grouping) of receivers. This directive defines the amount of pools to be allocated and
		cannot be changed at runtime.
DEFAULT:	128

KEY:            tee_max_receivers
DESC:           Tee receivers list is organized in pools (for present and future features that require
                grouping) of receivers. This directive defines the amount of receivers per pool to be
		allocated and cannot be changed at runtime.
DEFAULT:	32

KEY:		pkt_len_distrib_bins
DESC:		Defines a list of packet length distributions, comma-separated, which is then used to
		populate values for the 'pkt_len_ditrib' aggregation primitive. Values can be ranges or
		exact, ie. "0-499,500-999,1000-1499,1500-9000". The maximum amount of bins that can be
		defined is 255; packet lengths must be in the range 0-9000; if a length is part of more
		than a single bin the latest definition wins. 
DEFAULT:        none

KEY:		tmp_net_own_field
VALUES:         [ true | false ]
DESC:		Writes IP prefixes, src_net and dst_net primitives, to a own/distinct field than the
		one used for IP addresses, src_host and dst_host primitives. This config directive is
		meant for pmacct 1.5 only in order to save, default setting, backward compatibility.
		With the next major release this feature will become default behaviour.
DEFAULT:        false

KEY:		thread_stack
DESC:		Defines the stack size for threads screated by the daemon. The value is expected in
		bytes. A value of 0, default, leaves the stack size to the Operating System default.
DEFAULT:	0
