Configuring flow export

Introduction

Correct configuration of Flow Exporting Devices (FED) is key to Flow Based Network Analysis. Mistakes made during configuration will result in missing and duplicated data.  They are difficult to identify. Vendors of network equipment are not making it easy as many of them are using some sort of proprietary method to enable flow export on their devices.

Furthermore, Flow Collector (FC) and FED must allign on configuration parameters in order to interpret the records correctly.

This article creates a vendor independant framework to configure flow exports.  We hope it will help you to confgure your FED.

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

If you come aware of vendor specific issues thay may help others, please let us know.

 

Solution

Definitions

Flow Enabled Device or Flow Exporter

Flow Enabled Device of Flow Exporter is a device configured to send flow records to one or more collectors.  This can be a L2 or L3 device.

Flow or IP Flow

Flow is formed by all packets between two TCP/IP sockets.  Therefore, what we call a TCP sessions consists of two flows: one flow from client to server and the second flow from server to client.

Flow record

Flow record contains information about a specific flow that was metered at an observation point.  A flow record contains measured properties aggregated for the flow.  Key record fields are source and destination IP addess, protocol, source and destination port, number of bytes, number of packets, duration and input and output interfaces.  There could be many more.

Sensor

Sensor is a metering point in the device. Sensors are associated with interfaces.  It will quantify and qualify packets in or out of that interface, leading to the creation of a flow record decribing the flow.  It is very important to realize a sensor will measure packets in one direction only (ingress or egress). 

Collector

Flow collector is a server application that receives the flow records and stores them in a database. In TruView, TruView Flow is the collector.  In nGeniusONE, the Flow Collector is the collector.  The sizeof the hardware will depend on the number of flows received per second and the aging time of the "raw" flow records.

Reporter

Flow reporter is a server application mining the data records, producing tables and charts and possibly alerts.  In TruView, TruView Central is the reporter.  In nGeniusONE, nGenius Server is the reporter.  When the number of flows received per second is low (<50k/s), collector and reporter can be installed on the same hardware.

 

Global configuration

The way to enable flow monitoring and flow exports will vary from vendor to vendor.  In general there are two major portions.  In Global Setting you set parameters on the flow and the export mechanism itself.  Interface Settings let you decide where to deploy sensors so that all flows through the device are accounted for.

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 most cases, this is one minute or 60 seconds. 

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 Flexible NetFlow and the standardization of IPFIX, the PDU of a flow record is no longer uniquely defined. The fields contained in the PDU should match the reporter's capabilities of reporting on the value represented in that field.  These fields should be present at all times:

• source address
• destination address
• type of service
• protocol
• source port
• destination port
• input interface
• output 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

Additional fields may be required in case of sampling or to help indicating the in and out interfaces on a L2 device.

 

Interface configuration examples

 

 

Basically, this is the science of deploying sensors so that EVERY flow that goes through the device is metered once and NO flow is metered more than once.  

Example 1: Ingress sensor on all interfaces.

Flows from user to network are metered by the ingress sensor on interface 0/0 while flows from network to user are metered by the ingress sensor on interface 0/1.  If the device has more than two active interfaces, deploy ingress sensors on all these interface. 

2ArmedRouterNIUI.png

Example 2: egress sensor on both interfaces

Flows from user to network are metered by the egress sensor on interface 0/1 while flows from network to user are metered by the egress sensor on interface 0/0. If the device has more than two active interfaces, deploy egress sensors on all these interface. 

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 Flexible NetFlow configuration example

Consider this topology:

 

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. In order to avoid manual configuration of the collector, the collector must be able to user snmp(*) to the FED.  Also, you need to set the correct speed (ULR or CIR) for the circuit behind the physical interface to allow correct calculation of interface utilization (%).

(*)at least read-only on 'system,' 'interfaces" and IfMIB 

 

ip access-list standard SNMP-RO
 permit 1.2.3.4
snmp-server community notsecure RO 
!
!
flow record recordnfv9
 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 exporternfv9
 destination <IPcollecor>
 source <sourceIPflowexports>
 transport udp 2055
 template data timeout 60
 option sampler-table timeout 60
!
!
flow monitor monitornfv9
 exporter exporternfv9
 cache timeout active 60
 cache timeout inactive 14
 record recordnfv9
!
!
interface GigabitEthernet1/1/1
 bandwidth 20000
 ip flow monitor monitornfv9 input
 ip flow monitor monitornfv9 output
!
!
interface GigabitEthernet2/1/1
 bandwidth 10000
 ip flow monitor monitornfv9 input
 ip flow monitor monitornfv9 output