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?
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
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.
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
Fast adjacency disabled
IP redirect enabled
IP mtu 1500 (0x0)
Adjacency pointer 0x6663D3E0, refCount 5
Connection Id 0x000000
Suppose an IPv4 packet going to 192.0.2.1 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