Manage your Network!

Complete Guide to Netflow: How Netflow & its Components Work. Netflow Monitoring Tools

This article will cover the basics of Netflow, including its use cases, Netflow supported devices, Netflow history, and variants. We’ll also dive into the technical details of how the Netflow protocol works, including the Netflow ports, and the various Netflow versions. This will lead onto coverage of the various Netflow components, including the Netflow Exporter, Netflow Collector, and Netflow Analyzer, with some brief coverage of its main competition.

Key Topics:

Introduction to Netflow: What is Netflow used for?
Netflow History, RFC, Netflow Vendor Variants
Netflow Protocol Transport and Ports. What can I see with Netflow?
Netflow Components: Netflow Exporter, Netflow Collector and Netflow Analyzer
Netflow vs SNMP – What are the Differences?
Netflow vs IPFix – What are the Differences?
Summary

Introduction to Netflow – What is Netflow Used for?

Visibility plays a key role in the maintenance and security of any network. With it, admins can identify issues, discover non-compliant users, refine their provisioning, and more. Netflow is a protocol developed by CISCO that fulfils this purpose, letting interested parties understand network patterns and protocol distribution, while supporting more granular data like IP service type for diagnosis.

Its relatively low overhead and trusted history means that Netflow is still around in some forms a decade after its release. As well as user and application monitoring, admins utilize Netflow for network planning, application reporting and profiling, security analysis, and usage-based reporting and billing.

Broadly, a flow is a group of packets part of the same conversation between two endpoints in a network. More technically, a single flow is defined by its 5-tuple, a collection of five data points that include:

Source and destination IPs addresses
Source and destination ports
The protocol

As you’d expect, the Cisco-developed protocol is supported by a number of CISCO networking devices. The company’s IOS-XR routers use a software implementation running on line card CPU, while the IOS line runs software on route processor. Meanwhile, Catalyst and Nexus switches have a dedicated hardware TCAM implementation, generally supporting more flows.

Netflow History, RFC, Netflow Vendor Variants

Of course, Cisco isn’t the sole vendor of devices with Netflow-like support. Netflow began its evolution in 1996 with IOS 11.x as a software technique, rather than a hardware one. Initially, it was designed for LAN and scaled poorly, resulting in the rise of the express forwarding technique. Cisco, seemingly recognising the value of its solution, later enabled hardware-based implementations, which allow for higher bandwidth.

However, with the rise of Netflow came a number of other popular vendors trying to cash in on it. In a bid to avoid trademark battles, various competitors implemented their own flavors of the technique. Juniper’s jflow is one such example, as well as Huawei’s NetStream, and HP’s SFlow.

With the various solutions complicating matters, the IETF released IPFIX as the official standard in 2008. Making matters more confusing, IPFIX is sometimes referred to as Netflow v10. In reality, the latest official version of Netflow is v9, with IPFIX simply bearing some similarities. Netflow version 9 is described in RFC 3954 on the informational track rather than standards. IPFIX is on the standards track with RFC 7012.

Netflow is generally supported in three versions. Cisco did not publicly release versions 2-4, and v1 is naturally obsolete. Routers and switches most commonly support Netflow v5, v8, and v9, with v6 out of support and v7 seemingly exclusive to Catalyst 5K series switches.

Netflow records are exported via UDP and received by the Netflow Collector, which we’ll dive into more later. Suffice it to say that the IP address of the collector and the UDP destination port must be configured on the sending router, with the most common port being UDP 2055. Some Netflow implementations protect against packet loss through use of SCTP, however, this is not always performant if multiple independent collectors are in play.

Netflow Protocol Transport and Ports. What Can I See with Netflow?

As mentioned earlier, a Netflow enabled device inspects a number of parameters to define differentiate flows. These provide some natural, basic visibility. The source and destination addresses can tell admins who is sending and receiving traffic, for example. The ports show which applications are utilizing the traffic, class of service indicates the priority, and the interface how traffic is being utilized by the device.

However, the collection of various data points can lead to information beyond this. Tailed packets and bytes reveal the amount of traffic, and can be combined with data like timestamps for bytes per second, TCP flags to examine handshakes, subnet mask for prefix calculation.

The amount of real-world benefit often depends on the analysis tools at your disposal. With the right Netflow Analyzer, admins can use collected data to determine the following:

