CONFIG-KEYS

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' (it's likely it will not apply to 'uacctd' either)
NO_UACCTD	Does not apply to 'uacctd' 
NO_NFACCTD	Does not apply to 'nfacctd' (it's likely it will not apply to 'sfacctd' either) 
NO_SFACCTD	Does not apply to 'sfacctd' 


LIST OF DIRECTIVES:

KEY: 		debug (-d)
VALUES:		[ true | false ]
DESC:		enables 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, 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 ]
FOREWORDS:	individual IP packets are uniquely identified by their header fields 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 a custom and stripped down set of
		primitives.
		The procedure to create an aggregate starting from IP packets or flow 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 bytes/flows/packets counters whenever a new constituent 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 join together both inbound and
		outbound traffic into a single aggregate. The 'none' primitive allows to make
		an unique aggregate which accounts for the grand total of traffic flowing
		through a specific interface. 'tag' and 'tag2' enable generation of tags when
		tagging engines (pre_tag_map, post_tag) are in use. 'class' enables reception
		of L7 traffic classes when Packet/Flow Classification engine (classifiers) is
		in use. (default: src_host).
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 is enabled this field will report
		  a value of 1; otherwise it will report the rate pmacct would have applied if
		  renormalize counters was enabled.  
		* 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).
		* timestamp_start and timestamp_end should not be mixed with pmacct support
		  for historical accounting, ie. breakdown of traffic in time-bins via the
		  sql_history feature; the two 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 the likes of libpcap packet timestamp, sFlow sample
		  arrival time, NetFlow/IPFIX observation time and flow first switched time;
		  timestamp_end currently only makes sense for logging flows via NetFlow and
		  IPFIX. 

KEY:		aggregate_primitives [GLOBAL]
DESC:		Expects full pathname to a file containing custom-defined primitives. Once
		properly defined in this file (see 'examples/primitives.lst' for full syntax),
		primitives can be used in 'aggregate' statements. The feature is currently
		available only in nfacctd, for NetFlow v9/IPFIX, pmacctd and uacctd. IPFIX
		variable-length fields, for example strings, are currently supported only by
		defining a length equal to the maximum estimated length of the field. 

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.

KEY:		pcap_filter (like tcpdump syntax) [GLOBAL, NO_NFACCTD]
DESC:		this filter is global and applied to all incoming packets. It's passed to libpcap
		and, indeed, 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.

KEY:		snaplen (-L) [GLOBAL, NO_NFACCTD]
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.

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 ]
DESC:		Defines the size of the kernel socket used read traffic data. 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.

KEY:            bgp_daemon_pipe_size
DESC:           Defines the size of the kernel socket used for BGP messaging. 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.

KEY:		plugin_pipe_size
DESC:		Core process and each of the plugins are run into different processes. To exchange
		data, they set up a communication channel structured as a circular queue (referred
		as pipe). 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 store more data. In the following example the pipe between the Core process and
		the plugin 'test' is set to 10MB, whereas the receiving socket of the Core process
		is set to 2MB:

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

		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/rmem_default ; the maximum configurable socket size
		(which can be changed via sysctl) is defined in /proc/sys/net/core/rmem_max instead.
		(default: 4MB)

KEY:		plugin_buffer_size 
DESC:		by defining the transfer buffer size, in bytes, this directive enables bufferization
		of data transfers between core process and active plugins. It is disabled by default,
		ie. size of a buffer coincides to the size of a single element to be transferred,
		giving best feelings while testing out the package with small traffic loads. 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 'plugin_pipe_size'
		circular queue is hence partitioned in plugin_buffer_size/plugin_pipe_size slots.
		Once a slot is filled, it is delivered to the plugin while the circular queue moves
		to the next buffer element. (default: 0) 

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:		files_umask 
DESC:		Defines the mask for newly created files (log, pid, etc.). A mask less than "002" is
		currently 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. 

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.

KEY:		interface (-i) [GLOBAL, NO_NFACCTD]
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). 

KEY:		pcap_savefile (-I) [GLOBAL, NO_NFACCTD]
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). 

KEY:		interface_wait (-w) [GLOBAL, NO_NFACCTD]
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, NO_NFACCTD]
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, NO_NFACCTD]
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. 

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

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_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).

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.

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.

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
		default: '/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.

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:		It 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

		For correct working of the feature, responsibility is put on the user. A file is reckon
		as latest if it's 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. 

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

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 (default: 1)

