Date: Sun, 19 Apr 2009 14:05:55 -0700 From: Kip Macy <kmacy@freebsd.org> To: Marko Zec <zec@freebsd.org> Cc: svn-src-head@freebsd.org, Robert Watson <rwatson@freebsd.org>, svn-src-all@freebsd.org, src-committers@freebsd.org, Andre Oppermann <andre@freebsd.org> Subject: Re: svn commit: r191259 - head/sys/netinet Message-ID: <3c1674c90904191405v56298134g286ea31ee4680769@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Apr 19, 2009 at 1:21 PM, Marko Zec <zec@freebsd.org> wrote: > On Sunday 19 April 2009 19:13:37 Kip Macy wrote: >> On Sun, Apr 19, 2009 at 3:18 AM, Andre Oppermann <andre@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3c1674c90904191405v56298134g286ea31ee4680769>