From owner-svn-src-all@FreeBSD.ORG Mon Apr 20 07:48:01 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AB311065670; Mon, 20 Apr 2009 07:48:01 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id C27448FC2B; Mon, 20 Apr 2009 07:48:00 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so671463ana.13 for ; Mon, 20 Apr 2009 00:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=J5XY5Oew3P11rVXEh6LpqKuINdJeO5xjacRRWaz6+yw=; b=J/LDpqYPEVB9rtZuPdqpT0YXzLn1Bfq7DsE0FYbBURdLFlrxQK2uOqvfAt78S5O1NX 976j0ZyG4Sy3C5vN1u8lzb84Ktg5qyJmWH/l3CV+C7M05HJq+SUiFQPUrpSWr/A/1RGj ScAT3QaMwio5dbkjBnA6MDz0Ta+s5DKnkgy8E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=YfEC3E0UhYWEno7vA985y1g20ZUg+JQMV23/vJESgcdkgZ69T369rgixC016bg+rmj 40/mO83AgC+tcExZD9DQhUIEOPcm58av88e1cI41mwzo9uCLAXw/KpmLz7755ahxav/H kz7v3hKNXvlokKCSYYghgvtRH/08vMgOs+pNI= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.92.17 with SMTP id p17mr7051429anb.138.1240213657470; Mon, 20 Apr 2009 00:47:37 -0700 (PDT) In-Reply-To: <200904200929.57914.zec@freebsd.org> References: <200904190444.n3J4i5wF098362@svn.freebsd.org> <200904200844.12344.zec@freebsd.org> <3c1674c90904200001s1d03c7d8udcd2dd4cf99984fd@mail.gmail.com> <200904200929.57914.zec@freebsd.org> Date: Mon, 20 Apr 2009 00:47:37 -0700 X-Google-Sender-Auth: f92fac4977767c09 Message-ID: <3c1674c90904200047s551a93a3wec97607b8212b0d@mail.gmail.com> From: Kip Macy To: Marko Zec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: svn-src-head@freebsd.org, Robert Watson , svn-src-all@freebsd.org, src-committers@freebsd.org, Andre Oppermann Subject: Re: svn commit: r191259 - head/sys/netinet X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 07:48:01 -0000 On Mon, Apr 20, 2009 at 12:29 AM, Marko Zec wrote: > On Monday 20 April 2009 09:01:25 Kip Macy wrote: > ... >> > But it seems to me that CAM lookups are pretty resilient against DoSin= g >> > by throwing malicious synthetic flows on them, whereas flow caches wil= l >> > melt down easily. >> >> Actually a CAM is a hardware implementation of a hash table. It has >> the same limitations. To claim that routers don't use flow tables >> because they are handled in hardware is a very strange thing to say. > > Well I may be missing something, but TCAMs typically used for routing loo= kups > are populated by the router's control plane, i.e. routing protocols, whic= h > means that the number of entries in the FIB / TCAM correlates to the size= of > RIB, i.e. it definitely doesn't grow / shrink dynamically in response to = the > current flow pattern. > > And I may not know how CAMs are implemented internally, but I'm not aware= of > any current vendor who would use (T)CAMs indexed by a flow hash for routi= ng > lookups. =A0Wouldn't it be a more common case for a TCAM to hold a FIB ta= ble, > sorted in a way which lets more specific prefixes having precedence? > > i.e. > > FIB =A0 =A0 =A0 =A0 =A0 =A0TCAM > 10.0.1.0/24 -> 00001010 00000000 00000001 XXXXXXXX -> output port X > 10.0.0.0/8 =A0-> 00001010 XXXXXXXX XXXXXXXX XXXXXXXX -> output port Y > 0.0.0.0/0 =A0 -> XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX -> output port Z > > This definitely doesn't change with flows dynamics IMO. I'm not saying they're the same thing. I'm saying conceptually they're equivalent. The main point I'm getting at is that if your working set exceeds the size of your cache (whatever you are caching) your performance will be poor - period. Even after a number optimizations, FreeBSD is not likely to be able to forward more than 500kpps per core in the near future (i.e. 4Mpps on an 8-core). In the somewhat extreme case (from the environments I'm familiar with), you have 1 million unique destination IPs (per core) within a 30 second window - or 1 packet to each destination every other second, a 2 million entry table would require 16MB + ~80MB for the flows themselves (per core). A large amount of memory certainly, but nothing extraordinary when my laptop contains more than twice that. I'm not saying that cases where there is no locality in the destination space or that they aren't important use cases. I'm just saying that they're very much in the minority and those users can either disable the flowtable or 'nooption' it in their config. -Kip