Documentation

Flowc-1.4.3

• System requirements
o Software
o Hardware
• Package structure
o src/
o scripts/
o examples/
o www/
• Installation
o Flowd and web interface installing
o RRD scripts installing
• Cisco router configuration
o Configuring SNMP and NTP
o Configuring Netflow switching
o Configuring Netflow export
• Flowd configuration
o Global parameters
o AS sets
o Routers
o Traffic counters
o IPaddr counters
o AS counters
o flowd.conf example
• ISP billing
o Overview
o Billing strategies
o Netflow database structure
o Customers traffic counters
• Flowc optimization
o MySQL
o Flowd
o Routers flow cache
• Security
o Netflow packets spoofing
o DOS attacks

System requirements

Software
Flowc was tested on FreeBSD 4.* and Linux OS 2.4.*. For storage accumulated Netflow
accounting information it use MySQL. It provides flexible and fast access and data
manipulation. You always have ability to write own SQL request to database for
extracting necessary traffic information. Because Netflow accounting packets contain
SNMP id for routers interface identifying, and interfaces SNMP id may changes
frequently (after router reboot or adding/deleting logical interface), flowc require SNMP
library (UCD-SNMP or /NET-SNMP packages). The best and simplest way for building
traffic reports is using perl scripts and web interface. For this purpose flowc require
Apache HTTP server, PHP4 compiled as apache module and Perl5 with DBI module with
MySQL support. Flowc package contains some predefined most required in real life
traffic reports (perl and php scripts), but you always have ability to modify it for own
purpose. For graphical monitoring flowc parameters (Netflow accounting traffic,
processed flows, flowd routers cache utilization, total routers switched bytes and packets)
flowc use RRD-Tool package.

Hardware
Flowc is lightweight software and it don't require powerful hardware with the exception
MySQL server. MySQL server is most exigent Flowc component, especially for high
volume Netflow accounting traffic. In last case, additional MySQL tunning and Flowc
optimization is needed (see Flowc optimization). For Netflow collector host with flowc
installed you can approximately calculate required hardware resources.

• CPU. Pentium II-300MHz is more than enough for routers with heavy loaded
external links with total capacity up to 10Mbps. For links with total capacity
100Mbps or more Pentium III is required. You need to monitor flowd (flowc
daemon) CPU usage via top utility or Flowc rrd scripts. Flowd CPU usage must
be less than 50%, otherwise netflow packets lost may happen. In my case I have
three routers with total external link capacity about 100Mps. In average, routers
switch 40000 packets per second. My netflow collector running on Celeron
600MHz, and eats 2% CPU.
• Memory

Flowd use memory for flows aggregation (flows cache) and traffic counters. If
physical memory is not enough, flowd swaping occur, as result netflow
accounting packets may be lost if you have high volume of Netflow accounting.
Flowd periodically (by default dump interval is once per hour) flush flows cache
contents to disk. Flow cache size must be enough for storing netflow accounting
during dump interval. Otherwise if flows cache utilization exceed 95% flowd
performs autodump, and dump file growth rapidly. The approximately formula for
calculation flows cache size is 100000 records (40bytes x 100000 = 4Mb) per
1Mbit/s (10000 active flows) heavy loaded external routers interface bandwidth.
The exact value you can obtain by graphical monitoring flowd routers cache
utilization. Standard and ip traffic counters use approximately 160 bytes per filter
string, and AS counter use 512Kbytes of memory.

• Disk space

Flowd stores aggregated Netflow information to dump files befor loading it to

 MySQL database. Dump file size depends on Netflow accounting volume and
flowd dump interval (flows aggregation time). For default dump interval 1 hour
and 1Mbit/s heavy loaded external routers interface bandwidth you need
approximately 1Gb disk space per month.
Package structure

src/
The src directory contains sources of flowc binaries:

• flowd is a netflow collector. It gathers routers traffic accounting, agregates they in

a RAM and periodicaly flush it in to external files. The default flowd
configuration file is /etc/flowd.conf and can be redefined during building package.
The flowd daemon redirects all error messages to syslog. If debug option in
config file is set to ON, flowd runs in foreground and all debug information and
error messages will be displayed on the stderr too. MySQL DB must be created
before flowd start.

