Configuring flow export

Introduction

Proper configuration of Flow Exporting Devices (FED) is key to Flow Based Network Analysis. Errors made during configuration will result in missing or duplicate data and are difficult to identify. Vendors of network equipment are not making it easy as most of them are using a proprietary method to enable flow exports to the collector (in our case TVF or TVA).

Furthermore, some collectors require special configuration to be made on the FED in order to undersand its flows correctly.

This article is trying to decribe the concept behind network flow reporting and we hope it will help you to determine the correct procedure on how to confgure your FEDs.

For a complete overview of IP Flow Information eXchange (IPFIX), we recommend the reading of RFC 3917.

If you come aware of vendor specific issues during the configuration please let us know.

 

Solution

Definitions

FED

A Flow Enabled Device is in general any L3 device sending flow records to a collector.

Flow

A flow is defined as a stream of packets between a given source and a given destination. For example, in client-server computing a TCP sessions consists of two flows: one flow from client to server and the second flow from server to client.

Flow record

A flow record contains information about a specific flow that was metered at an observation point.  A flow record contains measured properties of the flow (e.g., the total number of bytes of all packets of the flow, flow duration and the physical or virtual input interface i.e. where the packets entered the FED) and usually characteristic properties of the flow (e.g., source/destination IP address, protocol, port, ToS/DiffServ marking, ...).

Sensor

A sensor is a meter located at an observation point. It will "meter" the packets going by the observation point and "build" the flow record decribing the flow.  A sensor will meter packets in one direction only (inwards/ingress/in or outwards/egress/out) but some vendors use sensors that are bidirectional. 

Collector

A flow collector is most likely a server or appliance that collects the flow records and stores them in a database-like structure. In a TruView system , TruView Flow is the collector.

Reporter

The reporter is an application running on the same or a different server than the collector that mines the data records and produces statistical results. In a TruView system, TruView Central is the reporter.

 

Global configuration

The way to enable flow monitoring and flow exports will vary from vendor to vendor.  At large you have to configure these parameters:

Destination

• IP address of the collector

Port

• UDP port where the collector is listening on

Active flow timeout

• Interval at which flow record updates are send in case of long flows. A flow is considered long when it exceeds the smallest database granularit. Consequently, this setting should match the smallest granularity of the database on the collector.  In case of TruView, this is one minute

Inactive flow timeout

• Interval of inactivity (no packets) that marks a flow as inactive. The recommended setting is 15 seconds.

Flow record format

With the introduction of CISCO's Flexible NetFlow and the standardization of IPFIX, the PDU of a flow record is no longer uniformely defined. The fields contained in the PDU should reflect the reporter's capabilities. In case of TruView the flow record must contain at least the following information:

• source address
• destination addresstos
• protocol
• source port
• destination port
• input interface
• tcp flags
• number of bytes 
• number of packets 
• timestamp of the first packet of the flow 
• timestamp of the last packet of the flow

 

Interface configuration examples

 

 

Basically, this is the science of deploying sensors so that EVERY flow that goes through the FED is metered.  It is equally important to make sure that NO flow is metered more than once.  

Example 1: Ingress/in sensor on both interfaces. Flows from user to network are metered by the sensor on interface 0/0 while flows from network to user are metered by the sensor on interface 0/1.

2ArmedRouterNIUI.png

Example 2: egress/out sensor on both interfaces. Flow from user to network are metered by the sensor on interface 0/1 while flows from network to user are metered by the sensor on interface 0/0. 

2ArmedRouterNEUE.png

Example 3: combination of ingress/in and egress/out sensors. Flows from user to network are metered by the ingress/in sensor on interface 0/0.  Flows from network to user are metered by the egress/out sensor on that same interface 0/0. This configuration is prefrerable when interface 0/1 is complex like a multitude of virtual interfaces or/and encrypted tunnels.

2ArmedRouterUIE.png

Example 4: combination of ingress/in and egress/out sensors. Flows from user to network are metered by the egress/out sensor on interface 0/1.  Flows from network to user are metered by the ingress/in sensor on that same interface 0/1. This configuration is likely when an operator configures flow export as the operator only cares about the network side of the router (interface 0/1). It can also be applied when the user side of the router is complex.

2ArmedRouterNIE.png

 

Cisco configuration example

 

CiscoFlowExample.png

 

This is how a Flexible NetFlow configuration would look like on a CISCO 3800 Series router with a recent IOS. The router has two physical interfaces facing the network (WAN) with different capacity.  There is no traffic between these interfaces. Please note that in most cases the collector needs to be able to query the router by SNMP in order to "discover" its interface configuration and hostname. You may need to configure the capacity of the interfaces (bps) to the collector/reporter manually to allow correct calculation of interface utilization (%).

 

ip access-list standard SNMP-RO
 permit 1.2.3.4
snmp-server community c0mc3rt-ro RO notsecure
!
!
flow record recordnf9-comcert
 match ipv4 tos
 match ipv4 protocol
 match ipv4 source address
 match ipv4 source mask
 match ipv4 destination address
 match ipv4 destination mask
 match transport source-port
 match transport destination-port
 match interface input
 collect interface output
 collect routing source as
 collect routing destination as
 collect transport tcp flags
 collect counter bytes long
 collect counter packets long
 collect timestamp sys-uptime first
 collect timestamp sys-uptime last
!
!
flow exporter exporter-comcert
 destination <IPcollecor>
 source <sourceIPflowexports>
 transport udp 2055
 template data timeout 60
 option sampler-table timeout 60
!
!
flow monitor monitor-comcert
 exporter comcert-1
 cache timeout active 60
 cache timeout inactive 14
 record recordnf9-comcert
!
!
interface GigabitEthernet1/1/1
 bandwidth 20000
 ip flow monitor monitor-comcert input
 ip flow monitor monitor-comcert output
!
!
interface GigabitEthernet2/1/1
 bandwidth 10000
 ip flow monitor monitor-comcert input
 ip flow monitor monitor-comcert output