General traffic patterns
Diagnosis of slow performance, including network bottlenecks
Unusual network behaviour
The network impact of certain applications
Unauthorized WAN traffic, unusual network behaviour such as DoS
QoS validation

Netflow Components: Netflow Exporter, Netflow Collector and Network Analyzer

To fully understand Netflow, it’s necessary to have an idea of its various components and how they function. It consists of three components: the Netflow Exporter, Netflow Collector, and Netflow Analyzer. Each of these has a different role, and is often based on different hardware.

These are fairly self-explanatory. The Netflow Exporter is an appliance or network device, an example device is a router or firewall. It gathers packets into flows and exports flow records to collectors when it decides the flow expires.

The Netflow Exporter determines which flows are new by the 5-tuple data points mentioned above. When packets enter the network, they’re checked against a table of recent flows called the flow cache. If the packet matches an existing 5-tuple, information such as packet count and byte length for the flow is updated. If not, a new entry is created.

The router expires flows, exports them, and removes them from the cache. It takes indications from TCP flags, such as FIN or RST, or when one of two requirements are met:

In an inactive timeout, flows expire when no packets have been detected in a set period. The default for this is usually fifteen seconds, but it can be adjusted to a network’s needs.
An active timeout happens for the opposite reason – the flow has been maintained for too long. If a flow doesn’t expire, the admin won’t get any data on it, so this is necessary to maintain visibility. The default is typically 30 minutes, but one minute is more popular in practice.

The Netflow Collector is a server or appliance that receives the aggregated flows, storing and pre-processing it for use by the Netflow Analyzer. The Netflow Analyzer is software-based and provides the necessary insights.

Click to visit

It often takes pains to present information in a digestible form, with graphs, tables, alerts, and reporting tools.

Netflow vs SNMP – What are the Differences?

If you’ve heard of Netflow, you likely know of SNMP. However, a popular misconception is that they’re similar. We’ll have a detailed explanation of this soon, but the bottom line is that the two protocols are very distinct. They take different approaches to monitoring, and are applicable in different scenarios.

Unlike Netflow, SNMP can return real-time data. This has obvious advantages, but it also comes with some downsides. Though it’s excellent at giving visibility of the network and bandwidth usage, it’s not as verbose. SNMP doesn’t maintain important information for network admins such as what a user or application is doing, the type of traffic, or source/destination addresses.

Essentially, SNMP can reveal that there’s an issue, but it’s not ideal for figuring out the cause. Though versions are fast and low-overhead, it’s often used for a quick overview, whereas Netflow can be utilized as well as, or separately, for more in-depth analysis.

Netflow vs IPFIX – What are the Differences?

When it comes to Netflow and IPFIX, the mix-up is even more prevalent. In this case, it’s entirely understandable. IPFIX is sometimes referred to as Netflow v10, was created by some of the same people, is derived directly from Netflow v9, and is backward compatible.

Even so, there are several reasons it should be considered a separate entity. IPFIX offers more flexibility when expanding outside of the Cisco ecosystem. It can, for example, add information usually reserved for the Syslog, or integrate SNMP info directly in the packet.

It’s worth noting that Netflow v9 comes close to this functionality with its Flexible Netflow support, but it does require further configuration. On top of this, IPFIX holds one big change in that it supports a vendor ID. Users can assign an ID to any piece of data for gathering, which is a large boon.

So why not use IPFIX from the start? Well, flexibility isn’t always better. It can mean more chance of incompatibility and confusion. IP If Netflow suits the needs, it’s sometimes not worth complicating matters. Again, we’ll be covering this in a dedicated IPFix and Netflow article with more technical detail. The main idea to keep in mind is that though IPFix is preferred in many scenarios, it’s not always the best suited to the job.

Summary

This article provided a basic understanding of the Netflow protocol and how it works, including the Netflow Exporter, Netflow Collector, and Netflow Analyzers. We’ve covered its history, protocol transports, and common ports, as well as its RFC status.

You should also recognise the benefit Netflow holds for network admins, letting them get a general overview of traffic patterns while also aiding in the diagnosis of bottlenecks, flagging DoS attacks, enhancing network planning, and more.

Finally, we’ve covered briefly some of the differences between the protocol and SNMP or IPFIX.