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 export on their devices.
Furthermore, collector and FED must agree on configuration parameters in order to interpret the records correctly.
This article creates a vendor independant framework for configuring flow exports. W 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 reading 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 a device configured to send flow records to one or more collectors.
Flow
A flow is defined as all the packets flowing between any given source and 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 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
A sensor is a meter located at an observation point. It will "meter" the packets passing 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).
Collector
A 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.
Reporter
The reporter is a server application that mines the data records and produces statistical results. In TruView, TruView Central is the reporter. In nGeniusONE, the nGenius Server is the reporter. Especially in smaller envirionments, 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. 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
 | If this is your first experience with configuring flow export on network devices, we recommend you make a drawing of the device, its interfaces (physical and virtual) and every flow that goes through the device. |
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.
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.
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.
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.
Cisco Flexible NetFlow configuration example
Consider this topology:
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. To avoid manual configuration of the collector, it needs to be able to reach the device with snmp (read-only suffies) Also, you may need to configure the speed (bps) of the circuit behind the physical interface for correct calculation of interface utilization (%).
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