Configuring flow export: Difference between revisions

From wiki.comcert.com
Jump to navigation Jump to search
No edit summary
No edit summary
Line 66: Line 66:
 
 


{{#invoke:Message box|ambox |type=content|text=If this is your first experience with configuring flow exports on network devices, we recommend you make a drawing of the device, its interfaces and every flow that goes through the device.}}
{{#invoke:Message box|ambox |type=info|text=If this is your first experience with configuring flow exports on network devices, we recommend you make a drawing of the device, its interfaces and every flow that goes through the device.}}


 
 

Revision as of 18:44, 14 January 2018

Introduction

Correct configuration of Flow Exporting Devices (FED) is key to Flow Based Network Analysis. In most cases, errors made during configuration will result in missing or duplicate data. It may be difficult to spot that because of this the flow data is compromized. Device vendors are not making it easy and most of them use different methods to enable network flow exports to the collector (in our case TVF or TVA).

Furthermore, some collectors require a special setting on FED in order to undersand its flow records correctly.

This article is trying to decribe the idea 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 are aware of vendor specific issues with the configuration of flow exports, it is greatly appreciated if you let us know.

 

Solution

Definitions

FED

Flow Enabled Device is any L3 and in some cases L2 device sending flow records to a collector.

Flow

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 interface where the packets entered and exited 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 "observe" packets going by the observation point and "build" the flow record decribing the flow.  A sensor will meter packets in one direction only (ingress/in or egress/out) but some vendors use sensors that are bidirectional. Historically, a sensor was ingress/in only, so if left unspecified by a vendor, you may assume the sensor being unidirectional and ingress/in only.

 

Global configuration

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

Destination

IP address of the collector

Port

UDP port where the collector is listening

Active flow timeout

Interval to send flow record updates in cse of a long duration flow. 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 collector's capabilities. In case of TruView this is

 

Interface configuration

 

 

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 NO flow is metered more than once.  

 

Cisco example