tcp hostcache and ip fastforward for review

Richard A Steenbergen ras at e-gerbil.net
Fri Nov 14 12:43:46 PST 2003


On Fri, Nov 14, 2003 at 03:28:47PM -0500, Richard A Steenbergen wrote:
> 
> You're a little off on the implementation of the layer 3 switches. They do
> not use "flows" persay, but rather their hardware destination lookups are
> not pre-programmed. This means that when you hit a new destination which 
> has never been seen before, the software must do a slow lookup to program 
> the CAM. This is more like Cisco's fastcache than flowcache, but yes the 
> end result is poor (or rather, unpredictable) performance during random 
> destination routing (worms anyone).

Actually I'll take that back, as it's not 100% accurate for everyone. Some
vendors actually do install a /32 route for every active destination by
traffic (which still isn't quite netflow, src+dst+port+(maybe tos) pairs,
but almost as bad). Without some form of accelerated expiration mechanism
under load (coughghettohackcough), you end up exhausting the cache space
available. It's just shooting yourself in the same foot with a different 
gun. The other ghetto hack available is to aggregate CAM entries, usually 
based on having default routes and very few real egress ports. I believe 
Cisco is actually pre-programming the CAM starting on the sup2/msfc2 now.

Bottom line, that kind of performance is what you get when you take
hardware designed for layer 2 exact match lookups (mac addresses), try to
turn it into a caching mechanism for l3 routing, and sell it to enterprise
customers who don't really care about performance under "core routing" (or
otherwise random destination) conditions.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


More information about the freebsd-net mailing list