KEY:		sql_table_type 
VALUES		[ bgp ]
DESC:		optionally combined with "sql_table_version", defines one of the supported SQL table
		profiles. Currently this directive has to be defined to select one of the default BGP
		table profiles.

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 | amqp_host ]
DESC:		defines the backend server IP/hostname (default: localhost).

KEY:		[ sql_user | mongo_user | amqp_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 | amqp_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 ] (-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.

KEY:		sql_startup_delay
DESC:		defines the time, in seconds, the first SQL 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 'sql_refresh_time' value, allowing them to spread
		the writes among the length of the time-bin; b) with NetFlow, 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 ]
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).

KEY:            [ sql_history_offset | print_history_offset | mongo_history_offset | amqp_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 ]
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. 

KEY:            sql_history_since_epoch
VALUES          [ true | false ]
DESC:		enables the use of timestamps (stamp_inserted, stamp_updated) in the standard seconds since
		the Epoch format. This directive requires changes to the default types for timestamp fields
		in the SQL schema. (default: false)

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

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. 

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.

KEY:            [ sql_max_writers | print_max_writers | mongo_max_writers | amqp_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 ]
DESC:		SQL and other plugins sport a Plugin Memory Cache (PMC) meant to accumulate bytes/packets
		counters until next purging event (for further insights take a look to 'sql_refresh_time'). 
		This directive sets the number of PMC buckets. Default value is suitable for most common
		scenarios, however when facing large-scale networks, it's higly recommended to carefully
		tune this parameter to improve performances. Use a prime number of buckets.
		(default: sql_cache_entries: 32771, print_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. (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:		sql_multi_values
DESC:		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). (default: none) 

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.

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

KEY:		sql_preprocess
DESC:		allows to process aggregates (via a comma-separated list of conditionals and checks) while
		purging data to the RDBMS thus resulting in a powerful selection tier; aggregates filtered
		out may be just discarded or saved through the recovery mechanism (if enabled). 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. 

		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. 

		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.

		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.

		      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.

		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.

		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. 

		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.

		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.

		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.

		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.

		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

		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 

		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.

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

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

KEY:		sql_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 primitives) resolution to seconds, ie. prevents
		timestamp_start_residual, timestamp_end_residual fields to be populated (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:		amqp_exchange
DESC:		Name of the AMQP exchange to publish data (default: pmacct).

KEY:		amqp_exchange_type
DESC:		Type of the AMQP exchange to publish data. Currently only 'direct' and 'fanout' types are
		supported. (default: direct).

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 supported variables follows (default: acct): 

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

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.".
		
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. 'json' is to enable
		JavaScript Object Notation format, also suitable for injection into 3rd party tools and having
		the extra benefit over 'csv' format of not requiring an 'event' version of the output ('json'
		not requiring a table title). 'event' versions of the output strip trailing bytes and packets
		counters. 'json' format requires compiling the package against Jansson library (downloadable at
		the following URL: http://www.digip.org/jansson/) (default: formatted)
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). 

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 ]
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_NTOA()
		function is defined in the RDBMS (which for MySQL is always the case, while for SQLite it is not
		by default). Since INET_NTOA() is used, unless redefined to some custom-made variant, this feature
		works for IPv4 addresses only. The feature is also not compatible with making use of IP prefix
		labels. Default setting is to convert IP addresses into strings. (default: false)

KEY:		[ nfacctd_port | sfacctd_port ] (-l) [GLOBAL, NO_PMACCTD]
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]
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: "defaut")

KEY:		[ nfacctd_allow_file | sfacctd_allow_file ] [GLOBAL, NO_PMACCTD]
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: allow all) 

KEY:		nfacctd_time_secs [GLOBAL, NO_PMACCTD]
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, NO_PMACCTD]
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 [ NO_PMACCTD]
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. (default: false)
NOTES:          If NetFlow sampling is enabled, it is recommended to have counters renormalization enabled
                (nfacctd_renormalize set to true).

