I understand that L3 switches use CEF for faster packet forwarding. However, CEF will not work for packets that need to undergo NAT. Does this mean CEF isn't used by edge routers and edge L3 switches? Is CEF's usefulness limited to the LAN?

3 Answers 3


NAT can of course use CEF. This is from Cisco's own guide over here: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_q_and_a_item09186a00800e523b.shtml

Q. What kind of routing performance can be expected when using Cisco IOS NAT?

    A. Cisco IOS NAT supports Cisco Express Forwarding switching, fast switching, and process switching. For 12.4T release and later, fast-switching path is no longer supported. For Cat6k platform, the switching order is Netflow (HW switching path), CEF, process path.

    Performance depends on several factors:

        The type of application and its type of traffic

        Whether IP addresses are embedded

        Exchange and inspection of multiple messages

        Source port required

        The number of translations

        Other applications running at the time

        The type of hardware and processor

Bigger platforms running IOS-XR, where the FIB gets ditributed to the line cards, also support carrier grade NAT, so it's usefulness is not limited to the LAN alone.

Also a lot of Cisco's L3 switches simply do not do NAT at all

  • 2
    Technically on CEF path from ingress to egress you have insertion points for features (like NAT). If this insertion point exists, feature works with CEF enabled. But unlike L3 lookup, there might be no observable performance gains for this feature, as CEF is simply giving data for the feature, not changing the feature itself. But mostly this is unimportant detail, important detail is, keep CEF enabled.
    – ytti
    Jun 2, 2013 at 15:57

CEF is Cisco's word for their FIB. When in L3 switch you do 'sh ip cef', none of this information is actually used to push the packets at all, this is just software trie which is used to populate the hardware ASIC.

CEF is just term Cisco uses to describe their optimize data storage/retrieval code, it is not specific technology with specific function.

In most HW platforms you cannot simply run the box without CEF, as CEF data structure is needed to compile the HW specific information.
Some features like MPLS also have dependency on CEF data structure and thus won't work without it.

LAN (L2) switching is not abstracted via CEF, so it does not depend on CEF at all.

I recommend this book for quite up-to-date information about CEF (it's written after major CEF rewrite around 12.2S)

If you constrain CEF definition of IP Trie FIB, then obviously that cannot be used for NAPT, because you cannot pre-determine what is natted and where. But as explained, CEF is not specific technology, it's broader concept, and thus it's debatable if CEF is NAT feature or not, I would err to the side of it being CEF feature:

bu.ip.fi#sh cef features global  | b Local
  Global Local features not attached to a specific interface:

I would never run anything without CEF and it is probably only because of legacy reasons choice of disabling it even exists. Consider Juniper, they don't have specific term they use to describe same concept, as they do not need to differentiate it from some alternative method, as such inferior alternative does not exist.

  • 5
    Just to add to this - CEF is switching path, an information tree for forwarding the information and so on, so the name 'CEF' may be used in many ways and it adds to confusion. Actually, NAT is supported in CEF path (as so are thousands of other functions), but CEF-built tables doesn't contain some of the information needed to switch packet purely by using them as ytti pointed out, additional entries need to be consulted (they're built and maintained by NAT code). Anyway, if packet can be switched in the CEF path without falling back to process switching, it's still feature supported by CEF. Jun 2, 2013 at 17:14

Does this mean CEF isn't used by edge routers and edge L3 switches? Is CEF's usefulness limited to the LAN?

CEF is useful because it permits a router to quickly rewrite the Layer2 information during Layer3 forwarding operations. WAN routers must rewrite Layer2 header information just like LAN switches do... CEF is extremely useful to both types of router.

At a high-level CEF performs two functions:

  • Contains a shadow-copy of the routing table, which maps the routed prefix to a next-hop
  • Contains a reference to a Layer2 adjacency table, which provides cached information about Layer2 headers required to rewrite the IP packet through the egress next-hop mentioned in the first bullet.


Consider this router that has a WAN HDLC link on Serial1/0, and a LAN connection via FastEthernet0/0...

R1#show adjacency internal
Protocol Interface                 Address
IP       Serial1/0                 point2point(5)
                                   0 packets, 0 bytes
                                   0F000800             <--------- HDLC Header rewrite info
                                   CEF   expires: 00:02:17
                                         refresh: 00:00:17
                                   Epoch: 0
                                   Fast adjacency disabled
                                   IP redirect enabled
                                   IP mtu 1500 (0x0)
                                   Fixup disabled
                                   Adjacency pointer 0x6663D3E0, refCount 5
                                   Connection Id 0x000000
                                   Bucket 6

Suppose an IPv4 packet going to enters the router from FastEthernet0/0 on the LAN, and must exit Serial1/0 on the WAN (the fact that it's exiting Serial1/0 is found in the CEF table... and the CEF table references the adjacency table).

When the router receives the IPv4 packet from FastEthernet0/0, the router has to strip off the ethernet header and prepend the HDLC header, which is 0F000800 since it's an IPv4 destination (0x0800 is there as an HDLC "type" value to say the next header is IPv4).

If CEF has not cached the (trivial) header rewrite information for Serial1/0, it must be look up the information manually at the process-switch level (which is very slow). These adjacency table values won't change as long as the encapsulation on Serial1/0 doesn't change; therefore, Cisco IOS caches the adjacency rewrite information in the adjacency table.

The rewrite information gets more involved when you look at frame-relay or ATM PVCs.

This document on CCO (Document ID: 17812) may explain things better than I could by rehashing a lot of CCO content

  • Won't layer 2 operations be consulted by the CAM only? Layer 3 operations will consult the FIB which is where CEF operates and if there needs to be deeper packet inspection at layer 3 (in the case of a packet needing to undergo NAT) won't that make CEF useless for WAN routers? Jun 2, 2013 at 14:13
  • 1
    CEF specifically is not used to /cache/ adjacency or l3 lookups, this is 'fast-switching' (which is no longer supported at all). CEF is pre-build, so all data you might ever need for adjacency or l3 lookup, is already in structure which is optimal to search with constrains set by given platform.
    – ytti
    Jun 2, 2013 at 14:29
  • @ytti, I'm sorry but CEF does cache adjacency information, I think you're getting confused about how the cache is populated (IMHO you assume the packet must be punted to be cached, but this is not true)... One of the substantial differences between CEF and the other switching methods (like fast-switching) is that CEF is pre-computed. However, CEF still must cache the information, otherwise it has to be looked up at the process-switch level... very slow, and the reason that we need CEF for both LAN and WAN interfaces. Jun 2, 2013 at 14:34
  • I think we just disagree on what 'caching' means, but yes key point is, it is pre-build and for many features (such as MPLS) it is only structure for data, there is no 'process switching' storage to fall back to.
    – ytti
    Jun 2, 2013 at 14:43
  • @ChristianDelapena, you're confusing the hardware implementations of a hardware lookup table (CAM memory) with the IOS software process that populates hardware lookup tables (i.e. CEF). CEF exists so you can map a layer3 prefix entry to the required protocol rewrite information at layer2... however, layer2 could be many different protocols, such as frame-relay, atm, packet-over-sonet, hdlc, ppp or ethernet... all of these protocols can carry IPv4, but they need specific fields filled in their headers before you can take that IP packet and encapsulate it for the next WAN router to process Jun 2, 2013 at 14:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.