• Usage: flowd [-k operation]

• where operations are:
• shutdown
• dump
file
• rebuild
table
• rotate
• rotate_db
- daemon stutdown
- dump gathered traffic in data
- rebuild internal snmp interface
- rotate data file
- rotate MySQL flow tables.

After start, flowd forks in two process. The child process performs Netflow
processing, the parent process look after child process, and restart it after 2
seconds in case of child sudden death.

• loader is a MySQL loader. It loads new records from dump files created by flowd
in MySQL database. After the loader added ordinary record in DB, the
LAST_FILE_OFFSET field in 'routers' table will be incremented. This field
contains last added record offset in router dump file. After start, the loader begins
record load process from that offset. If you created new dump file or rotated old
dump file, the routers.LAST_FILE_OFFSET field must be set to zero for
appropriate router. ("flowd -k rotate" command automatically reset
routers.LAST_FILE_OFFSET field after successlful rotation). MySQL DB must
be created before loader start. The 'routers' table creates automatically by flowd at
startup if it don't exists. The loader must be periodicaly executed via cron.
• Usage: loader [-r router_name [start_date [finish_date
[traf_counters_filename]]]
• start and finish dates have the following format:
yyyymmdd-HHMMSS
• where:
• yyyy - year in four digits presentation
• mm - month (01-12)
 • dd - day of month (01-31)
• HH - hours (00-59)
• MM - minutes (00-59)
• SS - seconds (00-59)

NOTE: If you are using partial data loading (with start_date option) the
last_file_offset field in ROUTERS table leaves untouched for specified router.
WARNING! Before running partial data loading, check the timezone settings.
Incorrect timezone settings will be cause of data lost or dublication.
If you want to load data for certain traffic counters (without loading to default
'flows' table and updating last_file_offset field in ROUTERS table) you can list
counters names in external file and use it as foth argument
(traf_counters_filename). It usefull if you have added new traffic counters
(customers) in the middle of a month and want to load data for corresponding
traffic counters flows tables begins from first month day. Because loader creates
lock file for each loading dump file, more than one copy of loader process can run
in any time. Each process will works with one routers dump file.

• counter connects to flowd via UNIX Domain socket, reads and displays internal
traffic counters packets and octets values and flowd statistic. See the flowd.conf
example for configuring traffic counters and examples/ directory if you are going
to graphical traffic representation.
• Usage: counter [-s] [-t] [-i] [-a] [-d]
• options:
• -s - display flowd statistic
• -t - display traffic counters
• -i - display ip address counters
• -a - display AS counters
• -d - display all traffic counters structure
including MySQL counters

without any options all listed above counters will be displayed.

• test binds to specified UDP port, listens and displays on terminal content of all
incoming NetFlow packets without any processing. It may be used for debuging
purposes.
• Usage: test -p port

scripts/
The scripts directory contains MySQL scripts.

• create_table This script automaticaly created by configure. The purpose of this

script is creation all needed databse table structures and netflow MYSQL user
with appropriative MYSQL access permissions.

• upgrade-1.4.3.sql This script used for upgrade database structire from old version
 to 1.4.3 version.

examples/
This directory contains examples of scripts.t may be used in real life

• as_set/ contains scripts for as_set building and monitoring.

• mrtg_rrd/ contains scripts and flowd.conf examples in case if you are going to
implement graphical traffic counters representation via MRTG or RRD Tool

• sql/ SELECT query examples for traffic reports.

www/
This directory contains scripts for traffic reports, billing web interface and flowd grahicas
monitoring.

• billing web interface to ISP traffic billing system. see the xxxxx for detail
description

• rrd scripts for flowd graphical monitoring. See the xxxxx for detail description

• reports This directory contains scripts used for generation html traffic reports

o analyser.pl This script automaticaly creates by configure if the --with-web

option has been used. The purpose of this perl script is a html traffic report
generation. The final report produced by analyser.pl has two HTML tables
(one for incoming traffic, other for outgoing traffic). That tables contain:
destination address and destination hostname, number of packets and total
bytes transfered. Report pages will be generated for each interface marked
as "External" in netflow MySQL DB (flowd automaticaly mark as
"external" all external interfaces specified in its config file flowd.conf).
This reports have the first level of traffic detalization.
o Usage: analyser.pl h|d|w|m
o h - hourly report
o d - daily report
o w - weekly report
m - monthly report

o host_detail.php HTML files generates by analyser.pl have a links to this

file. It generates more detail traffic reports. Reports produced by this file
will be generated "on the fly", instead static html pages generated by the
analyser.pl. They contain: source address, source hostname, destination
address, destination hostname, number of packets and total bytes
transfered. This reports have the second level of traffic detalization.

o host_very_detail.php HTML page generated by host_detail.php have a

links to this file. It generates very detail traffic reports. Reports generated
by this file will by generated "on the fly" too. They contain: timestamp,
 address, source hostname, source port, destination address, destination
hostname, destination port, protocol, number of packets and total bytes
transfered. NOTE: timestamp in that report will be arounded to
dump_interval specified in flowd.conf.

o customer_report.phphis script provide you flexible way to generates

reports for individual flows tables, interfaces, hosts, ports, ASes,
timeranges, etc...

o config.php This file authomaticaly generates by configure and contains

reports and MYSQL db access settings needed for .php scripts.

Installation

Flowd and web interface installing

Suppose you have already installed Apache web server with PHP support. (PHP must be
compiled as apache module with MySQL support), and DBI module with MySQL
support. For addition information see: www.php.net and www.apache.org.

• 1. Unpack the flowc distribution:

• $ tar -xzvf flowc-1.4.3.tgz

• 2. Run configure script. This script check your system and authomaticaly creates
all needed files:
• $ cd flowc-1.4.3
• $ ./configure
•
• The following main options is available:
•
• --prefix=PREFIX install architecture-independent files in
PREFIX
• default prefix is /usr/local/cisco
•
• --with-snmp[=PATH] UCD-SNMP or NET-SNMP package base
directory (configure
• trying to find package is /usr /usr/local
/usr/ucd-snmp
• and /usr/local/ucd-snmp directories)
•
• --with-mysql[=PATH] MySQL base directory (configure trying to
find package
• in /usr /usr/local /usr/mysql and
/usr/local/mysql
• directories)
•
• --with-flowd-conf=PATH flowd config file location.
/etc/flowd.conf is default
•
• --with-web=PATH web interface (reports, billing system)
base directory
•
• --enable-traff-counters enable traffic counters, enabled by
default
•
• --enable-ascii-addr store IP addresses in DB as ASCII,
default is binary
• network byte order (aka big-endian)
•
• --enable-aggregation aggreagtion TCP connection, enabled by
default
•
• --enable-store-ports store TCP/UDP port numbers in database,
enabled by
• default
•
• --enable-store-as store AS numbers in database, disabled by
default
•
• --enable-long-streams use 64-bit digits for storage in DB
packet & octets
• counters for individual flow
(appropriately for routers
• which handle huge traffic). By default
32-bit digits
• --enable-new-dbrotate the name of old flows MySQL DB table
after DB
• rotation based on date (f.e. flows-
20020501-21:00:00)
instead a "flows_old" as in 1.4 and older
releases.

For reducing database disk space I recommend use the binary storage. Also the
binary storage type allows address range manipulation in SQL requests, using
comarison operators ">", "<". But in case of manual SQL database requests, at
first you have to convert an IP address in to binary representation host order (for
details see FAQ). PHP report scripts included in flowc distribution detect storage
type automatically. If information about port numbers is not important for you
(like a classical IP accounting) choose --disable-store-ports or --enable-store-
ports=no option. It reduces the total database size. After start, configure offers
you specify MySQL DB access parameters and authomaticaly builds example of
flowd configuration file: src/flowd.conf, DB structure creator:
scripts/create_tables, report builders (if option --with-reports was specified) :
reports/analyser.pl and reports/config.php3. 32-bit digits used for packet and
octets values storage in DB. Because in real life a single flow (f.e. individual TCP
session) carries traffic less than 4294967295 bytes (2^32), for reduceing database
space 32-bit counters used by default. The --enable-long-streams option in
configure script allows to use 64-bit counters. NOTE: MySQL uses 64-bit digits
 for sum() operation, therefore report scripts work correct for 32-bit octets and
packets values summarization.

• 3. Compile and install package (use GNU make).

$ gmake

• 4. Create MySQL database, if it need edit the scripts/create_tables script and run
it. It creates all needed mysql tables and fix mysql access permission for netflow
MySQL user.
• $ mysqladmin -u root -p create netflow
• $ vi scripts/create_tables
• $ scripts/create_tables

• 5. Copy the example of the flowd configuration file generated by configure script
to its location (/etc/flowd.conf is the default location) and edit it. Because the
CISCO NetFlow handle incoming packets only (it is switching tech- nology), you
need to turn "ip route-cache flow" on all interfaces. Also, you need specify
"internal" interfaces, traffic information from wich will be stored.
• $ cp src/flowd.conf /etc
$ vi /etc/flowd.conf

• 6. Install the package.

$ gmake install

• 7. If you compiled with --web option, set 'register_globals' option in your system
php.ini file to 'On'.

• 8. Configure your router as described in router configuration section.

• 9. Add flowd start to system startup scripts. Takes in to account, that flowd
connects to MySQL DB during startup, therefore mysqld must be started before
flowd.

RRD scripts installing

Before RRD scripts installation, install RRD-Tool package, compile and configure flowd
(describe all needed routers in flowd.conf or MySQL database). Suppose you configure
flowc with --with-web=/usr/local/httpd/netflow option, then installation process will be
look like:

• 1. After installing flowc (make install) go to this directory:

# cd www/rrd
• 2. Edit create.pl, poll.pl and 1day.cgi.pl. May be you need to correct RRD-Tool
base directory (by deault it is /usr/local), path to counter program in poll.pl (by
default it is /usr/local/cisco/bin/counter) and WORKDIR (by default it is
/usr/local/httpd/netflow/rrd).

• 3. build script for rrd database creation:

# ./create.pl router1 router2 ... routerN > create.sh

where router1 router2 ... routerN are routers names as declared in flowd.conf file.
WARNING! Don't use names more than 10 characters, otherwise you will have
problems with RRD.

• 3. create cgi file:

• # ./1day.cgi.pl router1 router2 ... routerN > 1day.cgi
# chmod 755 1day.cgi

• 4. copy all needed files to working directory for rrd scripts:

# cp create.sh 1day.cgi poll.pl /usr/local/httpd/netflow/rrd

• 5. change working directory

# cd /usr/local/httpd/netflow/rrd

• 6. create RRD database:

# sh create.sh

• 7. Configure Apache web server. httpd.conf must contains following directives:

•
• AddHandler cgi-script .cgi
• ‹Directory "/usr/local/httpd/netflow/rrd/"›
• Options ExecCGI
• AllowOverride None
• Order allow,deny
• Allow from all

• 8. Restart Apache:
• # apachectl restart

• 9. Allows Apache to create .png files in rrd directory:

# chmod 777 /usr/local/httpd/netflow/rrd

 • 10. Start RRD database regular updating via cron. Add to /etc/crontab file string:

*/5 * * * * root /usr/local/httpd/netflow/rrd/poll.sh

• 11. See results from web browser. You have to see something like this

Cisco router configuration

Configuring SNMP and NTP

Netflow packets originated from router contain SNMP id-es as input and output interface
identificators. Unfortunately, SNMP id-es may changes frequently in many situation:
after adding or deleting asyncronous interface, frame relay subinterface, ethernet
subinterface, tunnels, rebooting router, etc. For storing netflow information flowc use
interface names, instead SNMP id, and SNMP access to router from collector host must
be configured before flowd start like this:
router# conf t
router(config)# access-list 1 remark SNMP access
router(config)# access-list 1 permit x.x.x.x
router(config)# snmp-server community public RO 1
router(config)# snmp-server ifindex persist
where x.x.x.x is your netflow collector host ip address. The last command is very
important, because netflow collector has no ability to determine routers SNMP interface
table changes. This command preserve existing interfaces SNMP id-es from changes and
flowd for storing wrong information in case if adding or deletion logical interfaces
occure. Routers SNMP interface table will be changed later, after rebooting, but flowd
has ability to detects router rebooting, and automatically rebuild own SNMP id-es table.
Netflow packets contain routers time as flow start and finish timestamps. By default
routers clock set to year 1993. Check does the routers clock configured properly (show
clock). If routers time differ than netflow collector host time, you will have a problems in
traffic reports. I reccomend you set up NTP clock syncronization on your router and
collector host:
router# conf t
router(config)# ntp server y.y.y.y
router(config)# ^Z
router#show ntp status

Clock is synchronized, stratum 4, reference is y.y.y.y

nominal freq is 250.0000 Hz, actual freq is 249.6494 Hz,
precision is 2**18
reference time is C27B6EEB.D6133750 (19:33:47.836 EEST Sun May
25 2003)
clock offset is -660.2284 msec, root delay is 488.19 msec
root dispersion is 886.06 msec, peer dispersion is 169.20 msec
For detail description of SNMP and NTP configuration see Configuring SNMP Support
and Configuring NTP.

Configuring Netflow switching

Netflow switching deal with interface incoming packets only, therefore you must enable
Netflow switching for all routers interface. Otherwise you have no ability to account
outgoing packets. The "ip route-cache flow" command entered in interface
configuration mode enables Netflow switching on interface:
router#conf t
router(config)#interface FastEthernet0/0
router(config-if)#ip route-cache flow
router(config)#interface Serial0/0
router(config-if)#ip route-cache flow
...
If you have sub interfaces (frame-relay, ATM or ethernet dot.1q or ISL VLAN-s) "ip
route-cache flow" command must be entered on main (physical) interface only.
Additional information about deploing Netflow on logical (frame-relay, ATM, tunnels,
MPLS VPN, etc) interfaces available here.
Be careful when enable netflow switching on asyncronous interfaces, some older IOS
versions (12.1) have bugs. As result you have high CPU load and no ability to get
information about traffic passed throgh asynchronous interfaces (Netflow packets contain
invalid interface SNMP id).
NOTE: Begins from IOS 12.2(15)T you have ability to enable netflow switching per
subinterfaces. See the NetFlow Subinterface Support for additional information.

Configuring Netflow export

Current flowc versions works with NetFlow version 5 packets only. To configure the
router to export NetFlow switching statistics maintained in the NetFlow cache to a
collector host when a flow expires, use the following commands in global configuration
mode:
router(config)# ip flow-export ip-address udp-port version 5
[origin-as | peer-as]
Turning "origin-as" or "peer-as" options will case including in Netflow pacckets BGP AS
numbers. Depend of which option use, router use source/destination traffic AS numbers
or your peers AS numbers (for exaplme your ISP AS number) respectively. If router is
not BGP enabled or source/destination address is absent in BGP table, or
source/destination address belong to your AS (and presented in BGP table with empty
AS-path: "show ip bgp reg ^$") then zero value will be used in src_as/dst_as.

Flowd configuration

flowd.conf is main configuration file for flowd, loader and counter programs. By default
it locates in /etc directory, but you can change it location via --with-flowd-conf configure
option (see Installation). Flowd.conf is a simple text file. All empty strings are ignored.
All text after '#' character is ignored. All key words is case insensitive. As separator you
can use space or TAB characters. flowd.conf contains following parts, that must be
defined in following order:
Global parameters
AS sets
Routers section
Traffic counters, IPAddr counters, AS counters
Global parameters
Parameter Dafault value Description
debug off The flowd daemon redirects all error messages to
syslog. If debug option in config file is set to 'on',
flowd runs in foreground and all debug information and
error messages will be displayed on the stderr too.
pid_file /var/run/flowd.pid After start, flowd forks in two process. The child
process performs Netf low processing, the parent
process look after child process, and restart it afte r 2
seconds in case of child sudden death. This file
contains process id of the child process.
dump_interval 1 hour how often flowd flush aggregated flows cache in to
dump file (in seconds)
listen_address 0.0.0.0:3000 Format: [address:]port. flowd must be binded for that
ip address and UDP port for listening UDP Netflow
packets from routers.
redirect Format: address:port. Optional parameter. If you
specify it, flowd will send copy of all netflow traffic to
specified host and port. Flowd construct UDP packet,
preserve original source address and source port
number and redirect it to other collector before
processing. It option usefull if you have two netflow
collectors, first for production purpose, the second for
testing purpose. On production collector you need to
configure redirection netflow traffic to test collector.
See the src/flowd.conf for syntax.
db_host MySQL database access settings (MySQL server
db_name hostname or IP address, netflow database name,
db_user userneme and password)
db_passwd
wait_loader on When loader is running all dump files and DB
manipulations are disabled. If wait_loader is 'off', the
"flowd -k rotate" or "flowd -k rotate_db" command
return immediately with appropriative error message. If
wait_loader set to 'on', then the "flowd -k rotate" or
"flowd -k rotate_db" commands will wait loader finish.
load_default on If set to 'on', then loader will be load all data from
dump file to 'flows' SQL table. Otherwise only data
that satisfy traffic_counters with load or load_only
options filter conditions will be load to 'flows' table.
load_tc on loader will be load data from dump file to 'flows' SQL
table in addion to 'flows-trafcounter_name' table if data
satisfy traffic_counter with 'load' or 'load_only' filter
conditions.
server_port well know TCP servers ports more than 1024. They are
 used for TCP port aggregation. You can define a lot of
ports, one server_port definition per line.

AS sets
If you have deal with large AS lists, using AS sets is preferable method. You can specify
large AS list once in flowd.conf or external file and apply it to many traffic counters or
external interfaces statements instead src_as or dst_as parameters. AS set store AS list in
sorted order and use binary search algorithm for fast AS lookup. AS set definition must
begins with letter (not from digit or '*' symbol). You can define AS set as list AS
numbers separated by space or TAB or specify external file name that contain AS number
list (one number per line):
as-set name ‹filename› | ASnumber1 ASnumber2 ...

for example:
as-set UA "/etc/ukras.txt"
as-set xxx 13032 3252 3254 6666

Routers
Routers section in flowd.conf describes Netflow enabled routers and must be defined
before any traffic counters statements. It has following syntax:
router ‹router_name›
{
‹parameter1›
‹parameter2›
...
‹parameterN›
}
where parameters are:
Default
Parameter Description
value
data_file File in which flowd dumps aggregated Netflow
accounting information. It is a binary file, it structure
defined in src/global.h (struct Flow). Dump file locked
by flowd after flowd start. loader program use this file as
data source for uploading to MySQL database.
rotate_level Data_file rotation level. After dump files rotation ("flowd
-k rotate"), old dump files will be renamed with ".0"
suffix, a previous ".0" file will be renamed with ".1"
suffix, etc. Rotate_level parameter defines how many
1 backup dump file you can have. For example, if data_file
is /var/flowc/router and rotate_level set to 3, you will
have /var/flowc/router.0, /var/flowc/router.1,
/var/flowc/router.2 files after 3 or more dump files
rotation ("flowd -k rotate")
router_address Router can have a dozen of interfaces, but as source
address in Netflow UDP packets used IP address of
nearest to Netflow collector host (in term of routing)

community
flow_cache_size
external_interface1
external_interface2
..........
external_interfaceN
routers interface, or address of interface specified in "ip
flow-export source " command. After receiveing Netflow
packet, flowd checks router_address parameter for all
routers defined in flowd.conf (and MySQL db). In case
of match, packet will be processed and stored in flows
chache allocated for this router, otherwise packet will be
ignored and warning message in syslog.
Flowd need to know SNMP Id of all routers interfaces,
because it used as interface identifiers in Netflow
packets. For this purpose flowd read routers SNMP
interface table at startup, if router reboot detected or by
user request ("flowd -k rebuild"). SNMP community
string must be defined the same as on router. For
configuring SNMP see here.
Flow cache memory size (in records) used for flows
aggregation. The reccomended value is 100000, but you
can increase or decrease it depends of routers traffic. If
no free memory in cache, flowd performs autodump.
This increases dump file size. You need to monitoring
flow cache utilization and adjust this value according
your network traffic.
External interfaces list. It used for minimization stored
netflow information. All packets switched between pair
of Internal interfaces are ignored by flowd. All packets
switched between Internal-External or External-External
interfaces processed by flowd. External interface
definition has syntax specified bellow:

external_interface interface [src_addr[/masklen] src_port dst_addr[/masklen] dst_port

protocol direction src_as|asc_AS_Set dst_as|dst_AS_Set]

Parameter Description
interface is a valid external interface defined for this router above
Internet protocols 0 - IP, 1 - ICMP 6 -TCP, 17 - UDP (see the
protocol
/etc/protocols)
In - for incoming packets, Out - for outgoing packets, Any - for any
direction
direction
src_as source AS number. Range 0 to 65535. "*" means any AS number
dst_as destination AS number. Range 0 to 65535. "*" means any AS number
src_AS_Set source AS list (it must defined before in flowd.conf)
dst_AS_Set destination AS list (it must defined before in flowd.conf)
Zero in src_addr, src_port, dst_addr or dst_port fields means a wildcard value (any valid
address or port)
Traffic counters
Traffic counters is a key component of flowc. It consists of traffic filter rules and used for
real time traffic accounting. Also it can be used by the loader program for customers
traffic separation with further loading to specific flows tables. Bytes and packets counters
for traffic counter renewed immediatelly after receiveing Netflow packet from router.
You can fecth bytes and packets counter values accumulated by flowd via 'counter'
program running with '-t' option. You can specify traffic counters by two ways: directly
defined it in flowd.conf or dynamically configured from MySQL DB. The last method
will be explained detail in traffic billling section. In flowd.conf traffic counters defined
the following manner:
traffic_counter name [loader option] [hit action]
{
filter statement1
...
filter statementN
}
where:
Parameter Description
name Traffic counter name, must be unique.
loader option options for loader program, "load" or "load_only". "load" means load data
that satisfy traffic_counter filter conditions from dump file to separate SQL
table "flows-name" instead default table "flows". Traffic counters with
"load_only" used when you want to load data that satisfy traffic_counter
filter conditions from dump file to separate SQL table "flows-name" but
without any flowd processing. Packets and bytes counters for those
counters will be always set to zero. By default no loader option applied.
hit action "stop" means stop processing NetFlow packet by next traffic_counters if
packet satisfy traffic_counter filter conditions. By default no hit actions
applied, it assumes continue processing NetFlow packet by next
traffic_counters.

Traffic counter filter statement has following syntax:

router_name interface SRC_NET src_port[-src_port2] DST_NET dst_port[-dst_port2]

protocol direction [src_as|src_AS_Set [dst_as|dst_AS_Set [match action]]]

where:
Parameter Description
router_name is a name of router defined above in routers section
interface is a valid external interface defined for this router above
protocol Internet protocols 0 - IP, 1 - ICMP 6 -TCP, 17 - UDP (see the
/etc/protocols)
direction In - for incoming packets, Out - for outgoing packets, Any - for any
direction
src_as source AS number. Range 0 to 65535. "*" means any AS number
dst_as destination AS number. Range 0 to 65535. "*" means any AS number
src_AS_Set source AS list (it must defined before in flowd.conf)
dst_AS_Set destination AS list (it must defined before in flowd.conf)
match_action Set it to "Stop" if you don't want to account this traffic (ignore this traffic
or by other words immediately exit from this traffic_counter) or "Pass"
otherwise. By default, the "Pass" action assumes.

SRC_NET and DST_NET can be defined in two manner, standard or as address range:
src_addr[/src_masklen] or start_src_addr-end_src_addr
and
dst_addr[/dst_masklen] or start_dst_addr-end_dst_addr
Zero in src_addr, src_port, dst_addr or dst_port fields means a wildcard value (any valid
address or port). You can specify ports range in src_port and dst_port fields. For tarffic
counters example see the flowd.conf examples

IPaddr counters
It intend for realtime IP adress pool traffic calculation on per address basis. It useful if
you have IP address pool (dialup, VPN, ...) and want to implement individual IP address
accounting scheme without using huge amount of standard traffic counters (one traffic
counter for each IP addres from pool). The counter program running with -i option (or
without any options) display ip_addr_counters packets and octets values. IPaddr counters
has following syntax:
ipaddr_counter name side
{
filter statement1
...
filter statementN
}
where:
Parameter Description
name ip address counter name
side Defines "active" side. If it set to "src" then ip addresses from source
address range filter statements will be accounted. Otherwise, if it set to
"dst", destination address range from filter statements will be used. Of
cource, all filter statements must have identical src or dst (depends of side
option) address range portition ("active" address portition). Warning!
Single address used in ip address counter eats 16 bytes of memory, avoid
using large address pools. It adversely affect on system performance.
Note: using whole IPv4 address space (0/0 as address/mask) as active
side for ip address counters prohibited.
filter statement filter statements has the same syntax and meaning as in standard traffic
counters except that all filter statements must has the same structure of
src or dst (depends of side parameter) address portition (other words all
filter statements must use same IP address pool).

AS counters
It intend for realtime traffic accounting on per AS basis. It useful if you want to keep
track in real time per AS traffic flows without using huge amount of standard traffic
counters (65536 counters) The counter program running with -a option (or without any
options) display as_counters packets and octets values. AS counters has following syntax:
as_counter name side
{
filter statement1
...
filter statementN
}
where:
Parameter Description
name AS counter name
side Defines "active" side. If it set to "src" then source AS will be accounted.
Otherwise, if it set to "dst", destination AS numbers be used. Warning!
Single as counter eats 1Mbyte of memory (65536*16), avoid using many
as counter name. It adversely affect on system performance.
filter statement filter statements has the same syntax and meaning as in standard traffic
counters except that all filter statements must has the same structure of
src or dst (depends of side parameter) address portition (other words all
filter statements must use same IP address pool).

flowd.conf example
debug off
pid_file /var/run/flowd.pid
dump_interval 3600
listen_address 3000
redirect 195.19.104.9:5000
db_host db.wolf.tambov.ru
db_name netflow
db_user netflow
db_passwd xxx

wait_loader on
load_default on
load_tc on

as-set UA "/var/flowc/ukras.txt"
as-set ExtAS 6877 13228 6850 3267 5568 9162

router router1
{
data_file /var/flowc/router1.data
rotate_level 3
router_address 1.2.3.4
community public
flow_cache_size 50000
external_interface serial0/4 # main uplink
external_interface serial1/0.1 # backup
external_interface serial1/1
external_interface "ATM1/0.1-aal5 layer"
external_interface "ATM1/0.2-aal5 layer" 193.25.87.0/23 0
0 0 0 any * *
external_interface "ATM1/0.2-aal5 layer" 194.44.0.0/16 0 0
0 0 out * *
}

server_port 3128 # squid

server_port 8080 # http
server_port 7070 # real audio/video
server_port 3306 # mysql
server_port 2593 # ultima online
server_port 6666 # IRC server
server_port 6667 # IRC client koi8
server_port 6668 # IRC client translit
server_port 6669 # IRC client win1251
server_port 4662 # eDonkey

traffic_counter Customer1_In
{
router1 "ATM1/0.2-aal5 layer" 0 0 193.25.97.151 0 0 in * *
router1 "FastEthernet0/0.11-ISL vLAN subif" 0 0 193.125.79.151
0 0 in * *
router1 ethernet2/1 0 0 193.25.97.178 0 0 in * * Stop
router1 ethernet2/1 0 0 193.25.97.0/27 0 0 in * *
router1 ethernet2/1 0 0 193.25.97.128/29 0 0 in * *
router1 ethernet2/1 0 0 193.25.97.95-193.25.97.99 0 0 in * *
}

traffic_counter HTTP_Out
{
router1 serial1/1 0 80 0 0 6 out
router1 serial1/1 0 8080 0 0 6 out
router1 serial1/1 0 8000 0 0 6 out
}

ipaddr_counter vpdn_world_out src

{
router1 serial1/1 193.25.97.0/26 0 0 0 0 out
router2 Ethernet0 193.25.97.0/26 0 0 0 0 out * UA
}

as_counter test1 dst

{
router1 serial1/1 0 0 0 0 0 0 out
router2 ethertnet0 0 0 0 0 0 0 out
}

Netflow database structure

Click to interesting table on picture below for detail description.

To be continue...