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:
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.
