From owner-svn-src-head@FreeBSD.ORG Sun Apr 19 21:05:56 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91357106564A; Sun, 19 Apr 2009 21:05:56 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id EAB7D8FC08; Sun, 19 Apr 2009 21:05:55 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so576183ana.13 for ; Sun, 19 Apr 2009 14:05:55 -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=Ftx37twJE8hmhzmL4YrmGrqppPpcUglsC9zdfpLS7fw=; b=CAVSkqesbOIY9AnPTK/+lKqGOst6yhd6fGwSLXirmvCNxM8a99Llhxtz/Fwqe43HwX jyXHLRQomccRaBdRTsS69tDxaXPgifLVBpSwB9DQJfEJFA4/5qaoWLpX0sKnJ2wZ1/Tg hw3ws+jYVTu6SFapE1Rkyj8YNbjT/FnIkoFNY= 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=crFvZWou6mqm+ZpEHMKhEAaCFIMwviAlaGzDS9bTIctJhqy5c8yRlDHPDYM+zgVQiL pi2dw0F77GqiRql8YmJ5GHGIEqKjUuxsJe665HtzLYmYSdsXD6OiEZ4VkGq2JBnlgwfO wcu9/vNzk+iD0OsP1btCMg3BE7P2B+GKxXeZc= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.33.15 with SMTP id g15mr6212495ang.103.1240175155057; Sun, 19 Apr 2009 14:05:55 -0700 (PDT) In-Reply-To: <200904192221.55744.zec@freebsd.org> References: <200904190444.n3J4i5wF098362@svn.freebsd.org> <49EAFA62.3010000@freebsd.org> <3c1674c90904191013h119d040u1c59772a94dad2f1@mail.gmail.com> <200904192221.55744.zec@freebsd.org> Date: Sun, 19 Apr 2009 14:05:55 -0700 X-Google-Sender-Auth: 927d4008075c5819 Message-ID: <3c1674c90904191405v56298134g286ea31ee4680769@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-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 21:05:57 -0000 On Sun, Apr 19, 2009 at 1:21 PM, Marko Zec wrote: > On Sunday 19 April 2009 19:13:37 Kip Macy wrote: >> On Sun, Apr 19, 2009 at 3:18 AM, Andre Oppermann wro= te: > ... >> > I have another question on the flowtable: =A0What is the pupose of it? >> > All router vendors have learned a long time ago that route caching >> > (aka flow caching) doesn't work out on a router that carries the DFZ >> > (default free zone, currently ~280k prefixes). =A0The overhead of mana= ging >> > the flow table and the high churn rate make it much more expensive tha= n >> > a direct and already very efficient radix trie lookup. Additionally a >> > well connected DFZ router has some 1k prefix updates per second. =A0Mo= re >> > information can be found for example at Cisco here: >> > =A0http://www.cisco.com/en/US/tech/tk827/tk831/technologies_white_pape= r0918 >> >6a00800a62d9.shtml The same findings are also available from all other >> > major router vendors like Juniper, Foundry, etc. >> > >> > Lets examine the situations: >> > =A0a) internal router with only a few routes; The routing and ARP tabl= e >> > =A0 =A0are small, lookups are very fast and everything is hot in the C= PU >> > =A0 =A0caches anyway. >> > =A0b) DFZ router with 280k routes; A small flow table has constant >> > thrashing becoming negative overhead only. =A0A large flow table has a= high >> > maintenance >> > =A0 =A0overhead, higher lookup times and sill a significant amount of >> > thrashing. The overhead of the flow table is equal or higher than a >> > direct routing table lookup. >> > Concluding that a flow table is never a win but a liability in any >> > realistic setting. >> >> You're assuming that a Cisco- / Juniper-class workload is >> representative of where FreeBSD is deployed. I agree that FreeBSD is >> sub-optimal for large routing environments for a whole host of other >> reasons. A better question is what are "typical" FreeBSD deployments, >> and how well would it work there. The flowtable needs to be sized to >> correspond to the number of flows, its utility rapidly diminishes as >> the number of collisions per bucket increases. > > ... which makes a flow cache a perfect DoS target in any environment, be = it a > DFZ or enterprise router or an end host or whatever. Uhm, assuming that you don't put a limit on the number of flows allocated - which I do. When you hit the zone limit for flows you simply stop caching new flows. So the added overhead is simply the extra cache misses up to the collision depth for the bucket. Are you two familiar with CAMs? -Kip --=20 All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke