RE: Real world sflow vs netflow?

[James Braunegg <james.braunegg () micron21 com>]

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.braunegg () 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:nick () 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