Real world sflow vs netflow?

Fri Sep 21 17:40:40 UTC 2012

On Thu, Sep 20, 2012 at 11:21 AM, Mikael Abrahamsson <swmike at swm.pp.se> wrote:
> Most of the platforms I know of do sampled netflow at 1:100-1:1000 or so,
> and then I don't really see the fundamental difference in doing the flow
> analysis on the router itself (classic netflow) or doing the same but at the
> sFlow collector.

There is no difference in the flow records you would obtain in either
case. However, moving the flow generation out of the router gives a
lot of flexibility. You can now choose how you want to generate flows,
rather than depend on the router vendor. You are also guaranteed
multi-vendor interoperability since problems associated with
differences in how each vendor generates flows are eliminated.

For a real world example on the need for flexibility in monitoring,
consider the challenge posed by IPv6 migration and virtualization as
they greatly increase the amount of layer 2, 3 and 4 tunneled traffic.
With an external software based flow generation you can easily upgrade
the software to report flows within the tunnels etc.

http://blog.sflow.com/2012/05/tunnels.html

There are many other things you can do with packet oriented (sFlow)
data besides flow generation and analysis that I think are worth being
aware of:

1. Route analytics. Packet forwarding decisions are made on a packet
by packet basis and sFlow accurately captures the forwarding decision
made for each sampled packet (flows are not a good way to report
forwarding decisions since you are forced to assume that the all
packets in the flow took the same forwarding path, which may not be
the case). With packet oriented measurements you can build a route
cache and use it to understand traffic forwarding based on AS-path,
next hop router etc.

2. Analysis of multi-path forwarding. Detailed visibility into
per-packet forwarding lets you diagnose issues with unbalanced LAG
groups, ECMP paths, TRILL paths etc.

3. Packet sizes. With packet oriented data you can easily calculate
packet size distributions by protocol, DSCP class, egress port etc.

4. DDoS detection and mitigation. Analysis of the sampled packet
stream can detect DDoS attacks within seconds and an automatic
response can be constructed using packet forwarding and header
information to find a signature for the attack, point of ingress etc.
You can also use packet analyzers like Wireshark and tcpdump to look
at the sFlow packet header records,
http://blog.sflow.com/2011/11/wireshark.html

5. Packet counters. MIB-2 interface counters are included in the set
of measurements that sFlow exports. Eliminating SNMP polling reduces
CPU load on the router (I have seen very high router CPU loads
associated with SNMP) and provides much faster updates on link
utilizations, packet discard rates etc.

I think Nick Hilliard put it well:

> Flows are good for measuring some things; raw packet sampling is good for
> measuring others.
>
> Decide on what you're trying to measure, then pick the best tool for the job.

However, to choose intelligently requires an understanding of the
fundamental differences between packet oriented and flow oriented
measurements, particularly as to how those differences relate to the
problem you are trying to solve. The two types of measurement are
related, but not the same.