From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Wed Aug 18 2004 - 10:28:09 GMT-3
It's worth remembering that CEF is really the way a router is
_supposed_ to work, with two data structures that contain the same
information organized differently for different purposes, and kept
synchronized. The RIB (i.e., the output of show ip route) is
optimized for updating by sources of routing information. The FIB is
optimized for fast lookup of (primarily destination) addresses.
Fast, autonomous, and silicon switching were all compromises driven
by the cost, at the time, of fast RAM. All of these have far less
table space than CEF, with all the attendant issues of cache misses
and cache invalidation. Nevertheless, they were a valid way of
building affordable routers. They were also, to a reasonable extent,
optimizations for the enterprise environment, where there are a
limited number of most-frequently-used routes.
Since you MUST have a complete RIB, process switching became the
default for complex forwarding decisions, but with the cost of doing
such lookups as tree or list traversal rather than hashing or N-way
trie.
The issue of compromise also extends to load sharing (we rarely truly
"balance"). Per-packet with the RIB is inefficient, but, unless you
know of all active paths to all destinations, it's the only way to do
it when your only alternatives are caches smaller than the FIB.
Per-destination has always been known to be tricky. Research papers
going back many years, probably most signinficantly by Curtis
Villamizor, have shown developers that source-destination hash was
always the best mode, unless you have the information to do
reservation and traffic engineering.
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.
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:45 GMT-3