From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 12:43:46 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0B3D16A4CE for ; Fri, 14 Nov 2003 12:43:46 -0800 (PST) Received: from overlord.e-gerbil.net (e-gerbil.net [69.31.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B060243FD7 for ; Fri, 14 Nov 2003 12:43:45 -0800 (PST) (envelope-from ras@overlord.e-gerbil.net) Received: from overlord.e-gerbil.net (ras@localhost.e-gerbil.net [127.0.0.1]) by overlord.e-gerbil.net (8.12.9/8.12.9) with ESMTP id hAEKhijg078446; Fri, 14 Nov 2003 15:43:44 -0500 (EST) (envelope-from ras@overlord.e-gerbil.net) Received: (from ras@localhost) by overlord.e-gerbil.net (8.12.9/8.12.9/Submit) id hAEKhiYB078445; Fri, 14 Nov 2003 15:43:44 -0500 (EST) (envelope-from ras) Date: Fri, 14 Nov 2003 15:43:44 -0500 From: Richard A Steenbergen To: Haesu Message-ID: <20031114204344.GY82121@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031114202847.GX82121@overlord.e-gerbil.net> User-Agent: Mutt/1.5.1i cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2003 20:43:46 -0000 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 http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)