With NetFlow administration and configuration, there are always choices. This blog post will briefly introduce different protocols and their options, as well as real-world examples. Let's dive into two protocols being used today: NetFlow and sFlow.
NetFlow
We won’t discuss history but will instead jump right into the NetFlow protocol's current use and its differences. Currently, there are only three versions of Netflow: 5, 9, and 10/IPFIX.
Netflow v5 is the oldest and simplest to configure. Just set up interfaces and an NFA address, and you’re good to go.
NetFlow v5 example
The image above shows a Wireshark example of the v5 Netflow. It contains everything you should expect from a Netflow document, in this case, a Cisco router. You can only have the fields you see, nothing more, nothing less.
But as time passed, a new version, v9, was out. In this version, you get templates, meaning you can choose which fields you want to export and present to NetFlow Analyzer. In Cisco's example, you configure (on the exporter) Flow records, Flow exporters, and Flow monitors. Then, apply them to interfaces from which you want NetFlow. In Cisco's example, all of this is called “Flexible NetFlow,” as in modular configuration.
NetFlow v9 example
Here, you can see a Palo Alto Firewall v9 Netflow and its template. There are at least 2-3 new fields, like 15-Direction, 17-firewallEvent, etc. We can even correlate these NetFlow information with AD logins and get the data for each VPN user. To learn more about that, visit our docs.
Netflow v9 allows companies to export pretty much everything they can and what they think can be useful to you. In Cisco ASA or newer firewall cases, there is something called NSEL, and it is something like a Netflow on steroids.
NSEL example
The NSEL example shows interesting fields, such as NAT Source and Destinantion addresses, extended firewall codes, and, in other cases, Firewall event messages.
Finally, there is Netflow v10/IPFIX. To be honest, this is the same as the V9, but it is just an industrialized version. Vendors wanted to add their special “sauce” to Netflow. A vivid example is VMware's NSX-T output in the picture below.
VMware's NSX-T example
VMware SDN provides some interesting fields, like Layer2 Segment ID and some private entries. NSX-T also gives a sampling option so that you can forward 1-100% of packets. The user decides on the ratio.
We’ve gone through pretty much all industry-standard Netflow implementations. Almost all vendors support some Netflow, and for those who don’t(or if you want a NetFlow export on a device that is not a router/firewall or switch), there is always something like a NetFlow probe, which translates traffic into Netflow packets.
sFLow
The goal of the sFlow protocol was not to shoehorn every kind of metric or message into a Netflow packet. Instead, it was created to be one thing only: a monitoring tech. There were some trade-offs, of course: the sFlow is sampled only traffic. This means that of all the traffic coming through the device, you could configure a one-in-something number of packets that would arrive at the Netflow collector.
Compact and Full sFlow examples
When looking at Compact and Full sFlow examples, the first thing that gets noticed is the sampling rate. Usually, you can configure it to something like 2-16384 packets.
Another interesting example is Brocade switch sFlow:
Brocade switch sFlow example
Here, we can see a myriad of data, from the interface's speed to its type and, of course, its familiar Admin and Operational status.
NetFlow VS sFlow
After looking at the real-world examples of both protocols, what are they being used for? By default, you will probably use NetFlow except in two cases:
a) Your device doesn’t support NetFlow
b) The amount of data flowing through the device is enormous and burdensome.
So, what are sFlow primary use cases? We will name a few similar to their docs:
a) Trending and capacity planning – You will get an overview of your network and devices to plan accordingly
b) Network visibility – When pushing hundreds of Tbps, sFlow gives you a bird's-eye perspective on your network.
c) DDOS detection and prevention
d) Multitenancy – you can quickly get all your tenants on one platform, with a lot of space efficiency achieved with sampling
e) Deep history monitoring – because of the efficiency of the sFlow itself, you could store years of data for that exporter and much more.
The key requirements that sFlow fills out are:
a) Efficiency – sFlow agents are very small and don’t do aggregations or keep data for a very long time
b) Light on CPU – sFlow implementation is a low-cost solution and can be implemented on pretty much any CPU and RAM combination
c) Lightweight packet – sFlow has only a few fields
d) Simple encoding – The sampling rate is forged directly into the packet, so you don’t need any external configuration or manual to read or compute the traffic.
e) Industry standard – Regarding that, it is easy to implement the sFlow agent.
In the end, everything boils down to three requirements:
1. You need all the traffic
2. You need advanced fields from your vendor
3. You need to drill down and aggregate your data.
Generally speaking, NetFlow is better at fulfilling these requirements. However, if you need efficiency in any parameter, sFlow wins the title. For big implementations in interfaces (40-100+ Gbps), sFlow can give you great insight into your network. For smaller implementations, NetFlow is the way to go, with raw data, aggregations, and Traffic Patterns to shape your traffic into meaningful views. Also, let's not forget integration with AD and deduplication of traffic.
