Real world sflow vs netflow?
nick at foobar.org
Sun Jul 15 20:52:50 UTC 2012
On 14/07/2012 09:30, Łukasz Bromirski wrote:
> And that's the biggest problem with sFlow. Packets are sampled, not
> flows. You may miss the big or important flow, you don't have
> visibility into every conversation going through the device.
Unless you enable sampling, which is pretty much necessary for non-trivial
> NetFlow supports IPv6. As well as L2 traffic (v9), MPLS, multicast and
> so on.
It does, depending on hardware variety, but you need specific platform
support for each packet variety (v4 / v6 / mpls / etc), and platform
support for this can be very dodgy. You don't need this with sflow - it
just punts 1 in N raw packets out to your collector, and the statistical
assumptions which were made by the networking device are well documented.
I've never seen documentation on the sampling technique used for each
> The measurements provided by sFlow are only approximation of the real
> traffic and while it may be acceptable on LAN links where details don't
> matter as much, it's hardly good enough to present a real view on the
> WAN links.
> sFlow was built to work on switches and provide "some" accuracy, it's
> not good enough (unless you do sampling on a 1:5-1:10 basis) to
> do billing or some detailed analysis of traffic:
Depends on how detailed your requirements are. For billing, most people
don't classify by packet analysis, but rather by byte count which can be
handled by snmp port counters. If you need to do something fancier,
non-sampled netflow is indeed good enough for billing.
> You can use it to *estimate* the traffic, detect DDoS, sure. But the
> data & scaling used by sFlow (and additionally tricks used by ASIC
> vendors implementing it in the hardware) can't change the fundamental
> difference - sFlow is really sPacket, as it doesn't deal with flows.
agreed, the name is wrong.
> NetFlow, jFlow, IPFIX deal with flows. You can discuss sampling
> accuracy and things like that, but working with flows is more accurate.
Depends on your use case. For large traffic values, you run into the law
of large numbers and you can get accurate visibility into what's happening
on your network.
Certainly, netflow _can_ offer amazingly precise visibility into your
network. But the trade-off is that you need specialised hardware to do
this on your line cards or your forwarding engine. This drives up both the
capex (extra hardware) and the opex (tcam is power hungry) of your network.
sflow is much cheaper to implement as you're not maintaining any state on
your chassis. You're just picking out a packet every so often.
The current generation of high end service provider hardware (juniper
mx-3d, cisco sup2t / n7k / asr9k) is pretty much the first generation of
hardware which doesn't have crippling netflow limitations, such as poor
support for v6 / mpls, too small cache sizes, etc. This fact alone should
provide a good indication of how difficult it is to implement it well on
sflow is simpler, cheaper and in many cases is simply a better choice if
you don't need drill-down into every single flow going through your networking.
More information about the NANOG