KEY:		[ nfacctd_as_new | sfacctd_as_new | pmacctd_as | uacctd_as ] [GLOBAL]
VALUES:		[ false | (true|file) | bgp | fallback ]
DESC:		When 'false', it instructs nfacctd and sfacctd to populate 'src_as', 'dst_as', 'peer_src_as' and
		'peer_dst_as' primitives from NetFlow and sFlow datagram respectively; when 'true' ('file' being
		an alias of 'true') it instructs nfacctd and sfacctd to generate 'src_as' and 'dst_as' (only! ie.
		no peer-AS) by looking up source and destination IP addresses against a networks_file. When 'bgp'
		is specified, ASNs are looked up against the BGP RIB of the peer from which the NetFlow datagram
		was received (see also bgp_agent_map directive). When 'fallback' is specified, lookup is done
		against the winning longest match lookup method (sFlow/NetFlow <= BGP), which can be different
		for source and destination IP prefix. Intuitively if 'fallback' is specified, IS-IS/IGP daemon
		is enabled and IGP is the winning method then no BGP information will be attached to the prefixes.
		In pmacctd and uacctd 'false' (maintained for backward compatibility), 'true' and 'file' expect a
		'networks_file' to be defined; 'bgp' just works as described previously for nfacctd and sfacctd;
		'fallback' is mapped to 'bgp' since no export protocol lookup method is available. (default: false)

KEY:            [ nfacctd_net | sfacctd_net | pmacctd_net | uacctd_net ]
VALUES:         [ netflow | sflow | mask | file | igp | bgp | fallback ]
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. Default behaviour under pmacctd
		and uacctd is for backward compatibility: 'mask' and 'file' are turned on if a networks_mask and
		a networks_file are respectively specified by configuration. If they both are defined, the outcome
		will be the intersection of their definitions. 'fallback' behaves in a longest-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).
		(default: nfacctd: 'netflow'; sfacctd: 'sflow'; pmacctd and uacctd: 'mask', 'file')

KEY:		use_ip_next_hop
VALUES:		[ true | false ] 
DESC:		When IP prefix aggregation (ie. nfacctd_net) is set to 'netflow', 'sflow' or 'fallback' (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]
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). 

KEY:            [ nfacctd_disable_checks | sfacctd_disable_checks ] [GLOBAL, NO_PMACCTD]
VALUES:         [ true | false ]
DESC:           both nfacctd and sfacctd check health of incoming NetFlow/sFlow datagrams - actually this is
		limited to just verifying sequence numbers progression. You may want to disable such feature
		because of non-standard implementations. By default checks are enabled (default: false)

KEY:		pre_tag_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' and/or
		'tag2' 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.  

KEY:		maps_entries
DESC:		defines the maximum number of entries a map (ie. pre_tag_map) 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) 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 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 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_id,
		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:		it 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'.

KEY:            [ post_tag | post_tag2 ] 
VALUES:         [ 1-2^64-1 ]
DESC:           it 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.

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: no sampling)

KEY:            sampling_map [GLOBAL, NO_PMACCTD, NO_UACCTD]
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.

KEY:		[ pmacctd_force_frag_handling | uacctd_force_frag_handling ] [GLOBAL, NO_NFACCTD]
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]
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: 4 Mb). 

KEY:            [ pmacctd_flow_buffer_size | uacctd_flow_buffer_size ] [GLOBAL, NO_NFACCTD]
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. It is expected in bytes (default:
		16 Mb).

KEY:            [ pmacctd_flow_buffer_buckets | uacctd_flow_buffer_buckets ] [GLOBAL, NO_NFACCTD] 
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]
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: 8 Mb).

KEY:            [ pmacctd_flow_lifetime | uacctd_flow_lifetime ] [GLOBAL, NO_NFACCTD]
DESC:           defines how long a 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) 

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: no sampling) 

KEY:		[ sfacctd_renormalize | nfacctd_renormalize | pmacctd_renormalize | uacctd_renormalize ] (-R)
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:		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. 

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
DESC:		defines the locking style for the SQL table. Supported values are: "table", the plugin will
		lock the entire table when writing data to the DB. It serializes 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. The user
		need to take cares on his own; a simple and safe enough protection can be tagging uniquely
		data coming from each plugin (see pre_tag_map, post_tag). In MySQL the use of an InnoDB table
		is mandatory. This config directive currently applies only to PostgreSQL and MySQL plugins.
		(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

KEY:		nfprobe_hoplimit
VALUES:		[ 1-255 ]
DESC:		value of TTL for the newly generated NetFlow datagrams. (default: 0, leave default OS settings) 

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 OS)

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_new/sfacctd_as_new/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 ]
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).

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.

