On Sunday 19 April 2009 19:13:37 Kip Macy wrote: > On Sun, Apr 19, 2009 at 3:18 AM, Andre Oppermann <an...@freebsd.org> wrote: ... > > I have another question on the flowtable: What 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). The overhead of managing > > the flow table and the high churn rate make it much more expensive than > > a direct and already very efficient radix trie lookup. Additionally a > > well connected DFZ router has some 1k prefix updates per second. More > > information can be found for example at Cisco here: > > http://www.cisco.com/en/US/tech/tk827/tk831/technologies_white_paper0918 > >6a00800a62d9.shtml The same findings are also available from all other > > major router vendors like Juniper, Foundry, etc. > > > > Lets examine the situations: > > a) internal router with only a few routes; The routing and ARP table > > are small, lookups are very fast and everything is hot in the CPU > > caches anyway. > > b) DFZ router with 280k routes; A small flow table has constant > > thrashing becoming negative overhead only. A large flow table has a high > > maintenance > > overhead, 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. Marko > The number of routes > isn't the key metric, it is the number of flows active within a 30 > second period. On current hardware we probably could not handle more > than a couple of million concurrent flows (with a 4 million entry hash > table). _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
