Date: Fri, 14 Nov 2003 15:43:44 -0500 From: Richard A Steenbergen <ras@e-gerbil.net> To: Haesu <haesu@towardex.com> Cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review Message-ID: <20031114204344.GY82121@overlord.e-gerbil.net> In-Reply-To: <20031114202847.GX82121@overlord.e-gerbil.net> References: <20031112024507.89398.qmail@web10007.mail.yahoo.com> <3FB20D2B.73624906@pipeline.ch> <20031112195529.GA48020@scylla.towardex.com> <3FB37F09.4050908@lowinger.se> <20031113135130.GA22054@scylla.towardex.com> <20031114202847.GX82121@overlord.e-gerbil.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031114204344.GY82121>