sFlow vs netFlow/IPFIX

Sun Feb 28 22:40:47 UTC 2016

Todd Crane wrote:
> This maybe outside the scope of this list but I was wondering if
> anybody had advice or lessons learned on the whole sFlow vs netFlow
> debate. We are looking at using it for billing and influencing our
> sdn flows. It seems like everything I have found is biased (articles
> by companies who have commercial offerings for the "better"
> protocol)

There is a lot of religion floating around about this subject.

Netflow was designed to measure flows, and it turned out that the design
was robust enough for it to be more-or-less good enough for billing
purposes. It's "more or less" because on larger routers, you can't do
1:1 data export and you end up needing to do traffic sampling, at which
point you're billing based on realistic estimates rather than exact
data.  That's fine if your contract with your customer says it's ok.

Netflow works by tracking individual flows in the data plane.  This is
pretty complicated in practice and requires dedicated hardware to handle
it at line rate.  You generally end up with two packet forwarding
engines on a hardware-forwarded router: one to handle the forwarding,
and the other to categorise and handle the flow data.  This means that
netflow is expensive to design, build and run.

Sflow is a simple packet header sampling mechanism.  The only thing it
does is to pick out every 1 in N packets, and to try to figure out where
the headers stop and the data begins.  The header is then forwarded to
the sflow collector, which is where all the smart stuff is done.

If your netflow / sflow packet sampling mechanism is accurate and your
router is configured appropriate for the quantity of flow data being
exported (i.e. it isn't dropping data samples due to overload), then for
the most part, there will be no substantial difference between using
sflow and sampled netflow (depending on the data flow type), assuming
that each protocol provides the data you're looking for.

Obviously, if your sampling mechanism is broken or your exporter is
overloaded, then both sflow and netflow will produce trash.

If you're using unsampled netflow, then netflow will be more accurate,
assuming you don't end up overflowing the netflow data export mechanism.

Anything which uses sampling - regardless of whether it's for netflow or
sflow - needs to be profiled before being pushed into production,
because you need to understand the limits of the sampling mechanism.
Hardware sampling often doesn't work properly or plateaus off at a
certain stage, dropping packets in the process.  This can cause
unwelcome surprises.

Without knowing anything more about your requirements or your choice of
equipment, I'd suggest that sflow would probably be a better choice for
SDN tuning and probably netflow would be better for billing, but YMMV.

Nick