From: James (james@towardex.com)
Date: Thu Aug 19 2004 - 18:04:15 GMT-3
On Thu, Aug 19, 2004 at 04:32:23PM -0400, Howard C. Berkowitz wrote:
> At 4:02 PM -0400 8/19/04, Tim Fletcher wrote:
> >At 09:28 AM 8/18/2004, Howard C. Berkowitz wrote:
> >>So, the bottom line is that CEF should be less, not more, likely to
> >>break things, because it is architecturally clean rather than a
> >>kludge.
> >
> >Agreed. Except the code hasn't been around as long, so is still
> >likely to have (more) bugs.
> >
> >-Tim Fletcher
>
> You can argue that two ways. True, there hasn't been the experience.
> But if the fundamental paradigm of CEF is much cleaner than of other
> switching modes, the actual code can be simpler. Cache management
> for fast/silicon switching is frighteningly complex. That goes away
> with CEF.
>
Software bugs can happen everywhere, it's a fact of human nature that will
never go away whether you hate it or like it. That's why we constantly
correct upon our faults and improve throughout our lives. With that being said,
Howard's statement of CEF being a clean design is very true. A router is nothing
more than a device that performs longest lookup on an IP address and decide
which interface (adjacency) to throw the packet out to. There are good routers,
mediocre routers, and TERRIBLE routers that achieve the same task.
Understanding your network traffic potentials and understanding how each
method forwards the packet is a first step in efficient operations.
Understanding that certain methods that perform process based IP lookup
(i.e. non-CEF) or base its decision on a flow cache or a cache on ethernet CAM,
or understanding methods that base decisions based on prefix lookup via an mtrie
(i.e. CEF) or ASIC + TCAM, etc against your network traffic is the first step in
running a network that won't break as often as operators who do not understand
the limits and design of the technology they use.
Without getting into discussions of CEF bugs, the CEF design was implemented to
achieve efficient packet forwarding rate through a clean and well conceived
design. There are also competing efficient deigns from other vendors as well
of course.
CEF not only builds an actual FIB, it is worth noting that CEF also disables
switching packet by scheduling a process to lookup the IP. Instead, FIB
lookup and majority of IP decisions are done within the interrupt routine w/
CEF enabled. This yields much higher packets per second (pps) performance than
aging 1980's/early 1990's design of process switching + fast cache.
Similar approaches have been done by other operating systems as well, even
some free unix/unix-like OSes such as NAPI for Linux and DEVICE POLLING +
Unicast FastForwarding code in FreeBSD 5.2 that can improve pps performance
of an x86 host by a substantial amount.
While IP lookups cannot be process switched in *BSD environment, the kernel
still has to switch its context and schedule a NETISR, similar to process
switching in IOS. FastForwarding in FreeBSD 5.2 eliminates scheduling of NETISR
by performing all unicast forwarding routines in a direct process to completion
within the interrupt routine, similar to CEF methdology (only difference being
FreeBSD uses much inefficient patricia trie as its routing table). Turning on
device pololing at that point will cause CPU to actively seek out and home in
to interrupts by iself, boosing performance even more.
As modern days of Gigabit IP routing is in our hands, people are trying
everything to achieve highest routing performance possible with the hardware
and given constraint. The proven industry method is a route lookup based on a
prepopulated FIB which is what CEF approach does effectively.
-J
-- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:46 GMT-3