Flow protocols in real-world environments

Over the years, libraries have been filled on the topic of flow protocols—specifically, how they work and their general accuracy.

One of the things that can be confusing is that there are a lot of different flow protocol names. Behind the many variants, there are actually only two major technologies related to capturing and recording traffic-flow metadata. The first is based on stateful flow tracking, and the other is based on packet sampling. Both ideals are explained below. But first, based on that fundamental difference, let’s classify common flow protocols as follows:

Stateful flow tracking:

NetFlow: Originally developed by Cisco in 1996. The most used versions are v5 and v9. Other vendors support NetFlow but call it something else, including J-Flow (Juniper), cflowd (Alcatel), etc.

IPFIX: The IETF standards-based successor to NetFlow, sometimes referred to as NetFlow v10.

Packet sampling:

sFlow: Launched in 2003 by a multi-vendor group (sflow.org) that now includes Alcatel, Arista, Brocade, HP, and Hitachi.

Flow tracking vs. packet sampling

So what’s the difference between the stateful flow tracking of NetFlow and the packet sampling of sFlow? Routers and switches running NetFlow/IPFIX designate a collection of packets as a flow by tracking packets. They typically look for packets that come from and go to the same place and share the same protocol, source and destination IP address, and port numbers.

This tracking requires CPU and memory—in some circumstances, a huge amount of it. For example, with a forged source-address DDoS attack, every packet can be a flow, and routers have to try to maintain massive tables on the fly to track those flows! Also, to cut down on CPU and network bandwidth, flows are usually only “exported” on average every 10 seconds to a few minutes. This can result in very bursty traffic on sub-minute time scales.

sFlow, on the other hand, is based on interface counters and flow samples created by the network management software of each router or switch. The counters and packet samples are combined into sFlow datagrams that are sent across the network to an sFlow collector. The preparation of sFlow datagrams doesn’t require aggregation and the datagrams are streamed as soon as they are prepared. So while NetFlow can be described as observing traffic patterns (“How many buses went from here to there?”), with sFlow you’re just taking snapshots of whatever cars or buses happen to be going by at that particular moment. That takes less work, so the memory and CPU requirements for sFlow are less than those for NetFlow/IPFIX.

Retention scale and depth of analytics

Whether you’re running an enterprise, web company, cloud/hosting, ISP, or mobile/telco network, you’re likely running significant volumes of traffic, which makes it critical to be able to retain flow records and analyze them in detail at scale. Most flow collectors of any note can handle a fairly high level of streaming ingest, but that’s where their scalability ends. With single-server or appliance systems, detail at the flow-record level isn’t retained for long, if at all. Instead you get summaries of top talkers, etc. We talk to tons of users of these legacy tools and they tell us what we already know: those few summary reports are neither comprehensive nor flexible enough to be informative about anything below the surface.

Scrutinizer solves the granularity issue

Our platform ingests massive volumes of flows, correlates them into a synthesizable parts (1m, 5m, 60m data points) with IP groups, performance, and other data, and retains records indefinitely (with supporting storage). You can perform ad-hoc analysis on billions of rows of data without any predefined limits, using multiple group-by dimensions and unlimited filtering.

If you’re not yet familiar with Scrutinizer, we’d love to show you; contact us to schedule a demo to walk you through it!