Real world sflow vs netflow?

Sat Sep 22 18:51:35 UTC 2012

On Fri, Sep 21, 2012 at 10:02 PM, Dobbins, Roland <rdobbins at arbor.net> wrote:
>
> On Sep 22, 2012, at 12:40 AM, Peter Phaal wrote:
>
>>  However, moving the flow generation out of the router gives a lot of flexibility.
>
> Actually, moving it out of the router creates huge problems and destroys a lot of the value of the flow telemetry - it nullifies your ability to traceback where traffic is ingressing your network, which is key for both security as well as traffic engineering, peering analysis, etc.
>
> It is far, far better to get your flow telemetry from your various edge routers, if at all possible, rather that probes.  Scales better, too - and is less expensive in terms of both capex and opex.

Roland,

I probably wasn't as clear as a should have been in describing how
sFlow works. Here are some comments and links to additional
information that address each of your concerns:

1. There are no probes involved when using sFlow, the architecture
looks very similar to NetFlow with UDP records streaming from multiple
routers to a software collector.

http://blog.sflow.com/2009/05/choosing-sflow-analyzer.html

2. The sFlow records exported by the router include telemetry that
allows you to trace traffic paths through the network (ingress port,
egress port, FIB entry etc.).

http://blog.sflow.com/2009/05/packet-paths.html

3. sFlow has a lower CAPEX,  the flow cache resides in inexpensive
memory on a commodity server instead of limited, expensive, TCAM
memory on the router. The sFlow instrumentation is included in ASICs
and is a base feature of the device; unlike NetFlow which often
requires upgraded supervisor cards etc. sFlow is widely supported in
merchant silicon, further reducing costs and increasing multi-vendor
interoperability - Cisco supports sFlow in the merchant silicon based
Nexus 3k series.

http://blog.sflow.com/2010/09/superlinear.html
http://blog.sflow.com/2011/12/merchant-silicon.html
http://blog.sflow.com/2012/09/vendor-support.html
http://blog.sflow.com/2012/08/cisco-adds-sflow-support.html

4. sFlow has lower OPEX, the architecture is simpler, has lower
operational complexity and provides much greater scalability.

http://blog.sflow.com/2010/11/complexity-kills.html
http://blog.sflow.com/2010/09/superlinear.html

Peter