Netflow is a network traffic flow reporting mechanism, originally introduced by Cisco, and adopted across the networking industry. A “flow” is typically defined as a stream of packets either entering or exiting an interface where Netflow collection is configured. A flow starts when a connection is built, and ends when a connection is torn down, or when a pre-configured length of time has passed. An important thing to note is that flow data does not include the payloads of the packets, but instead just data and metrics about the flow – source, destination, size, duration, ports, etc.
Typically flows are only tracked on the input side of an interface – ingress traffic. Some router manufacturers support egress flow monitoring, though not all, and typically it has to be turned on explicitly. A common pitfall with flow monitoring is to monitor flows ingress on one interface, then egress on another, so the same traffic gets counted twice. To prevent double-counting of flows it is often recommended that only ingress or egress flow monitoring be used at once. Regardless of ingress or egress, Netflow flows are uni-directional. Some proprietary standards by organizations like Cisco account for flows in a bi-directional manner, but this is not in keeping with published Netflow standards and is specific to those proprietary platforms.
Some versions of Netflow are “sampled”, meaning that only one out of every n packets passing in / out of an interface is sampled. This provides a good cross-section of traffic, without imposing a large processing burden on a router that is handling a lot of flows. Netflow v5 and v9 are examples of “sampled” Netflow. In contrast Netflow v1 is non-sampled, meaning every flow is exported. Those flows are sent to a collector for storage, analysis, and display to network operators.
There are a number of supported versions and features across the Netflow ecosystem, though a few versions have become the most prominent over time and are detailed below.
Netflow v5 is now considered a legacy version, originally published by Cisco, but is still very widely supported across the industry. It is only capable of handling IPv4 flows, and is not template-based, meaning that the fields v5 can report on are limited and static. Due to the static nature of flow data, however, it is very simple to parse and store. Where Netflow v9 can report ~127 individual fields and metrics using templates, v5 has only 18 possible fields and metrics. The possible fields in Netflow v5 can be found here.
Netflow v9 is considered a modern version of Netflow, and is very widely supported, despite still being a Cisco standard. This version is template-based, meaning that the fields it can export are not static like in v5, and it supports IPv6. An exporter will first send a Template to the collector, showing what fields and metrics it will be reporting and how many bytes each of those is. The collector will cache the template and use it to decipher the flow data that arrives after the Template is received. Any flow data received before a template arrives is discarded, per the Netflow v9 standard, because there is no way to decipher it. The approximately 127 possible fields and metrics in Netflow v9 can be found here, in Section 8 of the IETF text document.
IPFIX (aka Netflow v10)
IPFIX is often referred to as “Netflow v10”, but is actually a separate IETF standard, as defined in RFC 5101. Some router manufacturers specify the Netflow version number 10 in their CLI, others refer to it as “ipfix” at the CLI. This is another template-based standard, which adds additional fields, metrics, and flexibility on top of what Netflow v9 offers. The number of possible fields is increased significantly with IPFIX, offering 458 possible fields and metrics to report on. This standard adds additional capabilities for reporting on MPLS labels, BGP performance, mobile routing, and many other advanced configurations.
Decoding Netflow TCP Flags
NetFlow V9 Prot=6 Src=188.8.131.52 Dst=184.108.40.206 SPort=10979 DPort=60902 PktsIn=7 PktsOut=- BytesIn=1065 BytesOut=- Last_Switched=1026624 First_Switched=1026182 NextHop=220.127.116.11 InIfc=22 OutIfc=13 ToS=0 TCPFlags=24 SrcMask=32 DstMask=22 Type=- Code=- Dir=- FwdStatus=-
For the most part the fields in Netflow and IPFIX are self-explanatory – there’s really no question what “Source Port” or “IPv4 Next Hop” fields are. Other fields aren’t so straightforward, like the “TCP Flags” field. Lots of people know the typical TCP flags from learning the three-way handshake in basic networking (SYN, SYN-ACK, ACK). There are other flags too, like URG, RST, and FIN, but they aren’t exported in a way that’s spelled out.
Netflow v5 and v9 export TCP Flags as a numeric value, like “27”. For all the different types of TCP flags out there, it all boils down to a single number that doesn’t tell you much at first glance. This is where we have to do some special counting – binary. By counting in binary we can identify one or more flags that are set just from looking at one number.
First, we’ll write out a line of binary numbers from right to left:
32 16 8 4 2 1
Then we’ll match those numbers up with the corresponding TCP flags:
URG ACK PSH RST SYN FIN 32 16 8 4 2 1
This is what gives us the framework for counting. Start from the left and count to the right, adding together the numbers that make up the combination of your reported TCP flags.
For example, I just saw a flow with the TCP Flags field set to 18. Let’s figure out what flags are set for that flow.
Starting from left to right, we’ll add up numbers until we reach 18. We know that the URG flag wasn’t set, because 32 is greater than 18, and that blows the math out of the water. ACK has a value of 16, which is less than 18, so it looks like the ACK flag was set. Here’s what we have so far:
URG ACK PSH RST SYN FIN 32 16 8 4 2 1 -- X
There’s still 2 left, so we need to find a flag or a combination of flags that equal 2. Continuing to the right, we can tell the PSH flag wasn’t set, because 8 is more than the 2 we’re still looking for, and again it blows the math right out of the water. The same goes for RST, because it’s more than we need. The SYN flag, however, fits the bill as shown below:
URG ACK PSH RST SYN FIN 32 16 8 4 2 1 -- X -- -- X --
Adding the 16 (ACK) and the 2 (SYN) together gives us 18, the reported TCP flags in the flow.
This binary counting method works for all combinations of TCP flags, and allows us to report up to six possible flags being set in just one number. Unfortunately it takes a little legwork on our part to decipher it, but we also don’t have to parse out a bunch of fields in the flow export just for TCP flags.
Here are some other quick examples, just to check your comprehension of the method:
TCP Flag: 24 - ACK, PSH TCP Flag: 16 - ACK TCP Flag: 2 - SYN TCP Flag: 0 - Nothing