Real world sflow vs netflow?
peter.phaal at gmail.com
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.
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.
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.).
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.
4. sFlow has lower OPEX, the architecture is simpler, has lower
operational complexity and provides much greater scalability.
More information about the NANOG