Capture and Management of Flow Information

Capture and Management of Flow Information

Traffic flow information as defined in the context of the IETF IPFIX framework has many applications in relation to understanding the patterns of communication in a network. This aids in network planning, capacity management and security incident detection and reporting, among others.

Generating flow information may impact the concerned network elements in different ways depending on the specific Layer 3 Forwarding Architecture used in various sizes and kinds of platforms. The generated data may also be presented in different ways, as some platforms simply export raw data and others perform aggregation prior to export of the data to collectors.

• ASIC-based forwarding with flow information generation in hardware – These platforms are typically not impacted by flow collection or potential aggregation. Typically a local CPU is employed that is responsible for performing the actual export of flow information with the load profile being affected by the volume of information needing export.
• NPU with a programmable forwarding path – Some, but not all, NPUs have native flow collection support. For the ones that do not, there is typically a minor impact from the generation of flow information. As in the previous category, an external CPU will be responsible for flow information export.
• CPU-based forwarding – In this architecture any action that must be taken adversely affect performance and there’s typically a single CPU that must deal with packet forwarding as well as flow export and hence a more significant performance impact is to be expected.

In current generation platforms, typically used in the PSN and for MPLS based solutions in HSCN high-end routers fall into one of the first two categories and all other devices with very few exceptions are built using dedicated NPUs. Depending on the type of NPU the performance impact from flow collection will vary, high-end NPUs rarely suffer more than a 10-15% impact (e.g. Cavium).

Data volumes can be significant when dealing with flow information capture and the resulting export of collected data. The volume of exported data is directly proportional to the number flows being retired over a given window and only consists of the Layer3/4 information for those captured flows. Using the existing IPFIX standards for the format of export records the amount of information for each individual flow typically varies between 64-100 bytes depending on configuration. Without going into details on packet formats and such, the data export from a device retiring 100 flows per second will be around 23–36MB / H consuming roughly 6.5-11Kbps of bandwidth. This includes complete flow information with no pre-aggregation or sampling of traversed flows.

In the Software-Defined WAN environment for HSCN, the collection of flow information is not statically configured, but rather dynamically controlled with the assistance of an intelligent policy infrastructure enjoying enablement via a dynamic control plane. These mechanisms can greatly complement a traditional flow capture approach by eliminating the static and fixed nature of collection in the SD-WAN domain and replacing it with a dynamic approach.

A centralized SD-WAN controller is capable of dynamically controlling flow capture to provide an environment with the following attributes:

-Flow capture locations can be dynamically altered by means of a policy change

-Flow capture scope can be dynamically altered by means of policy changes to vary the inclusion of applications, source and destinations and target VPNs

-Collectors can be added and removed dynamically to respond to changes in demand directly related to the volume of data generated

-Collectors in different target domains, such as NOC, SOC and Billing can be dynamically added or removed

The use of SD-WAN technology does not typically increase the quality of captured flow information from any one location but does make the collection process more dynamic and responsive to potentially changing conditions during the course of capture. Something that should lead to improving overall information management and a more powerful environment for flow capture overall.

To provide for some real-life information, a Public Sector user having deployed a SEN solution saw the following flow generation across 1000 sites in their network:

• Peak hour flow-generation: 300K flows being retired per minute
• Average flow-generation / 24 hours: 141K flows being retired per minute

These numbers translate to five flows per second per site at peak hour across the entire network, clearly a low number with respect to the impact on a per site basis. The emphasis based on such a number immediately shifts to the collection side of the architecture.

Collection and Analysis of Flow Information

While capturing flow information is inherently exciting it does come with a set of challenges related to the mere volume of data generated. Different types of devices generate more or less verbose flow records resulting in variations in the type of information that can be extracted. Scaling a flow collection function hence becomes a function of the capability to store large volumes of information, supporting a sufficient number of devices and providing a scalable and efficient analytics and reporting capability.

In recent years several vendors that specialize in the collection, storage and analytics of flow information, some in combination with other sources of information, have surfaced to approach this challenge differently. One of these vendors that also haveforged relationships with SD-WAN vendors is SevOne ( They approach the challenge by employing an appliance-based architecture that can expand dynamically to match the installed base of flow-information generating devices.

A single SevOne DNC (Dedicated Netflow Collector) can scale to deal with 250000 flows per second from up to 1000 Netflow interfaces. Granular information is stored for seven days and aggregated data can be store for up to 12 months. Reports are generated in a way where multiple appliances process report requests concurrently to quickly service suchtasks. Events can also be tracked and correlated across multiple data sources for more advanced troubleshooting and interrogative exercises.

There are also other vendors, such as NetScout ( with their TruView platform that provide similar solutions.