Docstoc

Collecteur Netflow

Document Sample
Collecteur Netflow Powered By Docstoc
					                                                                                                                          IPFlow Collector




                                                 IPFlow Collector

1Introduction...............................................................................................................................4
2Supported Architectures............................................................................................................5
3Some recalls on Netflow...........................................................................................................5
  3.1 Principles...........................................................................................................................5
  3.2 Netflow versions...............................................................................................................6
4Configuration File and Collector Startup..................................................................................6
5Routers......................................................................................................................................8
  5.1 Settings..............................................................................................................................8
  5.2 Use of a « dispatcher »......................................................................................................9
  5.3 Interface naming..............................................................................................................11
6Dispatching Service................................................................................................................12
7Sites.........................................................................................................................................14
  7.1 Site notion.......................................................................................................................14
  7.2 Practical example............................................................................................................14
  7.3 Management of subnets...................................................................................................15
  7.4 Specific sites...................................................................................................................15
  7.5 Configuration..................................................................................................................16
8Rules .......................................................................................................................................17
  8.1 Actions............................................................................................................................17
     8.1.1Flow Colorization.....................................................................................................17
     8.1.2Site Traffic Matrix.....................................................................................................17
     8.1.3Aggregation...............................................................................................................18
     8.1.4Logging.....................................................................................................................18
     8.1.5Port scan detection....................................................................................................18
     8.1.6IP Address Rewrite...................................................................................................18
     8.1.7Term evaluation........................................................................................................19
  8.2 Rule Binding...................................................................................................................19
  8.3 Configuration..................................................................................................................20
9Access-Lists (ACL).................................................................................................................22
  9.1 Evaluation.......................................................................................................................22
  9.2 Description of the criteria................................................................................................22
     9.2.1IP Protocol.................................................................................................................22
     9.2.2Source and Destination IPv4 Addresses...................................................................22
     9.2.3Source and Destination IPv6 Addresses...................................................................23
     9.2.4ToS (Type of Service) Field......................................................................................23
     9.2.5TCP Flags..................................................................................................................23
     9.2.6Source and Destination Ports....................................................................................24
     9.2.7Source and Destination AS.......................................................................................24
     9.2.8Duration....................................................................................................................24
     9.2.9Number of packets and bytes....................................................................................25
  9.3 Optimization....................................................................................................................25
  9.4 Configuration..................................................................................................................26
10Channels................................................................................................................................27
Christophe Fillot - 06/10/2005                                                                                                             1/85
                                                                                                                     IPFlow Collector


  10.1 Text and Binary Files....................................................................................................27
     10.1.1Text Files.................................................................................................................27
     10.1.2Binary Files.............................................................................................................27
     10.1.3« Site Traffic Matrices » (STM) Files.....................................................................29
  10.2 Logging into a file.........................................................................................................30
  10.3 Logging into a TCP/UDP socket..................................................................................30
  10.4 Logging into an UNIX socket.......................................................................................31
  10.5 Log Format....................................................................................................................31
  10.6 Log Rotation.................................................................................................................31
     10.6.1Triggering Criteria..................................................................................................31
     10.6.2Configuration examples..........................................................................................32
  10.7 Specific Options of binary files.....................................................................................32
  10.8 Configuration................................................................................................................33
11Log Formats..........................................................................................................................34
  11.1 Principle........................................................................................................................34
  11.2 Format String (text files)...............................................................................................34
     11.2.1Field Specification..................................................................................................35
     11.2.2Special Fields..........................................................................................................36
       11.2.2.1TCP Flags.........................................................................................................36
       11.2.2.2Date and Hour..................................................................................................37
       11.2.2.3Colors...............................................................................................................37
  11.3 Field List (binary files).................................................................................................38
  11.4 Default Format..............................................................................................................39
12Site Traffic Matrices.............................................................................................................41
  12.1 Principle........................................................................................................................41
  12.2 Configuration................................................................................................................42
  12.3 Practical example..........................................................................................................42
  12.4 File storage....................................................................................................................43
13Aggregators...........................................................................................................................45
  13.1 Principle........................................................................................................................45
  13.2 Configuration................................................................................................................45
  13.3 File storage (precisions)................................................................................................47
  13.4 Tuning...........................................................................................................................47
14Port Scans Detection.............................................................................................................49
  14.1 Horizontal and Vertical Scans.......................................................................................49
  14.2 Thresholds setup...........................................................................................................49
  14.3 Notifications..................................................................................................................49
  14.4 Example........................................................................................................................49
  14.5 Configuration................................................................................................................52
15Netflow v8.............................................................................................................................53
16Netflow v9.............................................................................................................................55
  16.1 Template Definition......................................................................................................55
  16.2 Advanced Options.........................................................................................................57
     16.2.1Template ID Specification......................................................................................57
     16.2.2Exact definition of fields.........................................................................................57
     16.2.3Displaying template contents..................................................................................57
     16.2.4Displaying flow data...............................................................................................57

Christophe Fillot - 06/10/2005                                                                                                       2/85
                                                                                                                     IPFlow Collector


    16.2.5Displaying unknown templates...............................................................................57
17Counter Management............................................................................................................59
  17.1 Principle of counters.....................................................................................................59
  17.2 Output File ...................................................................................................................59
  17.3 Rule counters ................................................................................................................60
  17.4 Access-List (ACL) counters..........................................................................................61
  17.5 Counters for Site Traffic Matrices................................................................................61
  17.6 Router counters.............................................................................................................62
  17.7 Interface counters..........................................................................................................62
  17.8 Templates (Netflow v9 only)........................................................................................63
  17.9 Example........................................................................................................................64
18Using RRDTool with IPFlow...............................................................................................66
  18.1 RRDTool Installation....................................................................................................66
  18.2 Manual creation of a RRDTool database......................................................................67
  18.3 Automatic creation of a RRDTool database.................................................................67
  18.4 Obtaining graphics........................................................................................................68
  18.5 Example........................................................................................................................69
19IPFlow Grep : flow lookup utility.........................................................................................70
  19.1 Criteria..........................................................................................................................70
    19.1.1 How « --addr » and « --prefix » options work.......................................................71
    19.1.2Size specification (« --size »)..................................................................................71
  19.2 Particular options..........................................................................................................71
  19.3 Examples.......................................................................................................................72
20IPFlow « File Info »..............................................................................................................75
21IPFlow « STM_Info »...........................................................................................................79
22IPFlow « STM_Fetch » ........................................................................................................82
23Annex : a simple example.....................................................................................................84




Christophe Fillot - 06/10/2005                                                                                                       3/85
                                                                                 IPFlow Collector




1 Introduction

The IPFlow collector is a Netflow collector developed at UTC (University of Technology of
Compiegne, France), primarily for its internal use.

This collector has support for the following versions of Netflow :

     -   v1, v5, v6 et v7 : data are not aggregated. Netflow v5 is the most used version.
     -   v8 : data are aggregated by routers, with predetermined schemes.
     -   v9 : this is the new export format, based on templates. The IPFlow collector supports
         this new format with IPv6 capabilities.

When Netflow datagrams are received by IPFlow, a certain number of treatments can be
applied :

-   Logging into disk files (text and binary formats) ;
-   Data Aggregation ;
-   Port scan detection ;
-   Storage in RRDTool database ;
-   Colorization of flows for easy reading at screen.

IPFlow allows Netflow datagrams to be sent to other instances of IPFlow collectors, in order
to enable flow analysis with multiple configurations. This capability is called « dispatching ».

Bug reports, request for new features or improvement can be sent to Christophe Fillot
(cf@utc.fr).

More configuration examples or specific hints (especially for Netflow v9 and IPv6) can be
found at this URL :

                                 http://www.rrt.cr-picardie.fr/~fillot/nf6




Christophe Fillot - 06/10/2005                                                              4/85
                                                                                   IPFlow Collector




2 Supported Architectures

The IPFlow collector has been compiled and tried with success on the following
architectures :

-     Linux 2.4.x on i386,
-     FreeBSD 4.x on i386,
-     Solaris 8 on Sparc.

However, at this time, Netflow v9 feature is only supported on i386 platforms.


3 Some recalls on Netflow

3.1     Principles

Netflow is a technology created by Cisco Systems for network metrology. The main concept
of Netflow is the notion of flow, a flow being determined by these criteria:

       -   Source and destination IP addresses,
       -   IP Protocol (TCP, UDP, ICMP,…),
       -   ToS (Type Of Service)
       -   Source and destination ports (http, smtp, dns,…),
       -   Input and output interfaces of the router.

A packet belongs to a given flow if it corresponds simultaneously with all of these criteria.

A router that uses Netflow keeps in memory a table of the active flows at a given time, and
counts the number of packets and bytes received for each flow. Cisco calls this table “Netflow
cache” in its documentation.

For each packet that it receives, the router updates this cache. If the flow does not already
exists, it creates a new entry for it. If it exists, it increments the packet counter and the byte
counter.

In order to avoid consuming all its memory with an infinite number of flows, the router
deletes flows that it considers as finished. When a flow has been inactive during a certain
amount of time (“inactive timeout” is the expression used by Cisco), the flow is deleted from
the cache. A flow can also be delete if it has been active during a too long period (“active
timeout”). This avoids to keep in cache flows that never finish. Finally, when the router sees
“RST” or “FIN” flags for a TCP connection (that indicate the end of connection), the flow is
also deleted.

To know the inactivity of a flow, the router uses the time it received the last packet, and
compares it to the current time.

Christophe Fillot - 06/10/2005                                                                  5/85
                                                                                 IPFlow Collector




The objective of Netflow being network metrology, it was necessary to provide information
about flows to an analysis program. In fact, when a flow has expired and is being deleted from
the cache, it can be exported to a netflow collector, which receives Netflow packets with a
protocol defined by Cisco. It exists many versions of the protocol, the last version being the
version 9.

For bandwidth efficiency, the router groups between 20 and 30 flows in a same packet before
sending it.


3.2    Netflowversions

Cisco has created many versions of the Netflow protocol, following the needs of its
customers. At this time, the versions 1, 5, 6, 7, 8 and 9 exist. The version 9 should be able to
answer to evolutivity needs that have hit the previous versions, and so should be the last.

For recall, the version 5 is the most used on the routers. The version 7 is specific to the
Catalyst switches. The version 8 allows the user to use aggregation schemes.

Finally, the version 9 supports the « new protocols », like IPv6 and MPLS (MultiProtocol
Label Switching).


4 Configuration File and Collector Startup

The settings of IPFlow collector are defined using a configuration file divided in hierarchical
sections, whose syntax is very similar to BIND server from ISC.
        ! This is a comment
        /* This is a C comment */
        section <name> {
           sub-section {
              attribute <value>;

                  parameter-list {
                     <value_A>;
                     <value_B>;
                     <value_C>;
                  };
             };
        };


Remark : the parsing is case-sensitive.

The collector is started with the following command :

        ipflow collector <configuration_filename>


When the collector is starting, some informational messages are displayed :

        [rrtadm@nemesys ~]$ ./ipflow collector config-1.txt


Christophe Fillot - 06/10/2005                                                              6/85
                                                                              IPFlow Collector


        IPFlow Collector - Release 0.49.3 26-Jul-02 (experimental)
        Compiled at Aug 29 2002 00:04:22 by Christophe Fillot (cf@utc.fr)

        Initializing IPv4 and IPv6 MLS caches.
        IPv4 MLS: level-4, IPv6 MLS: level-16
        Default IPv4 address: 193.49.251.82.
        Default IPv6 address: undefined.
        Creating site matrix for traffic classifier.
        8 sites, 7 networks found in configuration.
        Retrieving 7500_UTC interface list by SNMP...
        Router 7500_UTC supervised (80 interfaces detected).
        IPFlow is using 310 Kb of memory in 122 blocks.
        MLS: memory allocated by IPv4 cache: 5 Kb, by IPv6 cache: 1 Kb.
        Enabling Netflow export on 1 router(s).
        >>> 100 OK
        Router 7500_UTC: registered with dispatching service (IPv4)
        Netflow v5 enabled for router 7500_UTC. UDP port=56040

        [ Pression de Control-C pour arrêt du collecteur ]

        Termination signal received, halting...
        Stopping Netflow dispatching for router 7500_UTC...
        >>> 100 OK
        IPFlow system successfully stopped.


If errors are found in the configuration file, IPFlow will stop immediately and display some
information about the errors.

To stop the collector, you can hit « Control-C » or send a « TERM » signal to the main
process.




Christophe Fillot - 06/10/2005                                                           7/85
                                                                                 IPFlow Collector




5 Routers

Each router involved in the Netflow process must be described in the configuration file.
Routers are identified by a unique name, which is generally the hostname (not mandatory).

It is necessary for the collector to have a SNMP access (read-only access is sufficient) on
the router. This SNMP access is needed to retrieve network interface properties, especially to
produce a mapping between names and indexes of interfaces. An example of IOS
configuration is given in the following paragraph. We suggest to apply an access-list to the
SNMP community in order to block requests from unauthorized hosts. SNMP views may also
be used : only access to IF-MIB is required by the collector.


5.1     Settings

The parameters that must be defined to enable Netflow datagram reception are listed below :

-     The IP address which is used by the router as source address for Netflow datagrams. It can
      be necessary to set this address on the router with the IOS command « ip flow-export
      source <ip_address>|<interface> ».


-     A SNMP community with read-only privilege. A SNMP access on the router is needed to
      determine interface names given SNMP indexes. If no community is specified, the
      collector will use « public » as default community name.

-     The Netflow version. The Netflow versions supported by the collector are 1, 5, 6, 7, 8 and
      9. If no version is specified, Netflow v5 is used as default.

-     The IP address and the UDP port used to receive the datagrams. Specifying an IP address
      is generally used in the case of multihomed hosts.

      Specifying the reception port allows you to keep the same configuration for Netflow
      export on the router. By default, the port is chosen dynamically by the system.




Christophe Fillot - 06/10/2005                                                              8/85
                                                                                    IPFlow Collector


The router section has the following syntax :

        router <router_name> {
           ip-address <router_ip_address>;
           snmp-community <snmp_community>;

             netflow {
                version 1|5|6|7|8|9;
                receiver-address <local_ip_address>;
                receiver-port <reception_port>;
             };
        };


Example :

        router 7500_UTC {
           ip-address 193.51.1.105;
           snmp-community netflow;

             netflow {
                version 5;
                receiver-address 193.49.251.82;
                receiver-port 8000;
             };
        };


In this example, the router to manage has IP address 193.51.1.105 and sends Netflow v5
datagrams. The collector will receive datagrams on the interface that owns IP address
193.49.251.82, with 8000/udp as reception port.

The IOS configuration of the router would be :

        interface Loopback0
          ip address 193.51.1.105 255.255.255.255;
        !
        ip flow-export version 5
        ip flow-export source Loopback0
        ip flow-export destination 193.49.251.82 8000
        !
        access-list 10 permit 193.49.251.82
        snmp-community netflow RO 10
        !



