NetFlow Vs. sFlow: Which is better?

系统管理员 2023-06-12 08:47 16阅读 0赞

最近主要工作精力在BGP方面，BGP环境搭建好后又上了DDos高防，所以需要配置sFlow，NetFlow；

以下是网上关于NetFlow，sFlow的讲解，转载以作学习记录；如有侵权，联系删除。

原文链接：[https://www.plixer.com/blog/netflow-vs-sflow-which-is-better/][https_www.plixer.com_blog_netflow-vs-sflow-which-is-better]

**[netflow][] [supported-devices][netflow]**

[https://www.manageengine.com/products/netflow/supported-devices.html][netflow]

The few debates that have emerged over [NetFlow Vs. sFlow][] often highlight why one technology is better than the other.  In this post, I would like to emphasize where the technologies are similar as well as where they should be implemented (i.e. one over the other). Certainly both have some merits but, one technology is definitely outpacing the other.

## What is a Flow? ##

As defined by the IETF.  [A flow is a sequence of packets from a sending application to a receiving application][].

The sFlow technology uses sampling in an attempt to achieve scalability. The architecture of a sFlow system consists of multiple devices performing two types of sampling: random sampling of packets or application layer operations, and time-based sampling of counters. The sampled packet/operation and counter information, referred to as flow samples and counter samples respectively, are sent as sFlow datagrams to a central server running software that analyzes and reports on network traffic; the sFlow collector. Source: [Wikipedia][] : Multiple sFlow samples can be sent in a single datagram.

*“Based on a defined sampling rate, an average of 1 out of N packets/operations is randomly sampled. This type of sampling does not provide a 100% accurate result, but it does provide a result with quantifiable accuracy.”*

Peter Phaal – Inmon

## What is NetFlow? ##

NetFlow is a true flow technology whereby cached flow entries in the hardware (e.g. router/switch) aggregate packets based on a matching tuple which is most often a set of seven key fields:

1.  Source Interface
2.  Type of Service
3.  Source IP address
4.  Destination IP address
5.  Source Layer 4 port
6.  Destination Layer 4 port
7.  IP Protocol

When flows are exported, the total or aggregated delta byte and packet counts are included as well as several other fields including BGP autonomous systems, subnet masks and other fields that will be explained later.  Packets that don’t match a flow cache entry’s key fields become new flow entries.  Multiple flow entries could be sent in a single NetFlow datagram and both hardware and software implementations of this technology exist from several vendors.  NetFlow provides 100% accuracy of IP traffic however, packet sampling and flow sampling are both supported by NetFlow.

## What is Flexible NetFlow? ##

Flexible NetFlow (FnF) really isn’t a new export format. Rather, it builds on the architecture of the NetFlow v9 export format and does more with it. FnF has one of the best albeit more complicated implementations of flow exports seen to date.  What FnF can export is vastly definable. In other words FnF allows customers to export nearly anything passing through the router including entire packets and it does this in real time just like sFlow.

## What is IPFIX? ##

IPFIX is the proposed standard for the structured streaming of information and is based on the latest version of NetFlow (v9).  Because of this, it is sometimes incorrectly referred to as NetFlow v10.

## Which is a standard: NetFlow or sFlow? ##

The answer is neither. If you go to the IETF web site, you will find RFC 3176 which discusses the sFlow protocol and RFC 3954 which discusses NetFlow v9. These technologies are not standards. RFC stands for Request For Comment (i.e. not a standard). Often many of us (including me) reference these technologies as standards however, there is no ‘flow’ standard.  IPFIX which is defined in RFC 5101 is the proposed standard.  Be leery of documents such as the one from Brocade:  [sFlow\_vs\_NetFlow\_WP\_00][sFlow_vs_NetFlow_WP_00]  which makes claims such as “IPFIX suffers from poor vendor adoption and still has most of the deficiencies of NetFlow.” This simply isn’t true.  [IPFIX adoption][] is growing and I can think of over a dozen vendors supporting IPFIX.

## Which scales better sFlow or NetFlow? ##

Packet sampling can be performed by sFlow or NetFlow which doesn’t scale in a way that is acceptable to most customers.  For example, a massive burst in traffic (E.g. DoS attack) would cause sFlow to sample more as it needs to keep up with 1:N sampling.  With NetFlow, a massive packet volume depending on the attack would likely show up as just a few flows with high packet volumes.  The amount of additional work for NetFlow is minimal especially if we are comparing apple to apples with both technologies implemented in hardware.  There is a dated but, still accurate article on [NetworkWorld][] about sFlow and NetFlow where the accuracy of the two technologies is tested.  In real time trouble shoots, NetFlow provides details on 100% of the traffic whereas sFlow often misses the traffic you need to look at making sFlow almost unusable for network threat detection and forensic analysis.

If sFlow can’t sample enough to provide useful metrics or if NetFlow simply overwhelms your flow collector I would consider switching to Flexible NetFlow where the match statements can be modified to send a few less details yet still be 100% accurate.  Consider the following tuple reduction where the tuple is reduced from 7 fields down to 5:

1.  Source Interface
2.  Type of Service
3.  Source IP address
4.  Destination IP address
5.  IP Protocol

When source and destination Layer 4 ports are dropped from the tuple, I’ve seen the flow volume exported by the hardware drop by over 75%!  If you really want the application details, leverage Flexible NetFlow and export NBAR which still dramatically reduces the flow volume.  Some service provider implementations export only the subnets or just the source IP address which reduces the flow volume even more.

## If I have to sample, which should I choose: flow sampling or packet sampling? ##

If you must sample, flow sampling over packet sampling is the best option.  Choosing one packet out of 1000 or reducing the sample rate to one out of every 100,000 exacerbates the misrepresentation problem.  With flow sampling, flows with 10 packets are sampled equally among the flows with 100,000 packets. As a result, if we are trying to gain representation of what applications are on the network, flow sampling improves the accuracy probability as it treats all flows equal.  Packet sampling will likely only show the top apps with the most packets and likely completely miss the applications with only a few packets.  And remember, sFlow and NetFlow both support real time packet sampling depending on the platform.

**NOTE**: If however overall utilization is the goal, export the in/out octet delta counts of the interface, both sFlow and NetFlow support this.

## If NetFlow is better than sFlow, why would anyone ever use sFlow? ##

The answer to this question comes down to choice.  Many switches today only support sFlow.  InMon made it very inexpensive to implement packet sampling with sFlow as a result, most vendors support it including Cisco.  Today, many customers think they have only one choice on switches: sFlow.  There are however a few vendors including Cisco that are supporting NetFlow and or IPFIX on a switch (e.g. Cisco 3750X with 3KX module or the 3850).

## Summary ##

Because of the larger community support for IPFIX (E.g. Astaro, Barracuda, Cisco, Citrix, Dell, Enterasys, Plixer, etc.), the innovations in exports are impressive:

*  Log messages (Cisco ASA denied connections)
 *  Detected virus messages (Dell-SonicWALL)
 *  VoIP (Cisco Performance Monitoring & SonicWALL)
    
     *  Jitter and Packet loss
     *  Caller ID
     *  Codec
     *  SSRC
 *  Latency or Round Trip Time (Cisco, Citrix, Plixer)
 *  URLs (Citrix, Dell-SonicWALL, Barracuda, Plixer)
 *  Rerouted connections (Cisco PfR)
 *  Wireless LAN IDs (Cisco)
 *  End user login names (Cisco, Dell-SonicWALL, Palo Alto)

On the other hand, sFlow lacks significant involvement from a large user community (only InMon) and the innovations coming from this company fall short in comparison to true flow technologies like NetFlow and IPFIX.  Finally, if you ask any customer that has a network with equipment supporting both sFlow and NetFlow, they will tell you this about sFlow when NetFlow isn’t available: “I’d rather collect NetFlow but, sFlow is better than nothing”.

[https_www.plixer.com_blog_netflow-vs-sflow-which-is-better]: https://www.plixer.com/blog/netflow-vs-sflow-which-is-better/
[netflow]: https://www.manageengine.com/products/netflow/supported-devices.html
[NetFlow Vs. sFlow]: http://seclists.org/nanog/2012/Jul/537
[A flow is a sequence of packets from a sending application to a receiving application]: https://www.ietf.org/proceedings/39/slides/int/ip1394-background/tsld004.htm
[Wikipedia]: https://en.wikipedia.org/wiki/SFlow
[sFlow_vs_NetFlow_WP_00]: https://www.plixer.com/wp-content/uploads/2013/02/sFlow_vs_NetFlow_WP_00.pdf
[IPFIX adoption]: https://www.plixer.com/Scrutinizer-Netflow-Sflow/activating-netflow-sflow.html
[NetworkWorld]: http://www.networkworld.com/community/node/29117