svn commit: r191259 - head/sys/netinet
zec at freebsd.org
Sun Apr 19 20:38:40 UTC 2009
On Sunday 19 April 2009 19:13:37 Kip Macy wrote:
> On Sun, Apr 19, 2009 at 3:18 AM, Andre Oppermann <andre at 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.
> 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
More information about the svn-src-head