5.2    Use of a « dispatcher »

Instead of receiving Netflow datagrams directly from a router, it is possible to use
dispatchers.

The goal of dispatchers is to duplicate Netflow datagrams received from routers (or from
other dispatchers) and to re-emit them to other collectors that have subscribed to the service.
So, it is possible to start multiple instances of collectors with different configurations to
analyze the same Netflow traffic.

This paragraph explains configuration for the client part ; the server part will be detailed in the
« Dispatching Service » chapter.


Christophe Fillot - 06/10/2005                                                                 9/85
                                                                                 IPFlow Collector


In order to receive Netflow traffic from a dispatcher, a collector must register itself with the
dispatcher.

The membership request allows the collector to send the following parameters to the
dispatcher :

Router name;
- UDP port used to receive datagrams ;
- Netflow version.

When the collector is halted, a message is sent to the dispatcher to stop emission of Netflow
datagrams.

The Netflow version must be identical between the collector and the dispatcher. In case of
mismatch, the router configuration will fail.

The membership join and leave messages are sent through a TCP connection opened by the
collector to the dispatcher. By default, the TCP port used for this control connection is 5555.

To define a dispatcher, use the following syntax in the configuration file :

        dispatcher <dispatcher_name> {
           hostname <host>;
           port <control_port>;
        };

Each dispatcher is identified by a unique name, so it is possible to use multiple dispatchers in
the same configuration file.

Then, it is needed to indicate in the router configuration that a dispatcher must be used to
receive Netflow datagrams :

        router <router_name> {
           netflow {
              dispatcher <dispatcher_name>;
           };
        };


Remarks:

-   The router name must be identical between the collector and the dispatcher.
-   It is still needed to specify an IP address and a SNMP community even when using a
    dispatcher, since the collector has to retrieve the interface list directly from the router.

Example :




Christophe Fillot - 06/10/2005                                                             10/85
                                                                                 IPFlow Collector


        dispatcher Nemesys {
           hostname nemesys.rrt.cr-picardie.fr;
           port 5555;
        };

        router 7500_UTC {
           ip-address 193.51.1.105;
           snmp-community netflow;

             netflow {
                version 5;
                dispatcher Nemesys;
             };
        };



5.3    Interfacenaming

In order to simply the IPFlow configurations, it is possible to rename the interfaces of router,
from the collector point of view. This allows the user to be independent from any
modification of an interface on router, which can happen when a given site migrates from an
interface to another one (for example when the physical link type changes). The main interest
of this function is to bind simpler names to the interfaces, easier to remember and to
manipulate, and to facilitate the search operations in log files (explained later).

The syntax to use is simple:

        router C6k-MSFC {
           ip-address 195.83.155.1;
           snmp-community netflow;

             netflow {
                version 5;
             };

             interface Vlan2 {
                rename-to “Internet”;
             };
             interface Vlan6 {
                rename-to “BF”;   /* « Benjamin Franklin » batiment network */
             };
        };




Christophe Fillot - 06/10/2005                                                             11/85
                                                                                  IPFlow Collector




6 Dispatching Service

The dispatching service (server part) is a feature completely integrated in the collector. So any
instance of the collector can act as a dispatcher.

The dispatching service is enabled with the « dispatching-process » section described below :

        dispatching-process {
           control-port <control_port>;
           protocol ipv4|ipv6;

             allowed-routers {
                <router_list>;
             };
        };


The routers for which dispatching has to be enabled must be explicity specified in the section
« allowed-routers ».

The control port defines the TCP port number used to receive membership join and leave
messages, exchanged between collectors and dispatcher. If no port is specified, the default
value is 5555.

The « protocol » statement allows the IP Protocol (IPv4 or IPv6) to be choosen. If nothing is
specified, the dispatcher will accept connections in IPv4 or IPv6 if supported by the operating
system.

Configuration example :

        router 7500_UTC {
           ip-address 193.51.1.105;
           snmp-community netflow;
           netflow {
              version 5;
           };
        };

        router 7500_CURI {
           ip-address 193.51.1.104;
           snmp-community netflow;
           netflow {
              version 5;
           };
        };

        dispatching-process {
           control-port 5555;
           allowed-routers {
              7500_UTC;
              7500_CURI;
           };
        };




Christophe Fillot - 06/10/2005                                                              12/85
                                                                              IPFlow Collector


Remark : it is possible to configure a collector to analyze flows (with aggregation, logging,
etc.) and to enable dispatching service simultaneously.




Christophe Fillot - 06/10/2005                                                          13/85
                                                                            IPFlow Collector




7 Sites

7.1     Site notion

The IPFlow collector use the notion of site to make classification of traffic from routers
easier. A Netflow packet contains (excepted for some aggregation schemes) source and
destination addresses. The site classification mechanism determines to which sites these
addresses belong.

A site is defined by the following :

-     A list of IPv4 networks ;
-     A list of IPv6 networks ;
-     A list of sites which belong to this site (hierarchical concept).

A given IPv4 or IPv6 network can be declared in more than one site. In this case, the IP
address to classify will belong to all the sites that contain this network.


7.2     Practical example

Suppose that we have two schools, named IUT_A and IUT_B, which use the networks shown
below :

-     SCHOOL_A : 192.168.1.0/24 and 192.168.2.0/24 ;
-     SCHOOL_B : 192.168.3.0/24 and 192.168.4.0/24 ;

The IPFlow configuration for those sites would be :

         site SCHOOL_A {
            networks {
               192.168.1.0/24;
               192.168.2.0/24;
            };
         };

         site SCHOOL_B {
            networks {
               192.168.3.0/24;
               192.168.4.0/24;
            };
         };


Imagine now that we want to group those sites in a general site called « SCHOOLS ». The
configuration would be then :

         site SCHOOLS {
            contains {
               SCHOOL_A;
               SCHOOL_B;
            };

Christophe Fillot - 06/10/2005                                                        14/85
                                                                                IPFlow Collector


        };


So, if the collector receives a Netflow record having 192.168.4.18 as source address, this
address will belong to sites SCHOOL_B and SCHOOLS simultaneously.

The site definitions can use multiple hierarchical levels :

        site Education {
           contains {
              SCHOOLS;
              Universities;
           };
        };



Remark : The definition order of sites in configuration file is totally free.


7.3    Managementof subnets

The IPFlow collector is able to use subnetting. Suppose that we have the following
configuration :

        site A {
           networks {
              192.168.1.0/24;
           };
        };

        site B {
           networks {
              192.168.1.0/25;
           };
        };


Therefore, IP addresses in range 192.168.1.0 – 192.168.1.127 will belong simultaneously to
sites A and B.


7.4    Specificsites

Two sites are automatically defined by IPFlow : « ANY » and « OTHER ». Every IP address
(IPv4 or IPv6) belongs to the site « ANY ». Every IP address which does not belong to any
site defined in the configuration file will belong to the site « OTHER ».

The « OTHER » site is therefore a simple way to check if a given IP address is located inside
or outside the managed network. In order to do this, the complete set of addresses must be
declared in the configuration file.




Christophe Fillot - 06/10/2005                                                            15/85
                                                                IPFlow Collector


7.5    Configuration

This paragraph summarizes the syntax used to declare a site :

        site <site_name> {
           networks {
              <ipv4_prefix>;
              …
              <ipv4_prefix>;
           };

             ipv6_networks {
                <ipv6_prefix>;
                …
                <ipv6_prefix>;
             };

             contains {
                <site_name>;
                …
                <site_name>;
             };
        };




Christophe Fillot - 06/10/2005                                            16/85
                                                                                   IPFlow Collector




8 Rules

The analysis rules define the actions (logging, counting, etc.) to apply to Netflow records
received from routers. A rule is composed of terms evaluated sequentially, given the order
specified in configuration file. Contrary to the access-lists (ACL), all the terms are evaluated,
unless otherwise specified.

Each term contains a list of criteria and a list of actions to execute when criteria have
matched. All criteria must match simultaneously to trigger the actions.

The first two criteria that can be used are source and destination sites. An access-list can be
optionally specified to select more precisely the type of traffic to match (mainly with layer 4
information, like TCP or UDP ports). Access-lists are described in the next chapter.

In order to match a rule term, source and destination IP addresses (v4 or v6) in the Netflow
record must belong to the sites specified in the rule term. If source and/or destination sites are
not defined, the collector use by default the « ANY » site (all addresses belong to this site).

If an access-list has been specified, the Netflow record must also match this ACL to have the
rule term evaluated positively.


8.1    Actions

When a rule term is matched, one or more actions can be applied to the received flow. For
example, actions can log the flow, colorize it or proceed to an aggregation. This paragraph
presents a summary of possible actions ; the details of configuration are studied in a specific
section for each action.


8.1.1 FlowColorization

To allow a real time display of flows at screen (like with tcpdump tool), it is possible to
colorize flows thanks to the keyword « color ». Possible colors are : « white », « red »,
« green », « yellow », « blue », « pink », « cyan », « bold-red », « bold-green », « bold-
yellow », « bold-blue », « bold-pink », « bold-cyan ».

Those colors are generated using ANSI codes, therefore it is necessary to have a terminal able
to recognize these codes.


8.1.2 Site Traffic Matrix

Those matrices allow the number of flows, packets and bytes exchanged between sites to
counted.

Christophe Fillot - 06/10/2005                                                               17/85
                                                                                    IPFlow Collector




Three modes exist :

•   Source : counting is done on source sites only ;
•   Destination : counting is done on destination sites only ;
•   Flow: counting is done between source and destination site

Remarks :

-   Counting is realized with source and destination IP addresses.
-   A site traffic matrix can be specified in the general configuration part of a rule.

The use of a site traffic matrix is realized using the keyword « site-traffic-matrix ».


8.1.3 Aggregation

Aggregators allow flows to aggregated according to a certain number of fields (protocol,
UDP/TCP ports, ToS, etc).

The use of an aggregator is done by using the keyword « aggregator ».


8.1.4 Logging

It is possible to log flows to a file thanks to the keyword « channel ». A channel can be a disk
file, or TCP/UDP/UNIX socket.


8.1.5 Port scandetection

The collector allows port scans on a set of hosts or on a particular host to be detected in real-
time.


8.1.6 IP AddressRewrite

In some cases, it can be interesting to rewrite source and/or destination IP addresses in flows
for a given interface on the router. This feature is often used to map IP addresses from
external networks (Internet) to one symbolical IP address, for example to reduce size of
aggregation tables.

It is important to keep in mind than once the addresses are rewritten, it not possible to use
their old contents. In the case where it is necessary to use « real » addresses and « mapped »
addresses, two instances of the collector must be started using the dispatching service.



Christophe Fillot - 06/10/2005                                                                18/85
                                                                                    IPFlow Collector


The following example shows the mapping of Internet addresses to IP address 0.0.0.0. The
interface which connects the network to Internet is supposed to be FastEthernet0/0 :

         router 7200 {
             ! […]

              interface FastEthernet0/0 {
                  rule-input rewrite_input;
                  rule-output rewrite_output;
              };
         };

         rule rewrite_input {
             term 1 {
                 rewrite-src-addr 0.0.0.0;
             };
         };

         rule rewrite_output {
             term 1 {
                 rewrite-dst-addr 0.0.0.0;
             };
         };


Remark : it is also possible to rewrite IPv6 addresses with the keywords « rewrite-ipv6-src-
addr » and « rewrite-ipv6-dst-addr ».


8.1.7 Termevaluation

Unless otherwise specified, all the terms of a rule are evaluated sequentially.

There are two ways to make a break in rule execution :

•     Stop of the rule evaluation, thanks to the statement « evaluation stop ». When a term
      which contains this statement is matched, the rule evaluation is immediately stopped.

•     Jump to another rule, thanks to the keyword « jump ». When a term is matched and is
      containing this keyword, the specified rule is evaluated. At the end of evaluation of this
      rule, the control is given back to the calling rule. This feature is similar to the notion of
      sub-programs.



8.2     Rule Binding

The rules allow specific actions to be applied to flows in function of criteria defined by the
administrator. In order to be used, rules must be bound to routers. There are three binding
methods :




Christophe Fillot - 06/10/2005                                                                19/85
                                                                               IPFlow Collector


      -     By input interface ;
      -     By output interface ;
      -     Global binding to the router, independently from the interfaces.

The syntax is described below :

           router <router_name > {
              interface <interface_name> {
                 ! Rule applied on input of interface
                 rule-input <rule_name>;

                     ! Rule applied on output of interface
                     rule-output <rule_name>;
                };

                ! Global rule
                rule <rule_name>;
           };


The collector analyzes the rules in this order :

                1. Input rule,
                2. Output rule,
                3. Global rule.


8.3       Configuration

This paragraph summarizes the syntax for a rule :

           rule <rule_name> {
              site-traffic-matrix <matrix_name>;

                term <term_name_1> {
                   source <site_name>;
                   destination <site_name>;

                     access-list <acl_name>;
                     aggregator <aggregator_name>;
                     site-traffic-matrix <matrix_name>;
                     scan-detector <detector_name>;

                     color <color_name>;
                     channel <channel_name>;

                     evaluation stop;
                     jump <rule_name>;

                     rewrite-src-addr <ipv4_address>;
                     rewrite-dst-addr <ipv4_address>;
                     rewrite-ipv6-src-addr <ipv6_address>;
                     rewrite-ipv6-dst-addr <ipv6_address>;
                };

                term <term_name_2> {
                   …
                };
                …
           };




Christophe Fillot - 06/10/2005                                                           20/85
                                 IPFlow Collector




Summary of possible colors :

-   white,
-   red,
-   green,
-   yellow,
-   blue,
-   pink,
-   cyan,
-   bold-red,
-   bold-green,
-   bold-yellow,
-   bold-blue,
-   bold-pink,
-   bold-cyan.




Christophe Fillot - 06/10/2005             21/85
                                                                                IPFlow Collector




9 Access-Lists (ACL)

IPFlow access-lists allow filters to be applied on traffic analyzed by rules. An access-list is
composed of terms evaluated sequentially in the order specified in configuration file. Once a
term is matched, the evaluation of access-list is stopped. IPFlow ACL are therefore very
similar to Cisco IOS ACL.

It is possible to specify the following criteria in ACL terms :

-     IP Protocol ;
-     Source and Destination Adresses (IPv4 or IPv6) ;
-     Source and Destination TCP/UDP/ICMP Ports ;
-     ToS (Type Of Service) Field ;
-     TCP Flags ;
-     Source and Destination Autonomous Systems (AS) ;
-     Flow duration ;
-     Number of packets in the flow ;
-     Number of bytes in the flow.

Remark : some fields may be not present in Netflow records given the version of Netflow
used, especially with aggregation schemes. The fields that are not present are automatically
set to zero by the collector.


9.1     Evaluation

The result of access-list evaluation is either « permit » or « deny ». When no term of the ACL
is matched, the implicit result is « deny ».

