Hi David, The main architectural difference between sFlow and Netflow is the location of the flow cache: 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. 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. In addition to exporting the packet header, the sFlow agent captures the FIB state associated with forwarding the sampled packet, exporting information such as next hop router, AS-path, communities etc. An sFlow agent also periodically sends all the MIB-II interface counters, eliminating the need for SNMP polling - this isn't very important if you are only monitoring a few links, but makes a big difference if you are monitoring large chassis switches or tens or hundreds of thousands of ports in a data center or campus environment. 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. 2. Operational complexity is greatly reduced since the configuration options and resource management issues associated with the flow cache are eliminated. 3. Low latency. Measurements aren't delayed by the flow cache - you can detect DDoS attacks/large flows within seconds. 4. Scalability - you can turn on sFlow on every link (even 100G links), on every device for a comprehensive view of traffic. 5. Multi-vendor interoperability. The sFlow measurements are interoperable across vendors (since very little processing is performed on the devices). With NetFlow, different vendors and devices have different hardware limitations affecting the fields that they can export. Unsampled Netflow is only practical for moderate traffic levels. If you carry significant traffic you would want to enable sampling anyway, even with Netflow. 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. Cheers, Peter On Fri, Jul 13, 2012 at 10:30 AM, David Hubbard <dhubbard@dino.hostasaurus.com> wrote:
Can anyone on or off list give me some real world thoughts on sflow vs netflow for border routers? (multi-homed, BGP, straight v4 & v6 only for web hosting, no mpls, vpns, vlans, etc.)
Finding it hard to decipher the vendor version of the answer to that question. We use netflow v9 currently but are considering hardware that would be sflow. We don't use it for billing purposes, mostly for spotting malicious remote hosts doing things like scans, spotting traffic such as weird ports in use in either direction that warrant further investigation, watching for ddos/dos destinations to act on mitigation, or investigating the nature of unusual levels of traffic on switch ports that set off alarms. I'm concerned things like port scans, etc. won't be picked up by the NMS if fed by sflow due to the sampling nature, or similar concern if 500 ssh connections by the same remote host are sampled as 1 connection, etc. Of course these concerns were put in my head by someone interested in me continuing to use equipment that happens to output netflow data, hence me wanting some real people answers. :-)
Thanks!