KEY:		sfprobe_agentsubid
DESC:		sets the value of agentSubId field inside the sFlow datagram header.

KEY:            sfprobe_ifspeed
DESC:           statically associates an interface speed to a given sfprobe plugin. (default: 100000000)

KEY:		bgp_daemon
VALUES:		[ true | false ]
DESC:		enables the skinny BGP daemon thread. This feature requires the package to be supporting multi-
		threading (--enable-threads). Neighbors are not defined explicitely via a piece of configuration
		(see bgp_daemon_max_peers directive); also, for security purposes, the daemon doesn't 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:		bgp_daemon_ip
DESC:		binds the BGP daemon to a specific interface. Expects as value an IPv4 address. The same is
		used as BGP Router-ID to its peers - otherwise a dumb "1.2.3.4" value is presented. Setting
		this directive is highly adviced. (default: 0.0.0.0)

KEY:		bgp_daemon_port
DESC:		binds the BGP daemon to a port different from the standard BGP port: 179/tcp. (default: 179)

KEY:		bgp_daemon_ipprec
DESC:		marks self-originated BGP messages with the supplied IP precedence value. (default: 0)

KEY:		bgp_daemon_max_peers
DESC:		sets the maximum number of neighbors the BGP daemon can peer to. Upon reaching of the limit,
		no more BGP sessions can be established. Differently from routers BGP 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_msglog
VALUES:		[ true | false ]
DESC:		enables BGP messages logging: as this can get easily verbose, it is intended for debug and
		troubleshooting purposes only. (default: false)

KEY:		bgp_daemon_batch_interval
DESC:		To prevent all BGP peers to contend resources, this defines the time interval, in seconds,
		between any two BGP 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. If bgp_daemon_init_interval or
		bgp_daemon_init_batch is set to zero, default, initial BGP peer batching is disabled.
		(default: 0)

KEY:		bgp_daemon_batch
DESC:		To prevent all BGP peers to contend resources, this defines the amount of BGP peers in each
		batch. If a BGP peer in a batch is replenished (ie. connection drops, is reset, etc.) no
		new room is made in the current batch (rationale being: be conservative, batch might have
		been set too big, let's now potentially induce flapping). If bgp_daemon_init_interval or
		bgp_daemon_init_batch is set to zero, default, initial BGP peer batching is disabled.
		(default: 0)

KEY:		bgp_aspath_radius
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). 

KEY:		[ bgp_stdcomm_pattern | bgp_extcomm_pattern ]
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.

KEY:            [ bgp_stdcomm_pattern_to_asn ]
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.

KEY:		bgp_peer_as_skip_subas
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
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
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'.

KEY:            bgp_src_std_comm_type
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.

KEY:            bgp_src_ext_comm_type
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.

KEY:            bgp_src_as_path_type
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.

KEY:            bgp_src_local_pref_type
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.

KEY:            bgp_src_local_pref_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'.

KEY:            bgp_src_med_type
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.

KEY:            bgp_src_med_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'.

KEY:		bgp_agent_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.

KEY:		flow_to_rd_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. 

KEY:		bgp_follow_default
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
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
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 [GLOBAL]
DESC:           full pathname to a file containing the list of IP addresses (one for each line) allowed
                to establish a BGP session packets to the BGP thread. Current syntax does not implement
		network masks but only individual IP addresses. (default: 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: no password)

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 if BGP sessions are passing best-path only. In case of 
		BGP ADD-PATHs it is instead recommended to raise this value; a value of 65535 proved
		to work OK for 25 concurrent BGP ADD-PATHs sessions. (default: 1024)

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

KEY:		isis_daemon_net
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.

KEY:		isis_daemon_iface
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.

KEY:		isis_daemon_mtu
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. (default: 1476) 

KEY:		isis_daemon_msglog
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 ]
DESC:		If pmacct is compiled with --enable-geoip, this defines full pathname to the Maxmind GeoIP
		v1 IPv4/IPv6 database file to use.  

KEY:		uacctd_group
DESC:		Sets the Linux Netlink ULOG multicast group to be joined. (default: 1)

KEY:		uacctd_nl_size
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]
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> 

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.

KEY:            tee_receivers
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.

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 OS)

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.