The result to return in a term is specified using the keyword « action » followed by « permit »
or « deny ».


9.2     Descriptionof the criteria


9.2.1 IP Protocol

The IP protocol is filtered with the keyword « protocol ». The protocol can be specified in the
form of a character string for common protocols (tcp, udp, icmp) or in the form of a 8-bit
number.

9.2.2 Sourceand DestinationIPv4 Addresses



Christophe Fillot - 06/10/2005                                                            22/85
                                                                               IPFlow Collector


Source and Destination IPv4 addresses are filtered thanks to the keywords « src-addr » /
« src-mask » and « dst-addr » / « dst-mask ».

Contrary to Cisco ACLs where masks are wildcard masks (where bits set to 0 are significant),
the IPFlow collector uses masks where bits set to 1 are significant (like network masks).

Example : the following filter matches address range 192.168.1.0 - 192.168.1.255 :

        src-addr 192.168.1.0;
        src-mask 255.255.255.0;



9.2.3 Sourceand DestinationIPv6 Addresses

The IPv6 addresses can be filtered using keywords « ipv6-src-addr » and « ipv6-dst-addr ».
Contrary to IPv4 addresses, IPv6 addresses must be specified in form of a CIDR prefix.

Example :

        ipv6-src-addr fec0:c000::/32;



9.2.4 ToS (Typeof Service)Field

The ToS field is filtered thanks to the keyword « tos-value » and « tos-mask ». Like for IPv4
addresses, significant bits must be set to 1 in the mask.


9.2.5 TCPFlags

The TCP flags are filtered with « tcp-flags » and « tcp-mask », which take a list of flags as
parameters :

-   « syn » : connection opening ;
-   « fin » : connection ending ;
-   « ack » : acknowledge;
-   « rst » : connection reset ;
-   « push » : buffered data to be sent to the application ;
-   « urg » : urgent data present.

Example :

        tcp-flags { syn; ack; };
        tcp-mask { syn; ack; rst; };


In this example, only the flows which have SYN and ACK bits set and RST bit set to zero
will be matched. The flag values not specified in the mask are ignored.



Christophe Fillot - 06/10/2005                                                           23/85
                                                                                 IPFlow Collector


Remarks :

•   It is important to keep in mind that TCP flags reported by Netflow are a logical OR
    combination of flags that have been seen in all packets of the flow.
•   It is strongly recommended to filter the IP protocol with « protocol tcp; » statement ;
    of course, TCP flags are undefined for protocols other than TCP.


9.2.6 Sourceand DestinationPorts

The source and destination ports are specified with statements « src-port » and « dst-port ». It
is possible to specify a port or a port range :

Example :

        src-port 25;
        dst-port 1024-65535;



9.2.7 Sourceand DestinationAS

Source and Destination Autonomous Systems can be filtered with keywords « src-as » et
« dst-as ».

Example :

        src-as 2200;



9.2.8 Duration

For each flow, the Netflow process running on a router maintains a timestamp for the first and
last received packets. The duration of a flow can therefore be easily determined by the
collector.

It is possible to specify a constraint on the duration of the flows in an ACL thanks to the
keyword « time-range », which takes a range of values as parameter, specified in
milliseconds.

Example :

        time-range 120000-180000;


In this example, only flows with a duration between 2 and 3 minutes will be matched.

Remark : when an high limit is not needed, it is sufficient to take an high value (for ex.
1.000.000.000) which will never be seen in practice.



Christophe Fillot - 06/10/2005                                                             24/85
                                                                                 IPFlow Collector


9.2.9 Numberof packetsand bytes

It is also possible to define a constraint on number of packets or bytes of the flow thanks to
the keywords « packet-range » and « size-range », which take both a range as parameter.


9.3     Optimization

Any ACL being evaluated sequentially, a too huge number of terms may have a negative
impact on the collector performance, especially if the most often matched terms are located
near the end of the ACL.

It is possible to compile the access-lists to obtain a constant time for their evaluation,
independently of the number of terms. This feature is very similar to the Turbo ACL feature
available in some IOS releases.

An ACL cannot be compiled if at least one the following criteria are used in a term :

-     Source or Destination Autonomous Systems (AS) ;
-     Flow Duration ;
-     Number of packets in flow ;
-     Number of bytes in flows ;
-     IPv6 fields.

Remarks :

•     The attempt to compile an ACL with the criteria mentioned above will fail during the
      collector startup, but will not cause any problem at use.
•     The compilation can be enabled on a per-ACL basis, contrary to IOS where all ACL are
      systematically compiled when using « access-list compiled » command.
•     The collector allows you to show useless terms of an ACL when it is compiled, provided
      that the statement « show-unused-terms yes » is present in the global configuration of the
      ACL. Indeed, the compilation algorithm can determine terms that will be never matched
      by any flow.




Christophe Fillot - 06/10/2005                                                             25/85
                                                              IPFlow Collector


9.4    Configuration

      access-list <acl_name> {
         compiled-mode enable|disable;
         show-unused-terms yes|no;

           term <term_name_1> {
              action permit|deny;
              protocol tcp|udp|icmp|<numero>;
              tos-value <tos_value>;
              tos-mask <tos_mask_value>;
              tcp-flags { syn; ack; urg; push; fin; rst; };
              tcp-mask { syn; ack; urg; push; fin; rst; };
              src-addr <ip_address>;
              src-mask <ip_address>;
              dst-addr <ip_address>;
              dst-mask <ip_address>;
              ipv6-src-addr <ipv6_prefix>;
              ipv6-dst-addr <ipv6_prefix>;
              src-port <port>|(<start_port>-<end_port >);
              dst-port <port>|(<start_port>-<end_port >);
              src-as <AS_number>;
              dst-as <AS_number>;
              time-range <start_value>-<end_value>;
              size-range <start_value>-<end_value>;
              packet-range <start_value>-<end_value>;
           };

           term <term_name_2> {
              …
           };

           …
      };




Christophe Fillot - 06/10/2005                                          26/85
                                                                                   IPFlow Collector




10 Channels

The channels allows the user to log flows in text or binary format on disk or into a TCP, UDP,
or Unix socket. Each channel is identifier by a unique name that is used as reference in other
sections of the configuration file (see especially the rule configuration).


10.1 Text and BinaryFiles

The IPFlow collector enables the user to store data in two types of files : the text files and the
binary files.


10.1.1 Text Files

The text files are easily readable by the human eye, thanks to classic unix commands like
“cat”, “grep”, etc, but have for disadvantages to consume a lot of disk space and are not
adapted for fast analysis by a computer. With a text file, the user can specify the way to
format the output in order to keep only fields that interest him.


10.1.2 BinaryFiles

The binary files are not readable by the human eye, but they offer an optimimum use of disk
space for data storage and permits a computer to make fast post-treatments. Only disk storage
is possible with this type of channel (sockets are not supported). For these files, the user must
specify what Netflow fields must be stored for each record.

The following utilities (detailed more precisely in other chapters) allows the user to
manipulate binary flow files:

        - flow_info : to get information about the file ;
        - grep : to make a multi criteria search ;
        - top : data aggregation, can be used to find top-talkers ;
        - sdraw : to realize some traffic graphs (with RRDTool).
        -
In a binary file, the flow are continuously written, whereas in a binary file, flows are written
in a structure organized in sections. The sections are configured by the user that determines
the interval between two sections. By default, this interval is fixed to 5 minutes, and can be
modified with the “time-mark” statement, with a number of seconds.

In this example, the user chooses to write sections with an interval of 5 minutes, beginning at
12:00 :



Christophe Fillot - 06/10/2005                                                               27/85
                                                                                      IPFlow Collector



            section0
                                  For instance, the section 0 corresponds to all flows stored
             Flow0                between 12:00 and 12:05. The section 1 corresponds to all
             Flow1                flows stored between 12:05 and 12:10.
             Flow2
             Flow3                It is important to note that section numbers begin at 0.
            section1
                               The structure of binary files is interesting. Indeed, it is
             Flow0
             Flow1
                               possible to position itself in the file, in function of flows and
             Flow2             sections. Suppose that a user wants to access to the flow n°2 of
                               the section n°1. In order to avoid reading all the file (which
           section2            can represent in some cases a huge time loss), he can use the
following options with “grep”, “top” and “sdraw” IPFlow utilities:

        -    --count |-c <arg>
        -    --last <arg>
        -    --start <arg>
        -    --section-count <arg>
        -    --section-last <arg>
        -    --section-start <arg>

With the previous example, the user would type:

                       ipflow grep --section-start 1 -–start 2 binary.log

If he wants to read the last two sections of the file, he should type :

                       ipflow grep --section-last 2 binary.log

The --count, --last et –start options are used to set position in the files in function of flows :

        -    --start indicates the number of the starting flow ;
        -    --last indicates the number of flows to read, from the end of file ;
        -    --count indicates the number of flows to read.

The --section/-count/-last/-start options are used to set position in the files in function of
sections :

        -    --section-count indicates the number of sections to read ;
        -    --section-last indicates the number of sections to read, from the end of file ;
        -    --section-start indicates the beginning section.

It is possible to use simultaneously many options. The --section-last et --last options must be
used alone.

If the flow positioning options are used with section positioning options, the flows to analyze
will be restricted to in the specified sections.



Christophe Fillot - 06/10/2005                                                                  28/85
                                                                                  IPFlow Collector




                       ipflow grep --section-start 1 --section-count 2 --last 1000

The flows that would be read would be the last 1000 flows from the section 1, and spreading
on two sections.

The sections are written with a default interval of 300 seconds (5 minutes). The ‘time-mark
<arg>’ statement in the channel configuration allows the user to modify this interval.


10.1.3 « Site Traffic Matrices» (STM)Files

The site traffic matrices allows to count the traffic emitted or received by sites defined in the
collector configuration. It is recommended to read the chapter explaining specifically how
these matrices work to understand them precisely.

It is possible to record the contents of these matrices by using STM files. The STM files are
binary files, and it is important to keep in mind that this kind of file can only record one
matrix.

Two utilities exist to manipulate these files : « stm_info » allows the user to know
characteristics of a STM file, whereas « stm_fetch » permits to fetch data from an STM file
and to write them to screen or to fill an RRDTool file.

Three types of matrices exist :
       - source matrices,
       - destination matrices,
       - « full-flow » matrices.

It is important to note that “ANY” and “OTHER” sites are implicitly included in all matrices.

A source or destination matrix has the following aspect. In function of the case, sites are
considered are source sites or destination sites:

                               Flows         Packets                    Bytes
        site 1
        site 2
        site 3
        site 4

For each site, there are three counters : number of flows, packets and bytes.


The « full-flow » matrices are bilinear matrices which are like this :

                      Site 1              site 2               site 3               site 4

    site 1       flows/packes/bytes


Christophe Fillot - 06/10/2005                                                               29/85
                                                                                    IPFlow Collector



    site 2

    site 3

    site 4

For each pair (site i, site j), there are three counters : number of flows, packets and bytes.


10.2 Logginginto a file

The more classical approach for channel use is to log flows into a disk file.

The configuration would be as described below :

        channel <channel_name> {
            filename ″filename ″;
        };


It is possible to use terminal output from the collector by using the special file
« /dev/tty ». This special file can be used by many channels simultaneously.

Important remark : if the channel corresponds to a binary file, the contents of the file are
kept by the collector. However, the flows are stored by using the format previously used in the
file, and not by using the format defined in the collector configuration. For text fields, the data
are added at the end of the file (« append » mode), in a format that can be different.


10.3 Logginginto a TCP/UDPsocket

Logging into a TCP or UDP socket requires two parameters : the hostname or IP address of
destination host and the destination port of the client application. The syntax is given below :

        channel <channel_name> {
            protocol tcp|udp;
            hostname <hostname_or_ip_address>;
            port <tcp_or_udp_port_number>;
        };


Example :

        channel Host_1 {
            protocol tcp;
            hostname nemesys.rrt.cr-picardie.fr;
            port 3000;
        };


Remark : IPv4 and IPv6 protocols are fully supported.




Christophe Fillot - 06/10/2005                                                                   30/85
                                                                                    IPFlow Collector


10.4 Logginginto an UNIXsocket

Logging into an UNIX socket allows flow data to be sent easily to a program running on the
same host. Contrary to TCP or UDP, an UNIX socket requires a special file to be created on
disk to work.

The collector configuration is given below :

        channel <channel_name> {
            protocol unix;
            filename ″filename ″;
        };



10.5 LogFormat

It is often preferable to define a customized format for log output, especially to log only
interesting fields of flows. The Log Formats give this possibility to the user.

A log format is identified by a unique name and can be bound to one or many channels, with
the keyword « log-format » specified in channel configuration.

Log Formats are described precisely in the following chapter.


10.6 LogRotation

In order to simplify log archiving (text or binary files), the collector has a log rotation feature,
that allows to rotate files on disk.

To distinguish the files, the date of creation is stored in the filename, for example "test-%Y%
m%d.log " (containing year, month and day). The time statements are given in the manual
page of “strftime” (use “man strftime” to known all of them).

The most important are :

-       %H : hours (0 to 23),
-       %M : minutes (0 to 59),
-       %S : seconds (0 to 59),
-       %d : day of the month (1 to 31),
-       %b : abbreviated month name,
-       %m : month (1 to 12)
-       %Y : year (on 4 digits),
-       %y : year (the last two digits).


10.6.1 TriggeringCriteria


Christophe Fillot - 06/10/2005                                                                 31/85
                                                                                 IPFlow Collector


There are two possibilities to trigger the rotation :

-       The number of flows in the file,
-       Periodically (for example every day).


10.6.2 Configurationexamples

The following example shows how to make a rotation every day :
        channel test {
            filename ²test-%Y%m%d.log²;

              rotation {
                  interval 1440;       ! 1440 minutes = 1 day
              };
        };


The files would be named :

-       test-20031225.log
-       test-20031226.log
-       …

The following example shows how to make a rotation when 10000 flows have been written :

        channel test {
            filename ²test-%Y%m%d-%H%M.log²;

              rotation {
                  flow-limit 100000;       ! 1440 minutes = 1 day
              };
        };


The files would be named (depending when the rotation occurs) :

-       test-20031225-1210.log
-       test-20031225-1403.log
-       test-20031226-0801.log
-       …


10.7 SpecificOptionsof binaryfiles

The collector offers the possibility to record a description and a text log format to facilitate
management of binary files.

The configuration is as follows :




Christophe Fillot - 06/10/2005                                                             32/85
                                                                               IPFlow Collector


        channel <channel_name> {
            filename ″file_name ″;

              options {
                  description <description_string>;
                  format <text_log_format>;
              };

              time-mark <interval_between_sections_in_seconds>;

              rotation {
                  interval <number_of_minutes>;
                  flow-limit <maximum_number_of_flows>;
              };
        };



The log format string allows a default display format to be specified for the file, when using
tools like IPFlow Grep. It is recommended to read the chapter « Log Formats » to obtain a
complete description of the log format fields.


