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


Reply via email to