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 traffic volumes.
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 netflow implementation.
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.
http://www.inmon.com/pdf/sFlowBilling.pdf
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 fast boxes. 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. Nick