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