10.8 Configuration

        channel <channel_name> {
            protocol tcp|udp|unix|file;
            filename ″filename ″;
            hostname <host>;
            port <tcp_or_udp_port >;
            log-format <log_format_name>;

              rotation {
                  size <file_size>;
                  interval <number_of_minutes>;
                  count <rotation_period>;
                  compression yes|no;
              };
        };




Christophe Fillot - 06/10/2005                                                           33/85
                                                                                   IPFlow Collector




11 Log Formats

11.1 Principle

The Log Formats enable the user to define easily information to log into output files or
sockets (see channel configuration chapter), either by specifying a character string with
needed netflow fields (text files), or by specifying a list of fields to store (binary files). Flow
data can therefore be managed in a customizable way.

In summary, the goal of channels is to provide an abstraction layer for flow storage.


11.2 FormatString(text files)

The text log formats are defined using a string, whose principle is very similar to C functions
like printf(), sprintf(), etc. Netflow fields are specified under the form « %{field_name} » in
this string.

Imagine that we have the following log format :

        log-format Text_Format {
           string ″%{router} : %{ipv4-src-addr} > %{ipv4dst-addr}\n″;
        };


An output example would be :

        cisco-7200 : 192.168.1.1 > 195.30.1.1
        gw1 : 130.1.1.15 > 172.16.30.254


It is possible to apply a specific alignment, like those possible with printf().

If we take the previous example, but with some alignment information :

        log-format Text_Format {
           string ″%-12s{router} : %-15s{ipv4-src-addr} > %-15s{ipv4-dst-addr}\n″;
        };


The output would be then :

        cisco-7200       : 192.168.1.1      > 195.30.1.1
        gw1              : 130.1.1.15       > 172.16.30.254


The list of existing fields is given in the next paragraph.




Christophe Fillot - 06/10/2005                                                                34/85
                                                                            IPFlow Collector


11.2.1 Field Specification

It is possible to use the following fields:

                                                                                   Default
         Field name                       Description          Type                Format
router                    Router                              String                %s
router-addr               RouterAddress                       String                %s
ipv4-src-addr             IPv4 SourceAddress                  String                %s
ipv4-dst-addr             IPv4 DestinationAddress             String                %s
ipv4-src-prefix           IPv4 SourcePrefix                   String                %s
ipv4-dst-prefix           IPv4 DestinationPrefix              String                %s
ipv4-nexthop              IPv4 Next-Hop                       String                %s
ipv4-bgp-nexthop          IPv4 BGPNext-Hop                    String                %s
ipv6-src-addr             IPv6 SourceAddress                  String                %s
ipv6-dst-addr             Ipv6 DestinationAddress             String                %s
ipv6-src-prefix           IPv6 SourcePrefix                   String                %s
ipv6-dst-prefix           IPv6 DestinationPrefix              String                %s
ipv6-nexthop              IPv6 Next-Hop                       String                %s
ipv6-bgp-nexthop          IPv6 BGPNext-Hop                    String                %s
ipv6-flow-label           IPv6 FlowLabel                      Integer               %u
ipv6-options-headers      IPv6 OptionsHeaders                 Integer              %4.4x
src-port                  SourcePort                          Integer               %u
dst-prt                   DestinationPort                     Integer               %u
protocol                  IP Protocol                         Integer               %u
src-mask                  SourceMask                          Integer               %u
dst-mask                  DestinationMask                     Integer               %u
src-as                    SourceAutonomousSystem              Integer               %u
dst-as                    DestinationAutonomousSystem         Integer               %u
tos                       IP TypeOf Service(TOS)              Integer               %u
ref-count                 AggregatorReferenceCount            Integer               %u
tag                       FlowTag                             Integer               %u
duration                  Duration                            Integer               %u
timestamp                 FlowTimestamp                       Integer               %llu
mpls-label-1              MPLSLabel at Position1              Integer              %3.3x
mpls-label-2              MPLSLabel at Position2              Integer              %3.3x
mpls-label-3              MPLSLabel at Position3              Integer              %3.3x
mpls-label-4              MPLSLabel at Position4              Integer              %3.3x
mpls-label-5              MPLSLabel at Position5              Integer              %3.3x
mpls-label-6              MPLSLabel at Position6              Integer              %3.3x
mpls-label-7              MPLSLabel at Position7              Integer              %3.3x
mpls-label-8              MPLSLabel at Position8              Integer              %3.3x
mpls-label-9              MPLSLabel at Position9              Integer              %3.3x
mpls-label-10             MPLSLabel at Position10             Integer              %3.3x
flows                     Numberof Flows                      Integer               %u
packets                   Packetsin Flow(32-bit counter)   32-bit Integer           %llu
bytes                     Bytesin Flow(32-bit counter)     32-bit Integer           %llu
packets- 64               Packetsin Flow(64-bit counter)   64-bit Integer           %llu
bytes-64                  Bytesin Flow(64-bit counter)     64-bit Integer           %llu
proto-num                 IP Protocol                         Integer              %2.2u
proto-str                 IP Protocol                         String                %s


Christophe Fillot - 06/10/2005                                                        35/85
                                                                                IPFlow Collector


