From owner-svn-src-all@FreeBSD.ORG Mon Apr 20 07:30:12 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 CBCFF1065670; Mon, 20 Apr 2009 07:30:12 +0000 (UTC) (envelope-from zec@freebsd.org) Received: from labs4.cc.fer.hr (labs4.cc.fer.hr [161.53.72.24]) by mx1.freebsd.org (Postfix) with ESMTP id 54C7A8FC1B; Mon, 20 Apr 2009 07:30:11 +0000 (UTC) (envelope-from zec@freebsd.org) Received: from sluga.fer.hr (sluga.cc.fer.hr [161.53.72.14]) by labs4.cc.fer.hr (8.14.2/8.14.2) with ESMTP id n3K7UUE3025702; Mon, 20 Apr 2009 09:30:30 +0200 (CEST) Received: from [192.168.200.110] ([161.53.19.79]) by sluga.fer.hr over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 09:30:07 +0200 From: Marko Zec To: Kip Macy Date: Mon, 20 Apr 2009 09:29:57 +0200 User-Agent: KMail/1.9.10 References: <200904190444.n3J4i5wF098362@svn.freebsd.org> <200904200844.12344.zec@freebsd.org> <3c1674c90904200001s1d03c7d8udcd2dd4cf99984fd@mail.gmail.com> In-Reply-To: <3c1674c90904200001s1d03c7d8udcd2dd4cf99984fd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904200929.57914.zec@freebsd.org> X-OriginalArrivalTime: 20 Apr 2009 07:30:08.0124 (UTC) FILETIME=[D4C6ABC0:01C9C189] X-Scanned-By: MIMEDefang 2.64 on 161.53.72.24 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:30:13 -0000 On Monday 20 April 2009 09:01:25 Kip Macy wrote: ... > > But it seems to me that CAM lookups are pretty resilient against DoSing > > by throwing malicious synthetic flows on them, whereas flow caches will > > 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 lookups are populated by the router's control plane, i.e. routing protocols, which 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 routing lookups. Wouldn't it be a more common case for a TCAM to hold a FIB table, sorted in a way which lets more specific prefixes having precedence? i.e. FIB TCAM 10.0.1.0/24 -> 00001010 00000000 00000001 XXXXXXXX -> output port X 10.0.0.0/8 -> 00001010 XXXXXXXX XXXXXXXX XXXXXXXX -> output port Y 0.0.0.0/0 -> XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX -> output port Z This definitely doesn't change with flows dynamics IMO. Marko