OpenFlow vs NetFlow

OpenFlow and NetFlow are two completely different concepts. OpenFlow controls how packets are forwarded through network switches, and Netflow collects IP traffic information. It’s easy to think of the two as being related because both words contain the suffix “flow”.  This post should provide some clarity on the nature of each one of these two protocols.

What is OpenFlow?

OpenFlow is a protocol used in Software Defined Networks for communication between a network device and a controller server. This particular architecture separates packet forwarding and high level routing decisions whereby packet forwarding is performed by the switch hardware and high-level routing decisions are made by a controller server.  I’ll digress more on this in a moment.

What is NetFlow?

NetFlow technology on the other hand, is used to collect network traffic information such as source IP, destination IP, ports, protocols, bandwidth utilization, applications and more. A NetFlow capable router or switch collects IP flow data and sends it to a server where a flow collector is installed. The collector has the ability to decipher NetFlow packets and interpret their content in a user friendly manner for further traffic analysis.

Are NetFlow and OpenFlow Complementary?

You might wonder if NetFlow and OpenFlow are complementary and the answer is “they could be”.  To understand why, we need to digress a bit more on the SDN and OpenFlow architectures.  In a SDN network, when a host ARPs for a destination, the switch configured to participate in OpenFlow, will make a decision on whether to:

1. forward the packet based on local policies or to
2. forward the ARP request up to the controller and wait for instructions on how to treat the connection request.

If the controller denies the connection the switch could do nothing.  On the other hand, if the controller allows the connection, the controller will then push down instructions to all switches and routers in the path on how to forward the traffic and possibly with a predefined priority. Whichever forwarding logic is leveraged (i.e. locally or via the controller), the switch could export IPFIX, NetFlow or sFlow details about the flows.  If the later is the case and the controller decides on whether to allow the connection or not, it could also maintain a connection table.  It is theoretically possible for the controller to also export flows with network traffic visibility details.

In short, some think of OpenFlow as the protocol used between the switches and the controller in a multi-vendor SDN environment. A good person to follow on all things SDN is Mark Leary at thefirsttracks.com.  Also worth noting is that switches participating in an SDN probably support NetFlow, IPFIX or sFlow however, they don’t have to.

Let’s hear some comments from anyone with OpenFlow network monitoring experience!