A network flow 'NetFlow' can be defined in many ways. Traditionally it is a cache entry on a device (i.e. router, switch, firewall, etc.) with accumulating counters based on a matching tuple within packets entering the device. Although the tuple is meant to be flexible, it is most commonly the following 7 fields:
- Ingress interface (SNMP ifIndex)
- Source IP address
- Destination IP address
- IP protocol
- Source port for UDP or TCP, 0 for other protocols
- Destination port for UDP or TCP, type and code for ICMP, or 0 for other protocols
- IP Type of Service
The accumulating counters portion is the total number of bytes for all the packets matching the above tuple as well as the total number of packets. The tuple generally determines which packets are part of the same flow entry, however, it does not dictate all the fields that are exported about flow. In other words, additional fields are also exported about each flow that are not defined by the tuple. Examples include:
- Egress interface
- Autonomous Systems
- TCP Flags
- Source and destination subnet
- Next Hop
Cisco has since made the tuple and the additional fields exported on a flow configurable using something called Flexible NetFlow. This configuration interface allows admins to specify a series of match and collect statements which define what is being collected and exported by a device. Flexible NetFlow can be used to export NetFlow v9 or IPFIX datagrams. IPFIX is the proposed standard for NetFlow. See what is IPFIX. Keep in mind that Flexible NetFlow is a bit more complicated than a simple ip route cache flow configuration.
What is NetFlow
So what is NetFlow then? It is a single cache entry representing one to thousands of packets with a matching tuple. Typically a device will export two flows for a TCP, UDP, ICMP, etc. connection between Host A and Host B. We end up with two flows: one from A to B and a second from B back to A. Some devices export bidirectional flows whereby a single flow entry represents traffic in both directions however, this implementation is primarily witnessed from firewalls.
Flow entries are usually metered as they ingress or in other words as they enter an interface. Since all flows are generally seen entering a device, both inbound and outbound utilization can be determined using the same ingress flows.
Ingress Vs. Egress
A distributed NetFlow collection solution demands an architecture that can scale into the millions of flows per second. Many Cisco ASA NetFlow environments require massive collection capabilities. Each NetFlow Appliance can independently collect, process and store over 100,000 flows per second and run Flow Analytics to detect cyber attacks.
There are situations where egress vs ingress metering is performed. Here are some examples:
- In WAN compression environments (e.g. Cisco WAAS, Riverbed, etc.), we need to see traffic after it was compressed. Using Ingress flows causes an over stated outbound utilization on the WAN interface. Egress flows are calculated after compression.
- In multicast environments, ingress multicast flows have a destination interface of 0 because the router doesn't know what interface they will go out until after it processes the datagrams. Exporting egress flows delivers the destination interface and as a result multiple flows are exported if the flow is headed for multiple interfaces.
- When exporting NetFlow on only one interface of the router or switch. Enabling both on a single interface means that all traffic in and out is exported in NetFlow datagrams.
- Keep in mind that a single NetFlow datagram exported by a device could contain between one to dozens of flow entries. Exporting both ingress and egress flows can double the volume of flows being exported and if the NetFlow analysis solution doesn't recognize the direction bit that is set to '1' for egress flows, it will likely overstate utilization on interfaces.
On busy networks, a single device may end up exporting tens of thousands of flows every second. Only the most scalable NetFlow collectors can handle this kind of volume.
Active Timeout and Inactive Timeout
During the process of caching and exporting the flows, devices exporting the data must maintain timers on how often they export details about each flow cache entry lasting longer than 60 seconds. Since most NetFlow reporting solutions want to trend the data in 1 minute intervals, routers maintain an active timeout on each flow entry. Every 60 seconds a cache entry is exported with the delta value of the total byte and packet count since the last export on the flow status. Basically, this practice forces the flow exporting device to send the delta value rather than the NetFlow collector having to calculate it by comparing the value to the last exported value.
Flow entries that don't see any updates (I.e. packets) within the inactive timeout (E.g. 15 seconds) are exported and removed from the flow cache.
The downside of What is NetFlow
When answering the question of "what is NetFlow" the short comings of the protocol should also be outlined. First of all, flows are generally not as detailed as the actual packets. They are summaries representing common attributes about the packets that traveled through the device exporting them. This means the NetFlow collector will not have all the details that a packet analyzer would however, it is possible to export entire packets with NetFlow!
Do not be confused by discussions revolving around NetFlow Vs sFlow. NetFlow is a true flow technology whereas sFlow is not a flow technology at all. SFlow is limited to packet sampling. NetFlow supports all the sFlow capabilities as well as true flow technologies.
If you have further questions on NetFlow and its capabilities, reach out to the leader in NetFlow.