First of all, I’m a fan of sFlow, NetFlow, IPFIX, NetStream, JFlow, etc. I like them all.  In this blog I would like to point something out that a customer made clear to me about sFlow.

IPFIX, NetStream, JFlow are all ‘NetFlow’ like technologies. These NetFlow technologies are truly ‘flow’ based.  On the other hand, sFlow is not.  It is a packet sampling technology. It has BIG benefits;  however, the benefits are very different from a flow-based protocol such as NetFlow and IPFIX. Lets take a look at the definition of a flow.

What is a Flow?

By definition: “A flow is a sequence of packets from a sending application to a receiving application.”

sFlow sampling does not sample packets in every flow.  It samples every X packet regardless of any flow. To the best of my knowledge, sFlow has no awareness of ‘flows’ at all. The way I understand it (which could be wrong) sFlow is not a flow technology at all, rather it is a packet sampling technology. In fact, many or often times most flows go completely unsampled with sFlow.  To be clear: sFlow doesn’t sample a packet within a flow, it samples every X (e.g. 1000th) packet on an interface.

For this reason, the customer jokingly suggested that sFlow be renamed ‘sPacket’. This is because sFlow is a technology where every X packet on an interface is sampled and exported off to a sFlow collector.  Multiple sFlow samples can be stuffed into a single sFlow datagram and sent off to the sFlow reporting tool.  The technology has its benefits however, lets clarify a few things.

sFlow Misconceptions:

  • Misconception: sFlow is real time and NetFlow exports session information after a flow is complete.
    • Correction: NetFlow has an active timeout which exports a summary of active conversations every 60 seconds.  You don’t have to wait until the end of the flow.  However, with the Cisco ASA you do as it doesn’t support the active timeout. Everything else from Cisco and every other vendor I’m aware of supports the active timeout feature. BTW: sFlow is close to real time and likely won’t capture the packet you wanted nor was it intended to.
  • Misconception: the most sFlow can sample is one in every 100 packets and it only samples the first X bytes.
    • Correction: with most vendors, this is configurable.  Foundry’s sFlow support can sample every other packet! If a single packet is large, it may be broken up and sent in a couple of sFlow datagrams.  So, a whole – single – very large packet can be sent in sFlow.  I think this is very cool about sFlow.
  • Misconception: sFlow is hardware based.  NetFlow is software based and could severely impact the CPU.
    • Correction: This is partially true.  Many vendors (e.g. Cisco and Enterasys) have implemented NetFlow in hardware chips just like sFlow.  In my experience, 95% of NetFlow implementations have little to almost no impact on CPU utilization.
  • Misconception: sFlow exports layer 2 information (e.g. MAC address) and NetFlow doesn’t.
    • Correction: NetFlow v9 and Flexible NetFlow export the MAC address as do several other vendors supporting NetFlow or IPFIX (e.g. Enterasys, Juniper, nProbe, SonicWALL and others). I should also mention that NetFlow can export VLAN information.  I wonder if sFlow export VLAN information?
  • Misconception: NetFlow can’t sample traffic like sFlow.
    • Correction: NetFlow sampling is available and works fine.  It doesn’t however provide a counter export like sFlow which is a real bummer when trying to calculate total throughput.  NetFlow sampling could learn from sFlow here.

I deal with sFlow analysis a lot and I like the technology. The reason I wrote this blog is because often times people want their sFlow reports to be as accurate as their NetFlow reports and this isn’t ever going to happen. Here is a good blog on NetFlow vs sflow.  sFlow is what it is, a sampling technology and it is awesome to have around especially when there is no other option for gaining traffic insight.  sFlow can help save the day!

My sFlow wish

I wish the folks behind sFlow would improve the technology. What are the latest advancements in sFlow exports?  NetFlow is now exporting VoIP information such as Jitter, packet loss and Latency.

When to use sFlow

Enable sFlow on your switches and take advantage of this awesome technology. It can help you accurately determine top talkers, applications, etc. Be careful with the sample rate as it could overwhelm even the fastest sFlow collector.

When to use NetFlow

If you want to answer questions like the following with accurate results, I suggest NetFlow:

  • Who is using DNS (i.e. port 53)?  What DNS servers are they connecting to?
  • Who is using SMTP? What machines are spamming.

Thanks for reading.  Also, check out NetFlow Vs. sFlow: which is better?

James Dougherty

James Dougherty

I have worn many hats in my professional life. Support engineer, developer, network admin and manager are all points on my resume, but the one common thread with all of these jobs is that I enjoy working with people; that is what I do here at Plixer. I make sure that everyone understands our product and can get the most out of it. It's just simple 'no bull' support!

Let me know if you have any questions, I would be happy to help.

- Jimmy D

Related

Big Data

Sankey Flow Graph

One of the greatest benefits of NetFlow collection for traffic analysis, is we’re provided with the ability to visualize the…

2 comments on “sFlow Myths : sFlow is really sPacket

  1. yes sFlow supports sending of VLAN information. Another thing sFlow supports that I have not seen a way to do in Netflow is BGP AS-path information. Only Src AS and DST AS seem to get encoded into Netflow.

Comments are closed.