tcp-flags                 TCPFlags                                                        n
input-ifindex             Input InterfaceIndex                       Integer             %u
output-ifindex            OutputInterfaceIndex                       Integer             %u
input-ifname              Input InterfaceName                        String              %s
output-ifname             OutputInterfaceName                        String              %s
vlan-id                   VLANIdentifier                             Integer             %u
template-  id             TemplateID                                 Integer             %u
template-  model          TemplateModel                              String              %s
date                                   M DD)
                          Date (YYYY- M-                             String              %s
time                      Time(hh:mm:ss)                               N/A               N/A
                          Unix Time(numberof secondssince 1970-01-
unixtime                  01)                                         N/A                N/A
ctime                     CustumTimeFormat(see strftimemanpage)
color-set                 Set Color                                   N/A                N/A
color-reset               Reset Color                                 N/A                N/A



The user can display all recognized fields in a particular IPFlow version by using the « ipflow
log_formats » command.

Important Remark : it is essential to respect the type indication given in the previous array,
especially please pay attention to string / integer distinction.


11.2.2 Special Fields

Some fields have particular properties or specific uses :

•   TCP Flags: « tcp-flags » ;
•   Date and Hour of flow start : « date » et « time » ;
•   Colorization : « color-set » et « color-reset ».


11.2.2.1 TCPFlags

By default, TCP flags are viewed under numeric form, in hexadecimal (with format « %2.2x).

It is possible to view these flags with a more readable form, by using a string format. Each
flag will be then defined by a character :

-   S : Syn
-   F : Fin
-   R : Rst
-   A : Ack
-   U : Urg
-   P : Push




Christophe Fillot - 06/10/2005                                                            36/85
                                                                                IPFlow Collector


11.2.2.2 Date and Hour

Date is logged under the format YYYY-MM-DD with :

-   YYYY = Year ;
-   MM = Month ;
-   DD = Day.

Hour is logged under the format HH:MM:SS.MMM with :

-   HH = Hours ;
-   MM = Minutes ;
-   SS = Seconds ;
-   MMM = Milliseconds.

To specify a specific format for hour and date, it is recommended to use the « ctime »
statement. This statement provides the user a more customizable way to display hour and date.
It relies on the C ANSI function « strftime() ». The user is advised to read the manual page of
this function to know all of its powerful capabilities.

The more important are :

-   %H : hours (0 to 23),
-   %M : minutes (0 to 59),
-   %S : seconds (0 to 59),
-   %d : day of the month (1 to 31),
-   %b : abbreviated month name,
-   %m : month (1 to 12)
-   %Y : year (on 4 digits),
-   %y : year (2 digits, century omitted).

Example :

        log-format Text_Format {
           string ″%H:%M{ctime} %{router} : %{ipv4-src-addr} > %{ipv4-dst-addr}\n″;
        };



11.2.2.3 Colors

As it has been said in chapter concerning rules, it is possible to colorize flows for screen
output with the keyword « color » specified in a rule term. This colorization system relies on
ANSI codes to work.

To emit these codes, the format statement « %{color-set} » must be used. To cancel the color
effect (and to go back to standard options of the terminal), use the statement %{color-reset}.



Christophe Fillot - 06/10/2005                                                            37/85
                                                                                  IPFlow Collector


11.3 Field List (binaryfiles)

When a binary file has to be produced, the user must specify the list of fields to store for each
flow. This permits the file size to be reduced since only interesting fields for user are
recorded.

The syntax to use is given below :

        log-format Binary_Format {
           fields {
              < field_name_1 >;
              …
              < field_name_n >;
           };
        };


The field names are defined in the following array :

              Field name                            Description
     router                      Router
     ipv4-src-addr               IPv4 SourceAddress
     ipv4-dst-addr               IPv4 DestinationAddress
     ipv4-nexthop                IPv4 Next-Hop
     ipv4-bgp-nexthop            IPv4 BGPNext-Hop
     ipv6-src-addr               IPv6 SourceAddress
     ipv6-dst-addr               IPv6 DestinationAddress
     ipv6-nexthop                IPv6 Next-Hop
     ipv6-bgp-nexthop            IPv6 BGPNext-Hop
     ipv6-flow-label             IPv6 FlowLabel
     ipv6-options-headers        IPv6 OptionsHeaders
     src-port                    SourcePort
     dst-port                    DestinationPort
     protocol                    IP Protocol
     src-mask                    SourceMask
     dst-mask                    DestinationMask
     src-as                      SourceAutonomousSystem
     dst-as                      DestinationAutonomousSystem
     tos                         IP TypeOf Service(TOS)
     ref-count                   AggregatorReferenceCount
     tag                         FlowTag
     duration                    Duration
     timestamp                   FlowTimestamp
     mpls-label-1                MPLSLabel at Position1
     mpls-label-2                MPLSLabel at Position2
     mpls-label-3                MPLSLabel at Position3
     mpls-label-4                MPLSLabel at Position4
     mpls-label-5                MPLSLabel at Position5
     mpls-label-6                MPLSLabel at Position6
     mpls-label-7                MPLSLabel at Position7
     mpls-label-8                MPLSLabel at Position8
     mpls-label-9                MPLSLabel at Position9
     mpls-label-10               MPLSLabel at Position10


Christophe Fillot - 06/10/2005                                                              38/85
                                                                                IPFlow Collector


     flows                       Numbersof Flows
     packets                     Packetsin Flow(32-bit counter)
     bytes                       Bytesin Flow(32-bit counter)
     packets-  64                Packetsin Flow(64-bit counter)
     bytes- 64                   Bytesin Flow(64-bit counter)
     tcp-flags                   TCPFlags
     input-ifindex               Input InterfaceIndex
     output-ifindex              OutputInterfaceIndex
     vlan-id                     VLANIdentifier
     template-  id               TemplateID



It is possible to specify any combination of fields.

Example :

        log-format Binary_Format {
           fields {
              ipv4-src-addr;
              ipv4-dst-addr;
              protocol;
              tos;
           };
        };



11.4 Default Format

When using a channel without any log format specified, the file will be in text format and the
log format will be set by default to :

« %{color-set}%-12s{router} %{date} %{time} | 
%-15s{ipv4-src-addr} | %-15s{ipv4-dst-addr} | 
%-4s{proto-str} %5u{src-port} %5u{dst-port} | P: %5Lu{packets} | S: %7Lu{bytes} | 
T: %6u{duration} | %-22s{input-ifname} -> %{output-ifname} %{color-reset}\n »


Example :

« 7500_UTC             2002-05-13 10:44:36.324 | 195.221.156.8    | 195.134.210.10   | 
TCP 61255             80 | P:     6 | S:     685 | T: 284 | 
ATM0/1/0.10                    -> ATM0/1/0.2 »


This string contains :

-   Router name (« 7500_UTC »),
-   Date and Hour (« 2002-05-13 10:44:36.324 »),
-   Source Address (« 195.221.156.8 »),
-   Destination Address (« 195.134.210.10 »),
-   IP Protocol (« TCP »),
-   Source Port (« 61255 »),
-   Destination Port (« 80 »),
-   Number of packets (« P : 6 »),
-   Number of bytes (« S : 685 »),
Christophe Fillot - 06/10/2005                                                             39/85
                                                                             IPFlow Collector


-   Flow duration in milliseconds (« T : 284 »),
-   Source Interface (« ATM0/1/0.10 »),
-   Destination Interface (« ATM0/1/0.2 »).

Remark : the size of this log format is huge and it is recommended to use a terminal with a
high number of columns, in order to not cut flow data display.




Christophe Fillot - 06/10/2005                                                         40/85
                                                                                    IPFlow Collector




12 Site Traffic Matrices


12.1 Principle

The site traffic matrices are an easy way to count traffic exchanges between sites. There are
three modes of counting :

   •   « Source » mode : counting is done on source site basis ;
   •   « Destination » mode : counting is done destination site basis ;
   •   « Flow » mode : counting is done for each pair (source site, destination site).

For the first two modes, data are therefore stored in form of vectors, whereas the third mode
creates an inter-site traffic matrix.

The counters contain three fields :

   •   Number of Flows ;
   •   Number of Packets ;
   •   Number of Bytes.

A source or destination matrix has the following aspect. In function of the case, sites are
considered are source sites or destination sites:

                               Flows         Packets                     Bytes
        site 1
        site 2
        site 3
        site 4

For each site, there are three counters : number of flows, packets and bytes.

The « full-flow » matrices are bilinear matrices which are like this :

                      Site 1              site 2                site 3                site 4

    site 1       flows/packes/bytes

    site 2

    site 3

    site 4

For each pair (site i, site j), there are three counters : number of flows, packets and bytes.



Christophe Fillot - 06/10/2005                                                                   41/85
                                                                                  IPFlow Collector


12.2 Configuration

The configuration of a matrix is simple :
        site-traffic-matrix <matrix_name> {
           mode source|destination|flow;
        };


Please note that matrices include counters for all sites or all site pairs, therefore there is no
need to define sites for which traffic has to be counted.. The two special sites ANY and
OTHER, automatically created by the collector, are also managed.

Results collected by a matrix can then be stored in a RRDTool database.


12.3 Practical example

Imagine a network that provides Internet access to two schools A and B, and to other sites
(universities, etc.). We want to know proportion of Internet traffic for these two schools, and
total traffic for schools.




Christophe Fillot - 06/10/2005                                                              42/85
                                                                                 IPFlow Collector


The configuration would be as follows :

        site School_A {
           networks {
              195.1.1.0/24;
              195.1.2.0/24;
           };
        };

        site School_B {
           networks {
              193.128.1.0/24;
              193.128.2.0/24;
           };
        };

        site Schools {
           contains {
              School_A;
              School_B;
           };
        };

        site-traffic-matrix Internet_Counting {
           mode source;
        };

        router Cisco7200
        {
           ! Internet Access on ATM5/0.1
           interface ATM5/0.1 {
              rule-output Internet_Output;
           };
        };

        rule Internet_Output {
           term 1 {
              source ANY;
              destination ANY;
              site-traffic-matrix Internet_Counting;
           };
        };


The « Internet_Counting » matrix will count traffic from sites School_A, School_B, Schools,
ANY and OTHER.

It is therefore simple with this matrix to determine proportion of school traffic compared to
the global traffic (given by « ANY » site counters).

It is important to keep in mind that one IP address can match many sites, and so that many
sites can see their counters grow simultaneously for a given IP address.

On the example mentioned above, reception of traffic from network 195.1.1.0/24 will update
counters for sites : « School_A », « Schools » and « ANY ».


12.4 File storage

It is possible to store the contents of the matrices in a binary file on disk, using channels of
“STM” type.

Christophe Fillot - 06/10/2005                                                             43/85
                                                                                    IPFlow Collector




We can take the following example :

        site-traffic-matrix matrix {
           mode flow;
           flush-interval 60;
           channel stm_file;
        };

        channel stm_file {
           mode source;
           filename « test-stm.log »;
        };


The « flush-interval » statement indicates that the matrix must be written into the file every 60
seconds. The « channel » statement gives the STM file to use for output. Every time the
matrix is written, a section is created in the output file, consequently this offers the possibility
to know the evolution of matrix during time. Lets recall that only one matrix can be written by
STM file.

If the user wishes to write the matrix with a huge period (for example every hour or every
day), it can be useful for him to use the synchronization to update more frequently the output
file. Compared to a “normal” write, the collector will update only the last written section
(without creating a new one), this section being marked as “partial”.

We can imagine the following configuration :

        site-traffic-matrix matrix {
           mode flow;
           flush-interval 86400;     /* 1 full write by day */
           synchronization 60;       /* synchronization every minute */
           channel stm_file;
        };

        channel stm_file {
           mode stm;
           filename « test-stm.log »;
        };


In this example, we store the contents of the matrix once a day. However, without
synchronization, if the collector is brutally stopped, data can be lost. Moreover, the up-to-date
information is only available after the write operation, this means that information about the
current day are not accessible (since stored in the memory used by the collector).

To avoid these problems, we use in this example a synchronization every minute. So it is
possible to access to the contents of the matrix for the current day at every time.




Christophe Fillot - 06/10/2005                                                                 44/85
                                                                              IPFlow Collector




13 Aggregators

13.1 Principle

Aggregators allow flow data to aggregated under any combination of the following fields :

    -   IPv4 Source and Destination Addresses : « ipv4-src-addr » and « ipv4-src-addr »
    -   IPv6 Source and Destination Addresses : « ipv6-src-addr » and « ipv6-dst-addr »
    -   IPv4 and IPv6 Next-Hop Addresses : « ipv4-next-hop » and « ipv6-next-hop »
    -   IP Protocol : « protocol »
    -   IP ToS (Type Of Service) field : « tos »
    -   TCP/UDP Source and Destination Ports : « src-port » et « dst-port »
    -   TCP Flags : « tcp-flags »
    -   Source and Destination AS : « src-as » et « dst-as »
    -   Router : « router »
    -   Input and Output interfaces : « input-ifindex » et « output-ifindex ».

The way of how aggregators work is therefore similar to aggregation schemes available with
Netflow v8.


13.2 Configuration

The syntax to define a new aggregator is :

        aggregator <aggregator_name> {
           max-entries <number>;
           entries-per-chunk <number>;
           hash-entries <number>;
           flush-interval <interval_in_seconds>;
           channel <channel_name>;

             fields {
                tos;
                protocol;
                tcp-flags;
                ipv4-src-addr;
                ipv4-dst-addr;
                ipv4-next-hop;
                ipv6-src-addr;
                ipv6-dst-addr;
                ipv6-next-hop;
                src-as;
                dst-as;
                src-port;
                dst-port;
                router;
                if-input;
                if-output;
             };
        };

The fields used for aggregation must be specified in « fields » section.


Christophe Fillot - 06/10/2005                                                            45/85
                                                                                   IPFlow Collector


The « flush-interval » statement defines when the aggregator entries have to be flushed. The
default value is 60 seconds. All the entries are flushed simultaneously.

If a channel is specified, aggregator entries are sent to this channel when flushing occurs. It is
strongly recommended to bind a custom log-format to this channel in order to keep only
appropriate data.

Example :
        log-format ACCT {
           string “%H:%M{ctime} %-16s{ipv4-src-addr} %-16s{ipv4-dst-addr} \
        %6u{flows} %6Lu{packets} %6Lu{bytes}\n”;
        };

        channel WEB_Accounting {
           filename ″web_acct.log″;
           log-format ACCT;
        };

        aggregator WEB {
           max-entries 16384;

             flush-interval 60;
             channel WEB_Accounting;

             fields {
                ipv4-src-addr;
                ipv4-dst-addr;
             };
        };

        router 7500_CURI {
           ip-address 193.51.1.104;
           snmp-community netflow;

             netflow {
                version 5;
                receiver-port 8000;
             };

             rule R1;
        };

        rule R1 {
           term 1 {
              source ANY;
              destination ANY;
              access-list HTTP;
              aggregator WEB;
           };
        };

        access-list HTTP {
           term 1 {
              action permit;
              protocol tcp;
              dst-port 80;
           };
        };




Christophe Fillot - 06/10/2005                                                               46/85
                                                                                   IPFlow Collector


13.3 File storage(precisions)

As we saw it previously, it is possible to store the contents of aggregators in binary files using
channels.

Lets take an example :

        aggregator agg {
           /* … définition de l'agrégateur … */
           flush-interval 60;
           channel fichier_agg;
        };

        channel fichier_agg {
           filename " essai-agg.log ";
        };


The "flush-interval" statement indicates that the aggregator entries must be written into the
file every 60 seconds. The "channel" statement indicates the binary file to use. Every time the
aggregator is written, a section is added to the output file. It is important to note that only one
aggregator can be stored into an output file.

If the user wishes to write the aggregator with a huge period (for example every hour or every
day), it can be useful for him to use the synchronization to update more frequently the output
file. Compared to a “normal” write, the collector will update only the last written section
(without creating a new one), this section being marked as “partial”.

Image the following configuration :

        aggregator agg {
           /* … */
           flush-interval 86400;        /* 1 full write for a day */
           synchronization 60;          /* synchronization every minute */
           channel agg_file;
        };

        channel agg_file {
           filename "test-agg.log ";
           log-format agg-format;    /* log-format for output into file */
        };


In this example, we store the contents of the aggregator once a day. However, without
synchronization, if the collector is brutally stopped, data can be lost. Moreover, the up-to-date
information is only available after the write operation, this means that information about the
current day are not accessible (since stored in the memory used by the collector).

To avoid these problems, we use in this example a synchronization every minute. So it is
possible to access to the contents of the aggregator for the current day at every time.


13.4 Tuning




Christophe Fillot - 06/10/2005                                                                47/85
                                                                                 IPFlow Collector


It is possible to improve the internal work of an aggregator depending of its usage, for
example when a huge number of flows are stored. Two parameters exist for this goal: “hash-
entries” and “entries-per-chunk”.

An aggregator uses an hash table to retrieve aggregated flows. To avoid collisions in this table
when a huge number of flows are stored, it can be useful to increment the size of this table
with the “hash-entries” statement. By default, the number of entries is 32768.

The second parameter that can be modified is the number of entries in a chunk. An aggregator
does not allocate memory for each flow to aggregate, it allows a block (called “chunk”)
containing room to store a large number of flows. When a chunk is completely filled, the
aggregator allocates a new one. It is possible to modify the number of entries for a chunk
thanks to the “entries-per-chunk” parameter. By default, the number of entries for a chunk is
4096.




Christophe Fillot - 06/10/2005                                                             48/85
                                                                                  IPFlow Collector




14 Port Scans Detection

The detection of port scans « in real-time » is a recently added feature in the collector, which
allows you to look for port scan activity, but also floods. Currently, it is possible to detect
scans launched by tools like « NMAP » with a relatively good efficiency.

It is important to keep in mind that at this time, the detection algorithm is based on threshold
values that must be not hit. Therefore it is difficult to detect « slow » scans, where probe
interval is set to an high value.


14.1 Horizontaland Vertical Scans

Two port scan types can be detected by the collector :

   -   « Horizontal » scans: the attacker scans a particular host on a large number of services;
   -   « Vertical » scans: the attacker scans a range of networks for one or many services.

Please note that analysis is based on source address, therefore scan detectors must be applied
on the interface connected to the « suspect » network (generally, the Internet access).


14.2 Thresholdssetup

The scan detection work on a time interval specified by the user. Following the type of
detection (horizontal or vertical scans), and if flows exceed the threshold value defined by the
user, a notification is emitted.


14.3 Notifications

When a scan is detected, it is possible to log a message immediately (immediate notification)
or at the end of detection interval (differed notification).

The interest of differed notification is to allow the user to know number of flows, packets and
bytes emitted by the scanning host. This permits then detection parameters to be adjusted.


14.4 Example

The following example presents a configuration that show how works a scan detector, for
horizontal scan detection.

When more than 1000 flows or more than 100000 packets have been emitted by an host
located outside of the network, a notification is logged immediately after the detection.

Christophe Fillot - 06/10/2005                                                              49/85
                                                                                   IPFlow Collector




When the value indicated by the « threshold » statement is exceeded, a notification message is
emitted immediately when the detection occurs.

        log-format scan_format {
            string "Warning: Detected probable scan from %{ipv4-src-addr}.\n";
        };

        channel scans {
            filename "scans.log";
            log-format scan_format;
        };

        scan-detector detection {
            type vertical;
            notification immediate;
            flush-interval 1;             ! Analysis on one minute.

              threshold 1000;

              report-channel scans;
        };

        rule internet {
            term scan_detect {
                scan-detector detection;
            };
        };



« report-all » allows the user to have information about table history. If it is set to “yes”, all
flows that have matched are sent.

        Detection of horizontal scans :

Suppose that A is source IP address and B destination IP address.

The table 1 is: (A, B).
The table 2 is : (A, B, protocol, source port, destination port).

The collector counts the number of references between the table 1 and the table 2.




Christophe Fillot - 06/10/2005                                                               50/85
                                                                                  IPFlow Collector


Imagine the following situation :

Table 1 :
       (A, B)

Table 2:
       (A, B, 06, 1000, 2000)
       (A, B, 06, 1000, 2001)
       (A, B, 06, 1000, 2002)
       (A, B, 06, 1000, 2003)
                 .
                 .
                 .
        (A, B, 06, 1000, 2020)


Therefore we have 21 references between the two tables for A and B. If the number of
references is superior or equal to the threshold specified by the user then the collector
supposes this is an horizontal scan from A to B.

        Detection of vertical scans :

Suppose the first table contains the source IP address A : (A).

Suppose now that the second table contains source IP address A and destination IP address B :
(A, B).

Imagine the following situation:

Table 1 :

        (A)

Table 2:
       (A, B1)
       (A, B2)
       (A, B3)
                 .
                 .
                 .
        (A, B20)

As explained previously, if the number of references between the two tables exceeds the
specified threshold, this is scan from A to B.

         « report-all » statement:



Christophe Fillot - 06/10/2005                                                              51/85
                                                                                  IPFlow Collector


Thanks to the « report-all » statement, we can have the details of the detection. When “report-
all” is used, all the flows of the second table are reported. Consequently it is possible to know
the list of flows that have produced the scan. Without this statement, only one entry from the
second table is reported.


14.5 Configuration

This section describes the syntax to use to define a scan detector :

        scan-detector <detector_name> {
           type horizontal|vertical;
           notification immediate|deferred;
           flush-interval <interval_in_minutes>;
           report-channel <name_of_logging_channel_name>;
           threshold <valeur>;
        };


Remark : by default, detection interval is set to one minute.




Christophe Fillot - 06/10/2005                                                               52/85
                                                                               IPFlow Collector




15 Netflow v8

Netflow v8 is a particular version of Netflow that exports flows aggregated by the router to
the collector. Netflow v8 can be also used by Catalyst switches to export flows.

IPFlow recognizes the following aggregation schemes :

        -    "as"
        -    "protocol-port"
        -    "source-prefix"
        -    "destination-prefix"
        -    "prefix"
        -    "as-tos"
        -    "protocol-port-tos"
        -    "source-prefix-tos"
        -    "destination-prefix-tos"
        -    "prefix-tos"
        -    "prefix-port"
        -    "dest-only" (Catalyst 5000/6000)
        -    "src-dst" (Catalyst 5000/6000)
        -    "full-flow" (Catalyst 5000/6000)

For example, the « source-prefix-tos » scheme does an aggregation based on the source IPv4
prefix and the ToS field.

The goal of this document is not to describe exhaustively the format of the different Netflow
v8 records, so it recommended to take a look at this URL :

        http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/netflsol/nfwhite.htm

Compared to the traditional netflow versions (v1, v5, v7), the collector allows analysis rules
to be applied on a per-scheme basis.




Christophe Fillot - 06/10/2005                                                           53/85
                                                                                  IPFlow Collector


The syntax is given below :

        router <router_name> {
           ip-address <ip_address>;
           snmp-community <snmp_community>;

             netflow {
                version 8;

                  v8-scheme <scheme_name> {
                      interface <interface_name> {
                          rule-input <input_rule_name>;
                          rule-output <output_rule_name>;
                      };

                       rule <rule_name>;
                  };

                  v8-scheme <...> {
                  };
             };
        };


Instead of having a « global » rule configuration for the router, rules are applied by scheme.

Remark : at this time, Netflow v8 flows must all be received on the same UDP port. The
possibility to specify a reception port for each scheme will be added in a future release.




Christophe Fillot - 06/10/2005                                                              54/85
                                                                                IPFlow Collector




16 Netflow v9

Netflow v9 is the latest version of datagram export format, which improves greatly the way
the data are exported, compared to the previous Netflow versions.
Before, when a modification had to be done on the export format (addition of a field, etc.), a
new Netflow version had to be defined. A similar problem exists with Netflow v8, which
tends to have a large number of aggregation schemes.

With Netflow v9, a template system has appeared. Instead of imposing a fixed format, routers
now export a description of the flow data they send.

Information on Netflow v9 is available in a White Paper on Cisco Web site :

               http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/tflow_wp.htm

It is strongly recommended to read this document to configure correctly the collector and to
understand the notions of Template Flowsets and Data Flowsets.


16.1 TemplateDefinition

A v9 template is identified by a number (ID) and contains a certain number of fields. Please
note that a particular ID is not affected to a specific template (the Cisco IOS CLI does not
allow the user to set a custom template ID at this time).

In order to be able to manage this situation, IPFlow defines the notion of template model.

A template model is defined by a name, and the user specifies in the configuration what fields
he expects to find in this template. Of course, many models can be defined.




Christophe Fillot - 06/10/2005                                                               55/85
                                                                               IPFlow Collector


        router 7200_IPv6
        {
            netflow {
                version 9;

                   template-model IPv4 {
                       ! Fields that we absolutely want to be present:
                       mandatory-fields {
                           ipv4-src-addr;
                           ipv4-dst-addr;
                       };

                         ! Fields that we don’t want in this template :
                         excluded-fields {
                             flows;
                         };

                         ! Analysis rule
                         rule R1;
                   };
              };
        };


In this example, the template model is called « IPv4 ». Fields that must be absolutely present
are IPv4 source and destination addresses, and the « Flows » field (used by aggregation
schemes) must not be present.

When the collector will receive a « Template Flowset » from the router, the list of the
compatible template models will be established. Then, data records corresponding to this
template flowset will be analyzed following the template models found before.

To facilitate understanding of template models, please consider the following example :

        router 7200_IPv6 {
            ip-address 193.51.1.109;
            snmp-community rrt;

              netflow {
                  version 9;
                  receiver-port 9002;

                    ! We analyze IPv4 data records with R1 rule
                    template-model IPv4 {
                        mandatory-fields {
                            ipv4-src-addr;
                            ipv4-dst-addr;
                        };

                          rule R1;
                    };

                    ! We analyze IPv6 data records with R2 rule
                    template-model IPv6 {
                        mandatory-fields {
                            ipv6-src-addr;
                            ipv6-dst-addr;
                        };

                          rule R2;
                    };
              };
        };




Christophe Fillot - 06/10/2005                                                            56/85
                                                                                   IPFlow Collector


In this example, two template models are defined : « IPv4 » et « IPv6 ». Their goal is to send
respectively IPv4 and IPv6 flows to R1 and R2. Therefore it is possible to apply specific
treatments given the templates.

To make this selection of traffic work, the list of fields that must be present for each template
is specified. For example, the template model « IPv6 » requires the presence of IPv6 source
and destination addresses fields. All template flowsets exported by the router containing these
two fields will see their corresponding data records treated by analysis rules specified in the
template model.


16.2 AdvancedOptions

The collector allows the user to control more precisely the binding between template flowsets
exported by the routers and the template models defined in configuration. Moreover, it has
some options that may be useful for debugging.


16.2.1 TemplateID Specification

When the template ID is known, it is possible to specify it in the configuration of the template
model, thanks to the « template-id <template_number>; » statement.


16.2.2 Exact definitionof fields

When exactly all fields of a template are known, it is possible to specify to the collector that
only these fields must be present in template flowset. In order to do this, the statement
« exact-match yes; » must be specified in the configuration of the template model.


16.2.3 Displayingtemplatecontents

To facilitate template configuration setup, it is possible to show contents (ie the field list) of
template flowsets received by the collector. To do this, the statement « show-templates yes; »
has to be present in the « netflow » configuration section of the router.


16.2.4 Displayingflow data

It is possible to display Netflow v9 data records received by the collector thanks to the
statement « show-records yes; » in the « netflow » configuration section of the router.


16.2.5 Displayingunknowntemplates




Christophe Fillot - 06/10/2005                                                               57/85
                                                                               IPFlow Collector


By default, when records are received by the collector with an unknown Template ID, they are
silently discarded. To change this behaviour and to display a warning message, the user has to
specify « show-unknown-templates yes; » in the « netflow » configuration section of the
router.

Remark : this option is generally used for debugging purposes only.




Christophe Fillot - 06/10/2005                                                           58/85
                                                                                    IPFlow Collector




17 Counter Management

17.1 Principleof counters

IPFlow is able to log counter values into text files or into RRDTool databases.

Different counter types exist for a certain number of purposes :

    •   Rules,
    •   Access-Lists (ACL),
    •   Site Traffic Matrices,
    •   Routers (global counters),
    •   Interfaces (input, output, both),
    •   Templates (routers and interfaces).

Each counter type is detailed in the following paragraphs.

Remark: All counters are 64-bit counters, in order to prevent too frequent resets.


17.2 OutputFile

For each output file there is a specific section in the collector configuration :

        counter-log filename {
            mode rrd|text;
            update-interval interval;
            date-format date_format;

              show-values yes|no;

              counter counter_1 {
                  counter definition
              };

              counter counter_i {
                  counter definition
              };

              counter counter_n {
                  counter definition
              };
        };


Keywords mode and update-interval are mandatory. The statement "mode" indicates to the
collector the type of output file (RRDTool database or text file), and the statement "update-
interval" defines the interval (specified in seconds) between two file updates.

The options specific to RRDTool will be covered in the next chapter.

Christophe Fillot - 06/10/2005                                                                59/85
                                                                                   IPFlow Collector




The date-format keyword is specific to text files. It specifies to the collector how to write
date in output files. This format string is used with strftime function, so it is strongly
recommended to read the manual page in order to know all possible options. By default, this
string is defined to "%Y-%m-%d %H:%M:%S" (for example: 2002-07-16 18:20:50).

The show-values keyword permits counter values to be displayed at each update. This option
is generally used for debugging purposes, especially with RRDTool.

Each counter is then defined in a counter subsection. When defining many counters, the
declaration order is important. Given a counter type, a certain number of parameters must be
specified.

Example:

         counter Coounter_1 {
             type rule;
             router 7200_SOIS;
             value bytes;
             mode absolute;
         };


The syntax for the different counter types are given in the next paragraphs.

Remark: it is of course possible to use the same counter in many output files.


17.3 Rule counters

The syntax to get counter from a rule term is as follows :

         counter <counter_name> {
             type rule;
             rule <rule_name>;
             term <term_name>;
             value packets|flows|bytes;
             mode absolute|delta;
         };

with :

    •    rule : rule name,
    •    term : term name in the specified rule.

The "value" parameter allows the type of value to be retrieved : packets, flows or bytes.

The "mode" parameter specifies to the collector how it must retrieve the counter value. If
"delta" is specified, the difference (delta) between current counter value and previous value is
recorded. If "absolute" is specified, the counter value itself is retrieved (keep in mind that this
value is always incremented since the collector startup, except when wrapping occurs).


Christophe Fillot - 06/10/2005                                                                60/85
                                                                                      IPFlow Collector


           L
17.4 Access- ist (ACL)counters

Syntax :

           counter <counter_name> {
               type acl;
               acl <acl_name>;
               term <term_name>;
               value packets|flows|bytes;
               mode absolute|delta;
           };


with :

       •   acl : ACL name,
       •   term : term name in the specified ACL.


17.5 Countersfor Site TrafficMatrices

Two syntaxes are possible given the matrix type :

           counter <counter_name> {
               type stm;
               site-traffic-matrix <matrix_name>;
               site <site_name>;
               value packets|flows|bytes;
               mode absolute|delta;
           };

or :
           counter <counter_name> {
               type stm;
               site-traffic-matrix <matrix_name>;
               src-site <source_site_name>;
               dst-site <destination_site_name>;
               value packets|flows|bytes;
               mode absolute|delta;
           };

with :

       •   site-traffic-matrix : name of the site traffic matrix,
       •   site : site name,
       •   src-site : name of the source site,
       •   dst-site : name of the destination site.

Given the matrix type, the configuration syntax is different :

       •   "source" or "destination": only one site to specify, with « site » statement.
       •   "flow: two sites must be specified, with « src-site » and « dst-site » statements.




Christophe Fillot - 06/10/2005                                                                  61/85
                                                                         IPFlow Collector


17.6 Routercounters

Syntax :

         counter <counter_name> {
             type router;
             router <router_name>;
             value packets|flows|bytes;
             mode absolute|delta;
         };

with router : the name of the router.

These counters represent the total traffic that the router has routed.


17.7 Interfacecounters

Three syntaxes exist:

         counter <counter_name> {
             type if-input;
             router <router_name>;
             interface <interface_name>;
             value packets|flows|bytes;
             mode absolute|delta;
         };

         counter <counter_name> {
             type if-output;
             router <router_name>;
             interface <interface_name>;
             value packets|flows|bytes;
             mode absolute|delta;
         };

         counter <counter_name> {
             type if-matrix;
             router <router_name>;
             if-input <input_interface_name>;
             if-output <output_interface_name>;
             value packets|flows|bytes;
             mode absolute|delta;
         };

with :

    •    router: router name,
    •    interface: interface name,
    •    if-input: input interface name,
    •    if-output: output interface name.


Remark: the "if-matrix" matrix corresponds to traffic exchanged between an input and an
output interface.



Christophe Fillot - 06/10/2005                                                     62/85
                                                                               IPFlow Collector


17.8 Templates(Netflowv9 only)

The collector can maintain statistics for each template model. Indeed, we can imagine to have
two templates, the first for IPv4 traffic and the second for IPv6 traffic and to want to count
separatly the two traffic types.

Remark: by default, the collector does not enable the per-template statistics. To enable
statistics, you have to use the "update-stats yes;" statement in the template model
configuration.

Possible formats :

         counter <counter_name> {
             type template;
             router <router_name>;
             template <template_name>;
             value packets|flows|bytes;
             mode absolute|delta;
         };

         counter <counter_name> {
             type template-if-input;
             router <router_name>;
             template <template_name>;
             interface <interface_name>;
             value packets|flows|bytes;
             mode absolute|delta;
         };

         counter <counter_name> {
             type template-if-output;
             router <router_name>;
             template <template_name>;
             interface <interface name>;
             value packets|flows|bytes;
             mode absolute|delta;
         };

         counter <counter_name> {
             type template-if-matrix;
             router <router_name>;
             template <template_name>;
             if-input <input_interface_name>;
             if-output <output_interface name>;
             value packets|flows|bytes;
             mode absolute|delta;
         };

with :

    •    router: name of the router,
    •    template: name of the template model,
    •    interface: name of the interface,
    •    if-input: name of the input interface,
    •    if-output: name of the output interface.




Christophe Fillot - 06/10/2005                                                           63/85
                                                                              IPFlow Collector


17.9 Example

The following example shows how to count IPv4 and IPv6 traffic for two Netflow v9
templates, the counters being written in a text file. The configuration for the templates is
given, too.

        router 7200_SOIS {
            ip-address 193.51.1.107;
            snmp-community netflow;

              netflow {
                  version 9;
                  receiver-port 9000;

                   ! IPv4 Template Model
                   template-model Flows_IPv4
                   {
                       update-stats yes;

                        mandatory-fields {
                            ipv4-source;
                            ipv4-destination;
                        };

                        excluded-fields {
                            flows;
                        };
                   };

                   ! IPv6 Template Model
                   template-model Flows_IPv6
                   {
                       update-stats yes;

                        mandatory-fields {
                            ipv6-source;
                            ipv6-destination;
                        };

                        excluded-fields {
                            flows;
                        };
                   };
              };
        };

        counter-log stats-ipv4-ipv6.txt
        {
            ! Update every 5 minutes
            update-interval 300;

              ! We want to log into a text file
              mode text;

              ! Date Format: HH:MM (HH=Hours, MM=Minutes)
              date-format "%H:%M";

              ! We want to count IPv4 traffic
              counter ipv4_packets {
                  type template;
                  router 7200_SOIS;
                  template Flows_IPv4;
                  value bytes;
                  mode absolute;
              };


Christophe Fillot - 06/10/2005                                                          64/85
                                                IPFlow Collector


              ! We want to count IPv6 traffic
              counter ipv6_packets {
                  type template;
                  router 7200_SOIS;
                  template Flows_IPv6;
                  value bytes;
                  mode absolute;
              };
        };


A sample result file would be as follows :

        19:05 0 0
        19:10 121020 10246
        19:15 215728 25412




Christophe Fillot - 06/10/2005                            65/85
                                                                                  IPFlow Collector




18 Using RRDTool with IPFlow

RRDTool is a very powerful tool from the public domain which allows arbitrary values to be
stored in RRD (Round Robin Database) files. The particular interest of RRD files is that they
do not grow along the time.

The main usage of RRDTool is to produce graphics like the following :




An exhaustive documentation of RRDTool can be found at this URL :

                          http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/

It is strongly recommended to take a look at the tutorial present on this site, because it
explains very clearly how RRDTool works, and gives a lot of details especially for the
graphical part.

The collector can interact with RRDTool to store counter values into RRD files.


18.1 RRDToolInstallation

Download the last version of RRDTool on the web site and type the following commands as
super-user (« root ») :

        #   tar xzf rrdtool-1.0.38.tar.gz
        #   cd rrdtool-1.0.38
        #   ./configure --prefix=/usr/local
        #   make
        #   make install

Remark : by default, the collector will assume that RRDTool binary is located in
"/usr/local/rrdtool/bin/" directory.

To specify another file path, the "rrdtool-path" statement has to be used in the "options"
section of the configuration file :

        options {
            rrdtool-path /usr/local/bin/rrdtool;
        };

Christophe Fillot - 06/10/2005                                                              66/85
                                                                              IPFlow Collector




Please note that « rrdtool-path » must contain the RRDTool binary filename and not a
directory path.


18.2 Manualcreationof a RRDTooldatabase

There are two ways to create RRDTool databases : one is automatic, which lets the collector
choose some of the parameters, and another which is manual for more control.

An example of script to create a RRD file would be :

        #!/bin/bash

        /usr/local/bin/rrdtool create stats.rrd -s 300           \
                       DS:byte_counter:COUNTER:300:0:U           \
                       DS:packet_counter:COUNTER:300:0:U         \
                       DS:flow_counter:COUNTER:300:0:U           \
                       RRA:AVERAGE:0.5:1:26000                   \
                       RRA:AVERAGE:0.5:6:775                     \
                       RRA:AVERAGE:0.5:48:775                    \
                       RRA:AVERAGE:0.5:288:797

Three counters are defined in this file (« byte_counter »,               « packet_counter »,
« flow_counter »), and updates are done every 300 seconds (5 minutes).

It is strongly recommended to use an update interval for RRDTool identical to the Netflow
active timeout configured on the router when RRDTool is used to graph traffic flows.
Similarly, the update-interval value specified in the collector configuration should be
identical to value used at the RRD file creation with "-s 300") parameter.

