Cisco Express Forwarding (CEF), NetFlow and OpenFlow

Mike Patterson speaks out
Learn more about Mike Patterson...
Archive

Aironet

Competitive Lab Tests

Subscribe to Bloggers speak out on BradReese.Com

Cisco Express Forwarding (CEF), NetFlow and OpenFlow

One might somehow compare SDN to CEF because in both cases an external process is making forwarding decisions.

Kennebunk, ME: Sun, 12/29/13 - 11:59pm View comments

Earlier this month the following comment was made to a Cisco Support Community web page:

"Can you please explain Netflow, CEF and Openflow mechanisms in brief. I found that netflow and CEF can be enabled on an interface simultaneously. How both technologies compliment each other and how openflow is different from these and works along with them?"

XR OS and Platforms: Community Tech-Talk Carrier Routing System (CRS) Multichassis

I'll do my best to explain the differences between these technologies. I'll tackle CEF (Cisco Express Forwarding) first and then move onto NetFlow and OpenFlow which are really very different from one another.

I like the very broad description of CEF that was posted on Wikipedia:

"Cisco Express Forwarding (CEF) is an advanced layer 3 switching technology used mainly in large core networks or the Internet to enhance the overall network performance. Although CEF is a Cisco proprietary protocol other vendors of multi-layer switches or high-capacity routers offer a similar functionality where layer-3 switching or routing is done in hardware (in an ASIC) instead of by software and the (central) CPU."

Although the above is a bit brief, it generalizes the benefits of CEF nicely. I once had CEF explained to me as a process where the router makes the routing decision based on the first packet. The first packet is routed and then an entry is made in the routing cache or FIB (Forwarding Information Base). Each of the following packets that match an entry in the FIB are forwarded 'switched' much more quickly using ASICs. When a connection finishes or times out, the entry is removed from the FIB.

Here are the CEF benefits that Cisco lists on its web site:

Improved performance—CEF is less CPU-intensive than fast switching route caching.

Scalability—CEF offers full switching capacity at each line card when dCEF mode is active.

Resilience—CEF offers an unprecedented level of switching consistency and stability in large dynamic networks

To enable CEF, enter the following commands:

Router# config t

Router(config)# ip cef

Router(config)#

CEF and NetFlow

How does CEF relate to NetFlow? It frees up the CPU so that it can provide more details (e.g. NBAR). Why is it enabled? CEF is sometimes enabled to prevent flows from being exported with a destination interface of Null or 0. In most cases, you want CEF turned on when NetFlow or IPFIX is being exported. IPFIX (IP Flow Information eXport) is the IETF standard for all flow technologies.

Consider this note on Cisco's website regarding NetFlow switching and CEF switching:

"Beginning with Cisco IOS Release 12.0, CEF is the preferred and default switching path. NetFlow switching has been integrated into CEF switching. For information on NetFlow switching, see the 'Cisco Express Forwarding Overview' chapter and the 'Configuring Cisco Express Forwarding' chapter later in this publication."

It seems that this distinction between NetFlow and CEF has been made moot for a long time. If the CEF ASIC is performing the same function for both methods in order to populate the FIB, they are sort of one in the same now as far as I can tell. Perhaps one of the readers can expand on this.

What is OpenFlow

OpenFlow has nothing to do with CEF or NetFlow. It is a proposed protocol for software defined networking (SDN).

OpenFlow is an open architecture that hopes to allow administrators to run experiments in the production networks we use every day. In a way, it sort of reminds me of what VLANs try to do only better. If OpenFlow or similar proprietary architectures are added to commercial Ethernet switches, routers and wireless access points, it will allow vendors to interoperate in the same SDN environment without exposing the internal workings of their proprietary network hardware.

"When an OpenFlow Switch receives a packet it has never seen before, for which it has no matching flow entries, it sends this packet to the controller. The controller then makes a decision on how to handle this packet. It can drop the packet, or it can add a flow entry directing the switch on how to forward similar packets in the future," - OpenFlow Forum.

It will be interesting to see how well a controller will respond when it is receiving hundreds of thousands or millions of connection requests per second. For this reason, some believe most of the initial packet forwarding decisions will still be performed in a distributed fashion (i.e. at the local switch/router) with only the exceptions being forwarded to the controller for further processing. An exception might be an application which specifically asks for certain preferences when making a connection.

One might somehow compare SDN to CEF because in both cases an external process is making forwarding decisions.

This "external process" could create an opportunity in the flow industry to correlate L7 metadata from the SDN controller with the flows exported by the switch. For instance, if flow volumes are excessive, perhaps hardware could use flow sampling or PSAMP (packet sampling) to offload traffic details to an external collector and even export the CEF equivalent of a FIB from the SDN controller alongside policy and application info as IPFIX option templates. We could then run reports to determine things like:

The top hosts impacted by selected policies.

The top applications impacted by selected policies.

The volume of traffic being impacted by certain policies.

My point is that if you look at these technologies by turning your head sideways a bit, you might feel that SDN serves the same function as CEF although CEF is limited to L3 decisions. Regardless, the forwarding logic is external and because of this, the SDN advocates feel that their strategy has massively more forwarding decision capacity at any layer because there is no direct hardware limitation in the form of a "local" ASIC.

My guess is that NetFlow and IPFIX will likely be exported as they are today in a SDN environments. The controller may end up exporting connection messages in IPFIX as well. The future of SDN is still being played out but, for purposes of this post, OpenFlow and NetFlow only share the letters f-l-o-w in their names. Beyond these four letters, they share very little if anything in function, but will likely end up complementing each other nicely.

Mike Patterson's other blog stories:

Dell solves complex business problems

Enterasys Secure Networks

Mike Patterson speaks out

Systrax High-Impact Network Monitoring

TMCnet Advanced NetFlow Traffic Analysis