NetFlow, in the very simplest of senses, is a technology, often built into various network hardware traffic devices but also available in standalone appliance form, which allows the collection and analysis of the traffic on said network.
The origins of NetFlow is traced back all the way to roughly 1996, when Cisco initially implemented it as more of a switching technology – at the time it worked great for smaller or local networks, but it faltered hard when it came to larger, traffic-heavy environments. Down the line, however, NetFlow shifted into a purely informational and diagnostic protocol – with v5 being one of the most common, as it’s frequently found even on consumer routers and network hardware since about 2009!
NetFlow utilizes, intuitively enough, Flow packets. Flow packets, like most any transmitted packet over network, contains a header with basic data and then its contents, which are often collected via packet capturing appliances for that very purpose, and then analyzed. A Flow packet, regardless of version, begin with a handful of basic fields in the header: Version number, sequence so as to determine if packets are lost, timestamp, and either number of records, or as of v9, list of templates and records.
The contents of the packet itself can be quite varied and offer a massive berth of information for diagnostics and analytics – input/output interfaces, timestamps, bytes of observed traffic, source/destination protocol, TCP flags, layer 3 headers and routing information, and so on so forth. In short, with the right implementation, you can examine just about any nuanced aspect of the network traffic you’re collecting.
Obviously such a swathe of information can be incredibly useful for making determinations about the health and nature of a network as well as providing almost any data points via analysis over periods of time. When you need to find out something about the traffic in your network, there’s almost no situation in which NetFlow collection and analysis wouldn’t be able to contribute.
In a standard NetFlow setup these days, which is usually in a moderate to large environment, you’ll have an added appliance or two to help perform the task at hand. There’s even some folks that add extra layers – for example, if some Flow packets are lost due to network congestion or connection issues, it’s gone forever!
There’s no resend information via UDP for Flow packets, so some admins take extra measures to assure some extra redundancy for these packets when having as complete a collection as possible is important. Usually a device will be attached to the network which will aggregate and handle NetFlow specific data and push that data into a collector.
The collector will often be attached to storage, for said data of course, as well as to a console system which would generally be where an admin will actually interface with NetFlow data! As with most aspects of IT there are other implementations – such as using a NetFlow probe instead, which are more passive devices in comparison to the collection appliances. Using probes can require a lot of added hardware, however, and simply using a singular probe at the front of a setup can be data-heavy, so all in all it requires examination of your needs and network.
Collection from a probe is excellent for taking a close look at a few critical links, but a more broad router-based NetFlow is better for an overall view of network traffic for accounting, performance, monitoring, security, and general capacity planning needs. NetFlow configurations tend to not be particularly one-size-fits-all.
There are many different ways to implement and access NetFlow – many routers support various versions of it, though Ipv6 is limited to the newest implementations. Some setups, if small enough and not needing a great deal of fidelity, may be fine just using a router’s built in simple NetFlow ability to assess traffic, whereas larger networks with excessive traffic will have little choice but to seek out some added hardware for a proper solution.
NetFlow v9 is one of the most recent versions and is fairly widely used. A comparable protocol, IPFIX, is heavily based on NetFlow v9 and also widely used in present implementations. A couple things in particular let v9 stand out above and beyond the previous – first and foremost it fully supports IPv6, something that will be increasingly necessary such that early adoption and preparation is quite wise!
Many recent routers also come with v9 support, and of course a wide range of separate appliances exist with v9 and v10 availability. The other major nuance of NetFlow v9 is the shift into a template based methodology for gathering and monitoring information. In short, it makes it a lot easier to very quickly and in a very organized manner gather and assess a collection of data using an array of templates via the NetFlow protocol.
It’s worth noting that many vendors have a similar technology with a subtly different name, such as Jflow, NetStream, Rflow, the eponymous sFlow, etc. Functionally these all tend to serve exactly the same purpose, and Cisco has been pretty loose with any kind of trademark or copyright efforts on NetFlow, leaving it widely up for general use
NetFlow has come a long way since it’s humble beginnings with Cisco, where it was casually mentioned on the side in an informational document not widely available. But since then it has grown and shifted into a powerhouse of analysis and diagnostics whose usefulness cannot be denied.