Very important remark :

There are two ways to retrieve counters : by « absolute » value or by computing a delta
(current_value – previous_value).

Please note that this impacts RRDTool use, since you have to specify a Data Source
type which is compatible with the way the counter is read.

The following rule can be used to avoid problems :

    •   "absolute" value <=> use a DS of type "COUNTER".
    •   Delta <=> use a DS of type "GAUGE".


18.3 Automaticcreationof a RRDTooldatabase

RRDTool files can be created by the collector if they do not exist. Data Source names are
chosen from counter names, and « RRA » information has to be specified in « rrd-options »
section.

Christophe Fillot - 06/10/2005                                                          67/85
                                                                                         IPFlow Collector




If we take the previous example, but with an automatic creation, the collector configuration
would be :

        counter-log stats.rrd
        {
            ! Update every 5 minutes (300 sec)
            update-interval 300;

              ! We want to store counter values into a RRDTool database
              mode rrd;

              rrd-options {
                  create-file yes;

                   rra   {   consolidation   AVERAGE;   xff   0.5;   steps   1; rows 26000;   };
                   rra   {   consolidation   AVERAGE;   xff   0.5;   steps   6; rows 775;     };
                   rra   {   consolidation   AVERAGE;   xff   0.5;   steps   48; rows 775;    };
                   rra   {   consolidation   AVERAGE;   xff   0.5;   steps   288; rows 797;   };
              };

              ! Counter declarations

              counter byte_counter {
                  […]
              };

              counter packet_counter {
                  […]
              };

              counter flow_counter {
                  […]
              };
        };




