Re: Real world sflow vs netflow?

[Łukasz Bromirski <lukasz () bromirski net>]

On 7/13/12 10:20 PM, Peter Phaal wrote:

> 1. NetFlow: Packets are decoded on the router, flow keys are extracted
> and used to lookup/create an entry in a flow cache which is then
> updated based on values in the packet. Records are exported from the
> flow cache in the form of Netflow datagrams when the flow completes or
> based on a timeout.

This is because NetFlow is based on the Flows, where sFlow name is
misleading - it's actually PACKET monitoring technology, not FLOW
monitoring. So the difference in the way both mechanisms work is
inline with their definition.

> 2. sFlow: Packets are randomly sampled in hardware and the packet
> headers are immediately exported as sFlow datagrams - there is no flow
> cache on the switch/router.

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.

sFlow and randomized sampling rely heavily on statistics, but as soon
as you agree on that, you'll loose accuracy right away.

> Moving the flow cache off the router has a number of benefits:
> 1. You are no longer limited by the hardware/firmware capabilities of
> the router - your analysis software decides which fields to decode and
> how to accumulate results. For example, if you are managing a mixed
> IPv4/IPv6 environment you can decide to use sFlow to look into v6 over
> v4 and v4 over v6 tunnels (to do the same thing with Netflow would
> likely require a hardware upgrade). You can even feed sFlow into
> Wireshark for detailed analysis of protocols and packet headers.

NetFlow supports IPv6. As well as L2 traffic (v9), MPLS, multicast and
so on.

> 2. Operational complexity is greatly reduced since the configuration
> options and resource management issues associated with the flow cache
> are eliminated.

That will depend on the device and the options. It takes around
3-4 commands to configure the export and then one to activate
it without any templates on a interface on Cisco device.

What's more important, you can have multiple monitors on one
interface monitoring & exporting different sets of traffic to
different groups within company (Security, Network Monitoring,
Trafic Engineering). sFlow gives just sampled packets.

> 3. Low latency. Measurements aren't delayed by the flow cache - you
> can detect DDoS attacks/large flows within seconds.

The same with NetFlow. Cache can be actively flushed.

> 4. Scalability - you can turn on sFlow on every link (even 100G
> links), on every device for a comprehensive view of traffic.

Same with NetFlow & sampling turned on.

> However, there are a wide range of Netflow
> sampling implementations, many of which yield questionable results. In
> contrast, the sFlow standard specifies how sampling must be performed
> and ensures that information is included that allows the sampled data
> to be correctly scaled and produce unbiased measurements.

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:

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.

NetFlow, jFlow, IPFIX deal with flows. You can discuss sampling
accuracy and things like that, but working with flows is more accurate.

--
"There's no sense in being precise when |               Łukasz Bromirski
 you don't know what you're talking     |      jid:lbromirski () jabber org
 about."               John von Neumann |    http://lukasz.bromirski.net