You raise an interesting point. IP CEF makes the operation of a software router much more efficient in forwarding packets than its predecessors like process switching, fast switching, etc. But it is still processing in the router CPU (operating in an interrupt rather than as a scheduled process). So if you look at the speed and efficiency of forwarding packets a layer 3 switch where the logic can be put into an ASIC will still be faster than a software router. There was a very interesting talk at the recent Cisco Live conference which gets into this a bit. If you have access to it you might want to look into BRKARC-2350 from the 2014 Cisco Live.
A full understanding of this is quite complex and requires understanding of how computer operating systems operate. Here is a simplified explanation which I hope will help you. The CPU of the router is a computer. There are multiple processes that need to run in that computer to accomplish the things that the router does (a process for IP Input which forwards packets, a process to handle a routing protocol, a process to manage the routing table, a process for your telnet/SSH session, and many others). The CPU can process only a single process at a time so to manage multiple processes that need to run the CPU has a scheduler that controls when a process can run, and selects the next process to run. So sometimes a process needs to run but must wait until it is selected by the scheduler which may cause some delay in achieving its results. There is a mechanism to identify things that need to happen immediately and that mechanism is the interrupt. When the CPU receives an interrupt it suspends the scheduled process that is running and processes the interrupt. When the interrupt is completed then the CPU returns control to the scheduled process. The implementation of CEF generates an interrupt rather than running as a scheduled process so CEF is able to complete its task without waiting for the scheduler which makes it faster.
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
As Rick noted, fully understanding interrupt processing is a bit complex. When dealing with interrupts, you also need to understand how interrupt hardware works.
Rick describes "The implementation of CEF generates an interrupt rather than running as a scheduled process so CEF is able to complete its task without waiting for the scheduler which makes it faster." This might not be exactly accurate. I don't believe CEF generates the interrupt.
What I believe happens, reception of an ingress packet triggers an interrupt. On most computers, the interrupt handler will just save the received packet somewhere, adjust hardware registers, if necessary, and often post an indication within the system that there's a newly saved packet (which will be processed by a scheduled process).
Generally, when dealing with interrupts, you have very little time for processing. This is due to same and lower priority level interrupts are often blocked, and may be "lost" if you take too much time to process the current interrupt.
On Cisco routers, instead of the interrupt handler just saving the received packet for later processing, the router will try to forward it too (i.e. by the interrupt handler). Again, remember, an interrupt usually has to be serviced very quickly.
Standard routing, i.e. doing a longest network prefix lookup, often cannot be done within the time budget of an interrupt. So, Cisco has over the years implemented different ways to avoid this, so the forwarding decision could be made very quickly (and remain within the interrupt handler). CEF is their latest "quick" way to make a forwarding lookup.
CEF's major advantage, over previous quick lookup schemes, is the first lookup for a destination isn't slow. (Many of the prior schemes were slow on the first lookup, but "cached" the result for much faster subsequent look ups for the same destination.)
Forwarding packets within the interrupt handler does save some instruction cycles allowing faster packet forwarding.
Cisco routers are a bit of a hybrid in the process scheduling design. They are using interrupts as a light weight scheduler, beneficial for "real-time" processing, yet they still retain a classical scheduler for other tasks the IOS needs.
BTW, in regard to the original question, L3 switches, using dedicated hardware for processing, are generally much, much faster than even the best software router. This is similar to a PC doing complex graphics with or without a (hardware based) graphics chip/card.
Joseph is correct that "This might not be exactly accurate." I was trying to make things simple in my explanation and felt that going into the details of how the interrupt is generated would lead to more complexity in the answer. I thought it is more important to understand that CEF operates under the interrupt and not as a scheduled process. But Joseph's explanation that the interrupt is related to the arrival of a packet is more correct that saying that the interrupt was generated by CEF.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...