sFlow Vs IPFIX

If you are a vendor considering whether to implement sFlow Vs IPFIX (IP Flow Information eXport), this post will help you understand the differences and benefits of the technologies.  Both technologies were developed to gather statistical details from the routers, switches, firewalls and servers they reside on.

Standards

IPFIX is the proposed IETF standard for flow technologies, whereas sFlow is a proprietary technology owned by InMon. Although InMon references sFlow as a standard or RFC, no standard exists for sFlow.

Because IPFIX is becoming the industry standard, it benefits from the collective engineering efforts of thousands of individuals in the Internet community.  Dozens of companies including Cisco provide the innovation for IPFIX. Although several companies have implemented sFlow, the innovation generally comes from one company: InMon.  The most recent version of sFlow (i.e. v5) was published in 2004.

SFlow Uses

1. It exports counters as well as other details using a push technology rather than a poll technology like SNMP.  Examples include interface counters and CPU utilization.
2. It exports random or predetermined packet samples – not actual flows as its name would imply.

IPFIX Uses

It is used to export details on the traffic flowing through the appliance; it can also be used to export systems details.  Not only has IPFIX become the standard for NetFlow, it is also evolving as a possible replacement for syslog technology.  It can even be leveraged to export SNMP counters (i.e. like sFlow) in real time.

Cost to Implement IPFIX Vs sFlow

IPFIX is free to anyone in the world who wants to implement it.  It can be implemented in hardware or software. sFlow is primarily a hardware technology, and the only vendor manufacturing chips for it is InMon.

Packet Sampling

Both sFlow and IPFIX can be used to export sampled packets.  IPFIX can be used, as demonstrated by Cisco with the Catalyst 4948E, to sample packets at line rate (i.e. 100% of the packets) in real time.  The sFlow technology can only sample 1 out of every X packets. The fastest sampling was seen on the Foundry sFlow capable switch, which sampled 1 out of every 2 packets (i.e. every other packet). Neither technology is limited to IP as both IPFIX and sFlow can be utilized to sample legacy network layer protocols such as IPX, Appletalk, etc.

Packet Sampling Vs. Flows

What is a flow? “A flow is a sequence of packets from a sending application to a receiving application (Source IETF).” IPFIX is a true flow technology.  On the other hand, sFlow is not a flow technology at all.

When comparing packet sampling with Flow technologies in real time environments, administrators will notice immediately that the top 10 hosts or applications will differ considerably.  In real time trouble shoots, where only the last 5 or so minutes are being observed, packet sampling maybe only be about 50% accurate.  Packet sampling will more accurately represent the top N applications or hosts as time goes on.  For some reports (e.g. top hosts), at least an hour should pass before a packet sample trends can be considered for a fairly accurate baseline (see the 2008 study on sFlow Vs. NetFlow).  For this reason, sFlow is often not a reliable real time trouble shooting technology.

Flow Sampling Vs. Packet Sampling

There is a book written by Benoit Claise and Ralf Wolter which outlines the different ways flow sampling can be performed, as well as the corresponding accuracy when representing all traffic.  In short, packet sampling by itself is fairly representative of what is passing through the device.  A multiplier used on samples often leads to misleading representation.  For example, a multiplier of 1000 on a packet that was only seen 3 times, will grossly overstate frequency.  Flow sampling on the other hand, can give all flows, regardless of packet volume, an equal chance of being sampled.  Sampling of the flows can be random or deterministic, but in either case, use of a multiplier can have the same negative impact as it does on sFlow.

How to avoid Flow Sampling

In short, all you have to do is modify the matching tuple to dramatically reduce the amount of flows being exported, yet still maintain 100% accuracy; the compromise is on the details.  Below is what many consider a traditional flow matching tuple:

• Source interface
• Source port
• Source IP address
• Destination port
• Destination IP address
• Protocol
• ToS / DSCP

If you simply remove the source port and the destination port from the match, you could witness a 95% reduction in flow volume.  If on the other hand you can’t compromise on application details, enable NBAR or the equivalent and get more accurate application details without the random port issues. Flow volume will, of course, go back up a bit with NBAR included in the export, but it won’t increase like it would when including the source and destination ports.

Real Time

Both IPFIX and sFlow are intended to support real time exports and samples of data, including packets.  In fact, NetFlow also supports it. However, being real time is not always advantageous.  One of the benefits of having a router that maintains a flow cache, is that a single exported flow can represent tens of thousands of packets. A single IPFIX datagram can represent a few dozen flows.  Keep in mind that both packet sampling and flow exports can add excessive overhead to the hardware, however, packet sampling scales poorly in comparison to true flow technologies.  With sFlow, your only option is to sample less which means a longer time to wait before your reports render accurate results.  Regardless of your preference, IPFIX supports both flow and packet sampling technologies and sFlow does not.

The future is IPFIX

The bottom line: IPFIX has all of the benefits of both sFlow and NetFlow, it is own by the Internet community and it scales dramatically depending on the vendor implementation (I.e. can the tuple be modified).  If you are looking for information on vendors supporting IPFIX or sFlow, we maintain a page with all of these details.  If you’re wondering about the future of sFlow (i.e. sFlow v6), in all likelihood it is probably going to be IPFIX.