18.4 Obtaininggraphics

Once the RRDTool file is created and the collector started, graphics can be generated.
Generally, this operation is done using a « CRON » entry, running for example every 5
minutes.

A script example to make a graphic is given below, for the examples mentioned above. Only
one line is drawn, corresponding to the number of packets.

        #!/bin/bash

        /usr/local/bin/rrdtool graph stats.gif --start -86400                             \
               -w 450 -h 100                                                              \
               -x HOUR:1:HOUR:6:HOUR:2:0:%H                                               \
               -v "flux/s" -l 0 --alt-autoscale-max                                       \
               DEF:packet_counter=stats.rrd:packet_counter:AVERAGE                        \
               LINE1:packet_counter#FF0000:"Packet Number"                                > /dev/null




Christophe Fillot - 06/10/2005                                                                     68/85
                                                                                IPFlow Collector


When traffic rate must be displayed in bits/s, the configuration to use is as follows (the
collector always use byte values) :

        #!/bin/bash

        /usr/local/bin/rrdtool graph stats.gif --start -86400                   \
               -w 450 -h 100                                                    \
               -x HOUR:1:HOUR:6:HOUR:2:0:%H                                     \
               -v "bits/s" -l 0 --alt-autoscale-max                             \
               DEF:compteur_octets=stats.rrd:compteur_paquets:AVERAGE           \
               "CDEF:cp=compteur_octets,8,*"                                    \
               LINE1:cp#FF0000:"Débit"                                          > /dev/null



RRDTool has a lot of powerful options to create custom graphics (stackable areas, comments
in graph, legends, etc.), so the user is advised to read the documentation to know capabilities
of this excellent tool.


18.5 Example

The script that has been used to make the following graph is given below :




UPJV and UTC are two sites making traffic to their Internet provider (Renater). The purpose
of the graphic is to show how Renater access is used by these two sites. UTC traffic (in blue)
is stacked on the top of UPJV traffic (in green) to get a cumulative aspect. The white area
between the red line and the blue area is traffic done by other sites than UTC and UPJV.


#!/bin/bash

cd /usr/local/rrt/ipflow

/usr/local/bin/rrdtool graph stats_bytes.gif --start -86400                     \
                -w 450 -h 100                                                   \
                -x HOUR:1:HOUR:6:HOUR:2:0:%H                                    \
                -v "bits/s" -l 0 --alt-autoscale-max                            \
                DEF:utc_in=renater_utc_upjv.rrd:utc_in_bytes:AVERAGE            \
                DEF:upjv_in=renater_utc_upjv.rrd:upjv_in_bytes:AVERAGE          \
                DEF:renater_in=renater_utc_upjv.rrd:renater_in_bytes:AVERAGE    \
                "CDEF:uti=utc_in,8,*"                                           \
                "CDEF:upi=upjv_in,8,*"                                          \
                "CDEF:ri=renater_in,8,*"                                        \
                AREA:upi#00C000:UPJV                                            \
                STACK:uti#4000FF:UTC                                            \
                LINE1:ri#FF0000:Renater                                         > /dev/null




Christophe Fillot - 06/10/2005                                                            69/85
                                                                               IPFlow Collector




19 IPFlow Grep : flow lookup utility

IPFlow Grep is a command line tool that permits multi-criteria lookups to be done on binary
files produced by the collector.


19.1 Criteria

Criteria that can be used are given below :

    •   Source and Destination Addresses (IPv4 and IPv6), with the possibility to specify
        CIDR prefixes,
    •   Source and Destination ports,
    •   IP Protocol (TCP, UDP, etc.),
    •   IP ToS (Type Of Service),
    •   Flow size in bytes,
    •   Number of packets,
    •   Flow duration.

Where many criteria are specified, the flow records must match simultaneously all the criteria
to be displayed.

                        Option                              Description
                      --src-addr       IPv4 Source Address
                      --dst-addr       IPv4 Destination Address
                     --src-prefix      IPv4 Source Prefix
                     --dst-prefix      IPv4 Destination Prefix
                         --addr        IPv4 Source or Destination Address
                        --prefix       IPv4 Source or Destination Prefix
                   --ipv6-src-addr     IPv6 Source Address
                   --ipv6-dst-addr     IPv6 Destination Address
                  --ipv6-src-prefix    IPv6 Source Prefix
                  --ipv6-dst-prefix    IPv6 Destination Prefix
                     --ipv6-addr       IPv6 Source or Destination Address
                    --ipv6-prefix      IPv6 Source or Destination Prefix
                      --src-port       Source Port (range accepted)
                      --dst-port       Destination Port (range accepted)
                         --port        Source or Destination Port (range accepted)
                         --size        Flow size
                      --duration       Flow duration (in milliseconds)
                        --proto        IP Protocol
                          --tos        Type Of Service (ToS)
                          --tag        User Tag (value on 32 bits)
                       --packets       Number of packets

Christophe Fillot - 06/10/2005                                                           70/85
                                                                                        IPFlow Collector


                        --src-as            Source Autonomous System (AS)
                        --dst-as            Destination Autonomous System (AS)


19.1.1 How« --addr » and « --prefix » optionswork

When « addr » or « prefix » options are used, records will be matched if their source or
destination addresses correspond to the specified criteria.

For instance, specifying « --prefix 195.83.155.0/24 » means that source or destination address
must match 195.83.155.0/24 CIDR prefix.


19.1.2 Size specification(« --size »)

It is possible to specify the minimum size of flows in bytes thanks to the « -s » or « --size »
options. A unit can be specified in order to manipulate large flows more easily :

                          Unit                                        Factor
                           K                1024
                           M                1024 x 1024
                           G                1024 x 1024 x 1024
                           k                1000
                           m                1000 x 1000
                           g                1000 x 1000 x 1000

Remarks :

       -    Units « K », « M » et « G » use the traditionnal « 1024 » factor for to manipulate byte
            values (it is recommended to use these units).

       -    The number before the unit can be a decimal number.

Example :

       « --size 1.58M » matches flows whose size is greater or equal than 1,58 Megabytes.


19.2 Particularoptions

Some other options exist :

   -       « --help » or « -h » : displays a short help on the different recognized options ;

   -       « --exclude » or « -x » : the effect of « grep » is reversed : only records that do not
           match simultaneously all specified criteria are displayed ;


Christophe Fillot - 06/10/2005                                                                    71/85
                                                                                    IPFlow Collector


   -   « --stats » or « -s » : displays the number of records which have matched specified
       criteria, with total number of records in file.

   -   « --format » or « -f » : allows a log-format string to be specified, to display flow data
       with a custom output format.

   -   « --start <record_number> » : starts « grep » at the specified flow position in file.

   -   « --last <n> » : performs a « grep » for the « n » last records of file.

   -   « --count <n>» or « -c <n>» : performs a « grep » on the « n » records specified. If no
       starting position is specified with « --start » option, the « n » records will be the first
       « n » records of the file.

   -   « --debug » or « -d » : enable debugging mode (for maintenance only).

   -   " --count " ou " -c " : this option indicates the number of flows to analyze.

   -   " --last " : this option indicates the number of flows to analyze, from the end of file.

   -   " --start " : this option indicates the starting flow.

   -   " --section-count " : this option indicates the number of sections to analyze.

   -   " --section-last " : this option indicates the number of sections to analyze, from the end
       of file.

   -   " --section-start " : this option indicates the starting section.



19.3 Examples

We will display from « example.log » file all TCP flows with more than 1.5 Mb of data, for
hosts located on 195.83.155.0/24 subnet :

       ./ipflow grep exemple.log --proto tcp --size 1.5M --prefix 195.83.155.0/24



We will search in the file called “binary.log” the flows that have for source address
193.55.117.58. The output format is the default format used by the collector.

      ipflow   grep --src-addr 193.55.117.58 binary.log
C6k-MSFC        2003-12-23 19:19:09.730 | 193.55.117.58  | 193.49.159.10                | TCP
43549     80   | P:    45 | S:    4632 | T: 18120 | *unknown*                           -> *local*
C6k-MSFC        2003-12-23 19:21:00.007 | 193.55.117.58  | 193.49.159.10                | TCP
43550     80   | P:    31 | S:    3818 | T: 16628 | *unknown*                           -> *local*
C6k-MSFC        2003-12-23 19:21:16.635 | 193.55.117.58  | 193.49.159.10                | TCP
43551     80   | P:    35 | S:    3896 | T: 26364 | *unknown*                           -> *local*


Christophe Fillot - 06/10/2005                                                                 72/85
                                                                         IPFlow Collector




Now, let us interest to the same address as destination address :
       ipflow grep --dst-addr 193.55.117.58 binary.log
C6k-MSFC      2003-12-23 19:19:09.734 | 193.49.159.10  | 193.55.117.58    | TCP
80 43549 | P:     64 | S:   84826 | T: 18120 | *unknown*               -> *local*
C6k-MSFC      2003-12-23 19:21:00.011 | 193.49.159.10  | 193.55.117.58    | TCP
80 43550 | P:     29 | S:   33780 | T: 16628 | *unknown*               -> *local*
C6k-MSFC      2003-12-23 19:21:16.639 | 193.49.159.10  | 193.55.117.58    | TCP
80 43551 | P:     62 | S:   84862 | T: 15132 | *unknown*               -> *local*




Let us interest to the prefix193.55.117.58/32 :

       ipflow grep --src-prefix 193.55.117.58/32 binary.log
C6k-MSFC     2003-12-23 19:19:09.730 | 193.55.117.58   | 193.49.159.10      | TCP
43549    80 | P:    45 | S:    4632 | T: 18120 | *unknown*                  -> *local*
C6k-MSFC     2003-12-23 19:21:00.007 | 193.55.117.58   | 193.49.159.10      | TCP
43550    80 | P:    31 | S:    3818 | T: 16628 | *unknown*                  -> *local*
C6k-MSFC     2003-12-23 19:21:16.635 | 193.55.117.58   | 193.49.159.10      | TCP
43551    80 | P:    35 | S:    3896 | T: 26364 | *unknown*                  -> *local*
C6k-MSFC     2003-12-23 19:22:29.755 | 193.55.117.58   | 193.49.159.10      | TCP
43552    80 | P:    35 | S:    4112 | T: 28316 | *unknown*                  -> *local*


Let us interest to the source port 22 :
       ipflow grep --src-port 22 binary.log
C6k-MSFC     2003-12-23 19:18:02.234 | 195.83.155.15    | 81.56.197.176    | TCP
22 3876 | P:      1 | S:      76 | T:       0 | *unknown*               -> *local*
C6k-MSFC     2003-12-23 19:18:02.238 | 195.83.155.15    | 81.56.197.176    | TCP
22 3944 | P:      2 | S:     116 | T:       0 | *unknown*               -> *local*
C6k-MSFC     2003-12-23 19:18:02.250 | 195.83.155.15    | 81.56.197.176    | TCP
22 4041 | P:      1 | S:      76 | T:       0 | *unknown*               -> *local*


Let us interest to the flows containing at least10000 packets :
       ipflow grep --packets 10000 binary.log
C6k-MSFC     2003-12-23 19:24:25.759 | 62.153.146.222 | 195.83.155.55   | TCP
80 60284 | P: 12928 | S: 19387664 | T: 81512 | *unknown*              -> *local*


Now, let us search the flows that contain at least 2 Mb of data :

       ipflow grep --size 2M binary.log
C6k-MSFC      2003-12-23 19:14:12.966 | 195.64.198.89  | 195.83.155.55      | TCP
80 41722 | P: 3864 | S: 5791576 | T: 300844 | *unknown*                ->   *local*
C6k-MSFC      2003-12-23 19:14:16.878 | 195.83.155.18  | 193.49.184.5       | TCP
38872    119 | P: 3916 | S: 4974683 | T: 301004 | *unknown*                 -> *local*
C6k-MSFC      2003-12-23 19:14:40.079 | 195.83.155.18  | 192.108.115.2      | TCP
38716    119 | P: 2040 | S: 2513009 | T: 301180 | *unknown*                 -> *local*

Let us interest to the flows whose duration is at least 100 seconds:
       ipflow grep --duration 100000 binary.log
C6k-MSFC     2003-12-23 19:41:02.282 | 80.8.84.15      | 195.83.155.55    | TCP
4662 1323 | P:    550 | S:   28784 | T: 301844 | *unknown*               -> *local*


Christophe Fillot - 06/10/2005                                                     73/85
                                                                          IPFlow Collector


C6k-MSFC    2003-12-23 19:41:02.486 | 195.83.155.55  | 80.8.84.15          | TCP
1323 4662 | P:   630 | S: 809974 | T: 301404 | *unknown*                  -> *local*

We can modify the output format :
       ipflow grep -f "%{ipv4-src-addr} %{ipv4-dst-addr} %{proto-str} \
       %{src-port} %{dst-port}\n" binary.log
172.21.80.22 172.22.48.99 ICMP 0 2048
172.21.8.46 192.190.109.20 TCP 49181 80
172.18.5.115 133.241.248.189 TCP 1374 135
172.18.5.115 133.241.248.190 TCP 1375 135
172.18.5.115 133.241.248.191 TCP 1376 135
172.18.5.115 133.241.248.192 TCP 1377 135




Christophe Fillot - 06/10/2005                                                      74/85
                                                                              IPFlow Collector




20 IPFlow « File Info »

The command line tool « File Info » shows characteristics of binary files written by the
collector.

File Info tool can provide the following informations :

     -   Date and Hour of data collection start,
     -   File description,
     -   Text log-format (« -t » option)
     -   Router names (« -r » option),
     -   Router interfaces with bindings between names and SNMP indexes (« -i » option),
     -   List of stored fields (« -f » field),
     -   Number of records in file (« -c » option).
     -   Section list (« --sections » ou « -s » option)

To display all of these informations, the « -a » option can be specified on the command line.
More details can be displayed with the « -d » options.

                        Option                                  Action
                    --sections |-s     List of sections
                      --fields |-f     List of stored fields
                     --routers |-r     Router names
                   --interfaces |-i    Router interfaces
                     --format |-t      Text format
                      --count |-c      Number of flow records
                     --details |-d     Show some details
                        --all |-a      Complete information
                       --help |-h      Help

All recognized options can be shown with « --help » or « -h » option.

