[156687] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Real world sflow vs netflow?

daemon@ATHENA.MIT.EDU (Peter Phaal)
Sat Sep 22 14:52:31 2012

In-Reply-To: <4D7095F3-6FA5-4507-AA49-D5192BA58437@arbor.net>
Date: Sat, 22 Sep 2012 11:51:35 -0700
From: Peter Phaal <peter.phaal@gmail.com>
To: "Dobbins, Roland" <rdobbins@arbor.net>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

On Fri, Sep 21, 2012 at 10:02 PM, Dobbins, Roland <rdobbins@arbor.net> wrot=
e:
>
> On Sep 22, 2012, at 12:40 AM, Peter Phaal wrote:
>
>>  However, moving the flow generation out of the router gives a lot of fl=
exibility.
>
> 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 tra=
ceback where traffic is ingressing your network, which is key for both secu=
rity as well as traffic engineering, peering analysis, etc.
>
> It is far, far better to get your flow telemetry from your various edge r=
outers, if at all possible, rather that probes.  Scales better, too - and i=
s 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


home help back first fref pref prev next nref lref last post