Dear All Around a year ago I had the same debate sflow vs netflow vs snmp port counters. read lots of stories lots of myths lots of good information. My Conclusion
In the end I did real life testing comparing each platform We routed live traffic (about 250mbits) from our Cisco 7200 G2 routers though Brocade MLXe routers and exported netflow from the Cisco platform and sFlow from the Brocade platform. Each router sent netflow/sflow traffic to two collectors on independent hardware (same specifications) running the same collection netflow analyzer software. The end result was after hours of testing, or even days and weeks of testing there was no significant difference between traffic volumes netflow was showing vs slfow. Ie less than 0.5% variance between each environment. That being said both netflow and sflow both under read by about 3% when compared to snmp port counters, which we put to the conclusion was broadcast traffic etc which the routers didn't see / flow. Regardless if you're going to bill from netflow or sflow in our test environment we saw no significant difference between either platform. Hope that helps Kindest Regards James Braunegg W: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616 E: james.braun...@micron21.com | ABN: 12 109 977 666 This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer. -----Original Message----- From: Nick Hilliard [mailto:n...@foobar.org] Sent: Monday, July 16, 2012 6:53 AM To: nanog@nanog.org Subject: Re: Real world sflow vs netflow? 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
