Go Configure!

CEF – A Simple Guide

7 min read

What is CEF?

CEF (Cisco Express Forwarding) is a method to quickly decide where a packet should be sent. A CEF enabled router or multi-layer switch creates tables containing the necessary information in hardware ASICs. An ASIC is custom circuitry inside the router that is optimised to perform a specific function at ultra high-speed.

In most cases because the router CPU doesn’t have to be personally involved, CEF can process packets at line-speed. ie. no delay is introduced. CEF is the default on Cisco devices and although it’s Cisco proprietary; other vendors have implemented their own similar technology.

To understand where we’re going…

…it’s useful to know where we’ve been. Here’s a mini history lesson on the forwarding methods of networks past:

Process Switching

The first method in existence was “process switching”. Being the first, it is somewhat inevitably the slowest. With process switching every packet is assessed by the router CPU to decide where it should be forwarded. The CPU is not dedicated to this function like an ASIC is, so we get comparatively poor performance.

..and yet, we still use it.

CEF cannot forward all packets, so process switching is still used in today’s networks with a de-emphasised role. Here are a few common reasons CEF might “punt” a packet to the CPU for processing:

  • The packet matches an access list that uses the log keyword.
  • There is no FIB entry for the destination.
  • A response needs to be generated – such as for an ICMP unreachable.
  • The packet is destined for the router.
  • The packet requires fragmenting.

Fast Switching

Cisco improved upon process switching by releasing “fast switching” capability. Fast switching was the first step made towards making forwarding decisions in hardware instead of software, reducing the CPU utilisation burden found in process switching alone.

Upon receiving the first packet in a particular flow, fast switching still has to perform the same initial lookup as process switching does. However now the router has done the hard work it caches the information, so for each subsequent packet in the flow, the device will look at the cache instead.

Fast Switching is largely unused now as CEF has improved on its functionality, but if you want to take a closer look, it can be enabled on your Cisco router or multi-layer switch using the command ip route-cache.

How does CEF improve upon Fast Switching?

Unlike Fast Switching, CEF does not require the first packet in the flow to be sent to the CPU to decide its next hop, encapsulation and exit interface. CEF performs this magic by creating two tables in hardware. The “CEF Forwarding Table” and the “CEF Adjacency Table”.

Layer 2 information is maintained by the Adjacency Table.

Layer 3 information from the routing table is used to create the CEF Forwarding Table – sometimes called a FIB (Forwarding Information Base).

These tables contain all of the information required to successfully forward a packet to its correct destination. As the two tables created are in hardware, the router is able to forward the majority of packets without interrupting the CPU – meaning optimised performance.

The CEF Forwarding Table

Take a look at this simple topology:

CEF lab topology

From R1’s perspective, there are locally configured IPs ( and and remote IPs ( , , and

The CEF forwarding table on R1 looks like this:

CEF FIB Forwarding Table

In the first column there are IP address and subnet mask combinations (aka prefixes) that exist in our topology, and there are some additional prefixes that provide default functionality.

The second column contains the “Next Hop” value. The most familiar of these may be where the next hop is an IP address. To paraphrase the forwarding logic for the prefix:

If a packet originating from, or transiting via R1 is destined to the specific prefix then forward it to the device with the IP – which is out of the local FastEthernet0/0 interface.

Other “Next Hop” values may not be familiar but are pretty easy to understand too:

Drop – Packets will meet a grisly demise, ejected without mercy.

Receive – This is R1 saying “I’ve got this..the destination you want to go to belongs to me”.

Attached – If the packet destination doesn’t match a more specific prefix (a subnet mask closer to 32) in the forwarding table, then the rest of the subnet can be found out of the interface shown.

The Adjacency Table

The second piece of the CEF puzzle is the adjacency table. This table holds the local and next hop MAC addresses to allow for wirespeed re-writing of layer 2 header information.

This is the fun-size adjacency table on R1:

CEF adjacency table output

So… there’s not much here for this topology; but we do only have one next hop – – the R2 end of the shared link.

Why aren’t , etc in the adjacency table?

Good question.

R1 doesn’t need to know the MAC of to be able to send a packet there.

All it needs to know is the MAC of its next hop, which is This is why we only see an entry for in R1’s adjacency table.

So what exactly am I looking at here?

There are a couple of obvious pieces in here, the adjacent IP address, the packet and byte count, and the remaining time before ARP entry timeout. However, there are some less obvious pieces that may be useful:

The long alphanumeric in the middle starting CC020:

This string contains the destination and source MAC addresses, and finally an ethertype of 0800 which is tagged on the end. Don’t lose sleep about the ethertype – if you’re using IPv4 then it will always say 0800. If you’re the kind of person that this will really bug, there is more information available here: https://en.wikipedia.org/wiki/EtherType

The (11) after the IP:

This is called the refCount value and refers to the amount of times the FIB has an entry that points to this adjacency.

Ah yes, the good old “Epoch”:

Other than being a great word, the epoch is a value between 0-255 that allows CEF to distinguish old from new entries.

CEF the enabler

Far from being a one-trick pony, CEF is a prerequisite technology for lots of other features that are commonplace in the networking world. Here are some of those features and their purposes:

Netflow: Gathers information about which IP sources are talking to which destinations and their usage. This can then be mapped over time to help spot trends and help resolve issues.

NBAR: Enables us to see common applications that are being used between sources and destinations.

NSF (NonStop Forwarding): A way for a device that has two Route Processors to ensure that it is able to continue its business of sending and receiving packets, in the event that one RP fails.

AutoQOS: Applies cookie-cutter Quality of Service policies for businesses with fairly simple application prioritization requirements.

As you can see, aside from the faster switching capabilities that CEF brings it is also useful for all kinds of things from monitoring traffic, to making sure that your VOIP traffic is classified more favourably than PornHub.

Summary, Summary, Summary Time

You hopefully now understand the history of forwarding and the reasons why CEF has become so ubiquitous in networking after starting out as Cisco proprietary. We also discovered that CEF cannot be used for every type of packet, and what happens instead when that is the case.

We’ve looked into the component pieces of CEF – the forwarding and adjacency tables, picking apart some of the key fields and discussing the values. It is easy to create your own lab to test this out in GNS3 or with your own physical equipment. I will show how to set up a lab in GNS3 as part of another post coming soon. If you want to figure it out for yourself there is some great documentation at the GNS3 website.

Finally we took a brief look into the other “stuff” that uses CEF in the background that we might otherwise take for granted. I hope you enjoyed this post, share with a friend…one that’s into networking or they’ll think you’re odd. Thanks!