Example :

         [rrtadm@nemesys ~]$ ./ipflow file_info -f -c -t -r example.log
         Description: Test File
         Data collection started at 2002-09-03 14:46:49.
         Record size: 48 bytes

         Field list:
             1: router
             2: ipv4-src-addr
             3: ipv4-dst-addr
             4: packets
             5: bytes
             6: flows
             7: timestamp
             8: duration
             9: src-port
            10: dst-port


Christophe Fillot - 06/10/2005                                                          75/85
                                                                                      IPFlow Collector


              11: if-input
              12: if-output
              13: protocol

         Router list:
            7500_UTC (80 interfaces)

         Log-Format: %{router}: %{ipv4-src-addr} -> %{ipv4-dst-addr}\n
         3090 records in file.


Remarks :

     -   The size for a single flow is given at the « Record size » line.
     -   The description and the text log format string must have been defined in the
         « options » section of a channel to be present.

     Some examples :

Let us interest to sections present in the file “binary.log”:

         ipflow flow_info -s binary.log
         Data collection started at 2003-12-23 19:18:17.
         Data collection stopped at 2003-12-23 19:46:21.
         Section Information:
         Section Cache size: 0 bytes.

         0:   2003-12-23   19:18:17   ->   2003-12-23   19:20:00   :   13530   record(s)
         1:   2003-12-23   19:20:00   ->   2003-12-23   19:25:00   :   43830   record(s)
         2:   2003-12-23   19:25:00   ->   2003-12-23   19:30:00   :   42990   record(s)
         3:   2003-12-23   19:30:00   ->   2003-12-23   19:35:00   :   41220   record(s)
         4:   2003-12-23   19:35:00   ->   2003-12-23   19:40:00   :   41370   record(s)
         5:   2003-12-23   19:40:00   ->   2003-12-23   19:45:00   :   42990   record(s)
         6:   2003-12-23   19:45:00   ->   2003-12-23   19:46:21   :   10860   record(s)

We can obtain details on these sections :
         ipflow flow_info -s -d binary.log
         Data collection started at 2003-12-23 19:18:17.
         Data collection stopped at 2003-12-23 19:46:21.
         Section Information:
         Section Cache size: 0 bytes.

         0: 2003-12-23 19:18:17 -> 2003-12-23 19:20:00 :               13530 record(s)
            Flow start index: 0, Flow end index: 13530.
            Offset: 0x00002000, Data Preamble: 0 bytes.
            Data size: 541200 bytes.

         1: 2003-12-23 19:20:00 -> 2003-12-23 19:25:00 :    43830 record(s)
            Flow start index: 13530, Flow end index: 57360.
            Offset: 0x00086238, Data Preamble: 0 bytes.
            Data size: 1753200 bytes.
         Etc…

Let us interest to the fields :
         ipflow flow_info -f binary.log
         Data collection started at 2003-12-23 19:18:17.
         Data collection stopped at 2003-12-23 19:46:21.
         Header size: 8192 bytes.
         Record size: 40 bytes.

         Field list:
                1: timestamp (length 8, offset 0)

Christophe Fillot - 06/10/2005                                                                  76/85
                                                          IPFlow Collector


                 2: router (length 4, offset 8)
                 3: ipv4-src-addr (length 4, offset 12)
                 4: ipv4-dst-addr (length 4, offset 16)
                 5: duration (length 4, offset 20)
                 6: packets (length 4, offset 24)
                 7: bytes (length 4, offset 28)
                 8: src-port (length 2, offset 32)
                 9: dst-port (length 2, offset 34)
                 10: protocol (length 1, offset 36)

Let us interest to the routers :
        ipflow flow_info -r binary.log
        Data collection started at 2003-12-23 19:18:17.
        ata collection stopped at 2003-12-23 19:46:21.
        Router list:
        C6k-MSFC (24 interfaces)



We can known all the interfaces :
        ipflow flow_info -i binary.log
        Data collection started at 2003-12-23 19:18:17.
        Data collection stopped at 2003-12-23 19:46:21.
        C6k-MSFC: Interface List:
               01: EOBC0/0
               02: Null0
               03: Vlan1
               04: Vlan2


Let us interest to the total number of flows :
        ipflow flow_info -c binary.log
        Data collection started at 2003-12-23 19:18:17.
        Data collection stopped at 2003-12-23 19:46:21.
        236790 flow record(s) in file.

We display the complete information :
        ipflow flow_info -a binary.log
        Data collection started at 2003-12-23 19:18:17.
        Data collection stopped at 2003-12-23 19:46:21.
        Header size: 8192 bytes.
        Record size: 40 bytes.

        Field list:
               1: timestamp (length 8, offset 0)
               2: router (length 4, offset 8)
               3: ipv4-src-addr (length 4, offset 12)
               4: ipv4-dst-addr (length 4, offset 16)
               5: duration (length 4, offset 20)
               6: packets (length 4, offset 24)
               7: bytes (length 4, offset 28)
               8: src-port (length 2, offset 32)
               9: dst-port (length 2, offset 34)
               10: protocol (length 1, offset 36)

        Router list:
               C6k-MSFC (24 interfaces)

        C6k-MSFC: Interface List:
               01: EOBC0/0
               02: Null0
               03: Vlan1
               04: Vlan2
               05: Vlan3

Christophe Fillot - 06/10/2005                                      77/85
                                                                         IPFlow Collector


                 06:   Vlan4
                 07:   Vlan5
                 08:   Vlan6
                 09:   Vlan7
                 10:   Vlan8
                 11:   Vlan9
                 12:   Vlan10
                 13:   Vlan11
                 14:   Vlan12
                 15:   Vlan13
                 16:   Vlan14
                 17:   Vlan17
                 18:   Vlan18
                 19:   Vlan19
                 20:   Vlan20
                 21:   Vlan22
                 22:   Vlan23
                 23:   Vlan200
                 24:   Vlan300


        Section Information:
        Section Cache size: 0 bytes.

         0: 2003-12-23 19:18:17 -> 2003-12-23 19:20:00 :    13530 record(s)
            Flow start index: 0, Flow end index: 13530.
            Offset: 0x00002000, Data Preamble: 0 bytes.
            Data size: 541200 bytes.

         1: 2003-12-23 19:20:00 -> 2003-12-23 19:25:00 :    43830 record(s)
            Flow start index: 13530, Flow end index: 57360.
            Offset: 0x00086238, Data Preamble: 0 bytes.
            Data size: 1753200 bytes.

        …




Christophe Fillot - 06/10/2005                                                     78/85
                                                                                  IPFlow Collector




21 IPFlow « STM_Info »

The “STM_Info” utilitity permits the user to obtain information about a binary file of STM
type, that means that stores contents of site traffic matrices. This is like the « Flow_Info »
utility that permits to obtain information about binary flow files.

STM_Info can provide the following information :

     -   Date and hour of first write,
     -   File description,
     -   List of sites,
     -   List of IP prefixes,
     -   Number of records (the number of times the matrix has been written),
     -   List of sections,

To display all of these informations, the « -a » option can be specified on the command line.
More details can be displayed with the « -d » options.


                        Option                                           Action
                    --sections |-s           Section list
                       --sites |-i           Site list
                    --prefixes |-p           List of IP prefixes
                      --count |-c            Number of records
                     --details |-d           Show some details
                        --all |-a            Complete information
                       --help |-h            Help

All the recognized options can be displayed using the « --help » or « -h » option.

     Some examples :

Let us interest to the list of section in the file called « stm.log » (please remember that each
section contains the contents of the matrix for the given period).

         ipflow stm_info -s stm.log
         Sections:

              0:   2004-01-25    21:34:26   ->   2004-01-25   21:35:00
              1:   2004-01-25    21:35:00   ->   2004-01-25   21:36:00
              2:   2004-01-25    21:36:00   ->   2004-01-25   21:37:00
              3:   2004-01-25    21:37:00   ->   2004-01-25   21:38:00
              4:   2004-01-25    21:38:00   ->   2004-01-25   21:39:00
              5:   2004-01-25    21:39:00   ->   2004-01-25   21:40:00
              6:   2004-01-25    21:40:00   ->   2004-01-25   21:41:00
              7:   2004-01-25    21:41:00   ->   2004-01-25   21:42:00
              8:   2004-01-25    21:42:00   ->   2004-01-25   21:42:03

Let us interest to list of IP prefixes:

Christophe Fillot - 06/10/2005                                                              79/85
                                                                      IPFlow Collector



        ipflow stm_info -p stm.log
        Site Networks:
           * SI:
             172.16.0.0/16
             193.55.117.0/24
             195.83.155.0/24

            * BF:
              172.19.0.0/16
              195.83.156.0/24

            * CR:
              172.18.0.0/16
              193.55.116.0/24

            * PG:
              172.21.0.0/16
              193.55.118.0/24

            * Mare_Gaudry:
              172.26.0.0/20

            * Roberval:
              172.26.16.0/20


Let us interest to the list of sites :
        ipflow stm_info -i stm.log
        List of sites:
           0: ANY
           1: OTHER
           2: SI
           3: BF
           4: CR
           5: PG
           6: Mare_Gaudry
           7: Roberval

We can know the number of times the matrix has been written so far:
        ipflow stm_info -c stm.log
        8 records in file.

We display the complete information about this file :
        ipflow stm_info -a stm.log
        List of sites:
           0: ANY
           1: OTHER
           2: SI
           3: BF
           4: CR
           5: PG
           6: Mare_Gaudry
           7: Roberval

        Site Networks:
           * SI:
             172.16.0.0/16
             193.55.117.0/24
             195.83.155.0/24

            * BF:
              172.19.0.0/16
              195.83.156.0/24


Christophe Fillot - 06/10/2005                                                  80/85
                                                               IPFlow Collector


            * CR:
              172.18.0.0/16
              193.55.116.0/24

            * PG:
              172.21.0.0/16
              193.55.118.0/24

            * Mare_Gaudry:
              172.26.0.0/20

            * Roberval:
              172.26.16.0/20

        Sections:

              0: 2004-01-25 21:34:26 -> 2004-01-25 21:35:00
                 Offset: 0x00002000, Data Preamble: 0 bytes.
                 Data size: 256 bytes.
                 Interval: 60 sec (complete)

              1: 2004-01-25 21:35:00 -> 2004-01-25 21:36:00
                 Offset: 0x00002128, Data Preamble: 0 bytes.
                 Data size: 256 bytes.
                 Interval: 60 sec (complete)

        [...]

        8 records in file.




Christophe Fillot - 06/10/2005                                           81/85
                                                                                   IPFlow Collector




22 IPFlow « STM_Fetch »

The “STM_Fetch” utility allow to read the information stored in STM files, and optionnaly to
send the result to RRDTool files.


                       Option                                    Action
                    --sections |-s      Section list
                       --site|-u        Site (“source” or “destination” matrix only)
                       --src |-s        Source site (bilinear matrix only)
                       --dst|-d         Destination site (bilinear matrix only)
                       --rrd |-r        RRDTool file to fill with the data
                  --section-count       Number of sections to treat
                    --section-last      “n” last sections
                   --section-start      Starting section
                      --help |-h        Help


The principle of « STM_Fetch » is to read counters for a particular site in the case of
« vector » matrices (« source » or « destination » modes) or for a pair of sites in the case of
bilinear matrices (« full-flow » mode).

Take as example following situation :

        ipflow stm_info -i stm-source.log
        List of sites:
           0: ANY
           1: OTHER
           2: SI
           3: BF
           4: CR
           5: PG
           6: Mare_Gaudry
           7: Roberval

        ipflow stm_fetch -u SI stm-source.log
        1075062900              923                  12068            2641107
        1075062960             2845                  41329            8931845
        1075063020             4479                  57731           13797988
        1075063080             6006                  85729           23871737
        1075063140             7558                 104344           29030710
        1075063200             9051                 134201           34451948
        1075063260            10572                 150534           43493727
        1075063320            11884                 171716           48486738

We begin by consulting the site list using « STM_Info » utility. If we want to obtain the
traffic made by the site called “SI”, it is sufficient to specify « -u SI » to select this site in
particular.




Christophe Fillot - 06/10/2005                                                               82/85
                                                                                  IPFlow Collector


The result of « STM_Fetch » is displayed using this method :

    •   Number of seconds since 01/01/1970
    •   Number of flows
    •   Number of packets
    •   Number of bytes


Instead of displaying the result to screen, it is also possible to store the values in a RRDTool
file. In order to do this, this file must contain necessarily 3 “Data Sources”: the first for the
number of flows, the second for the number of packets and finally the third for the number of
bytes.




Christophe Fillot - 06/10/2005                                                              83/85
                                                                                IPFlow Collector




23 Annex : a simple example

This chapter presents a typical configuration for a collector, in order to give to the reader a
general idea of the configuration aspect.

The goal of this example is to colorize some traffic patterns (HTTP/HTTPS and DNS) coming
from an Internet access. A site « UTC » is defined with a certain number of prefixes.

We colorize flows with the following rules :

WEB traffic for UTC in green,
DNS traffic (for any site) in yellow.



router 7500_UTC {
   ! IP Address of router and SNMP community
   ip-address 193.51.1.105;
   snmp-community netflow;

     ! We use Netflow v5 et we receive Netflow datagrams on port UDP 8000
     netflow {
        version 5;
        receiver-port 8000;
     };

     ! The Internet access interface
     interface ATM0/1/0.2 {
        rule-input Internet_Input;
     };
};

! Networks for site « UTC »
site UTC {
   networks {
      195.83.154.0/24;
      195.83.155.0/24;
      195.83.156.0/24;
      195.83.157.0/24;
      193.55.116.0/24;
      193.55.117.0/24;
      193.55.118.0/24;
   };
};

! This rule is applied to flows coming from the Internet interface
! of the router.
rule Internet_Input {
   ! We display HTTP and HTTPS traffic for UTC WEB
   ! servers in green.
   term WEB_UTC {
      source ANY;
      destination UTC;
      access-list HTTP;
      color green;
   };

     ! We display DNS traffic in yellow
     term DNS {


Christophe Fillot - 06/10/2005                                                            84/85
                                           IPFlow Collector


          source ANY;
          destination ANY;
          access-list DNS;
          color yellow;
     };
};

! Access-List for HTTP/HTTPS traffic
access-list HTTP {
   term http {
      action permit;
      protocol tcp;
      dst-port 80;
   };

     term https {
        action permit;
        protocol tcp;
        dst-port 443;
     };
};

! Access-list for DNS (UDP/TCP port 53).
access-list DNS {
   ! Performance optimization
   compiled-mode enable;

     term 1 {
        action permit;
        protocol udp;
        dst-port 53;
     };

     term 2 {
        action permit;
        protocol tcp;
        dst-port 53;
     };

     term 3 {
        action permit;
        protocol udp;
        src-port 53;
     };

     term 4 {
        action permit;
        protocol tcp;
        src-port 53;
     };
};




Christophe Fillot - 06/10/2005                       85/85

				
DOCUMENT INFO