svn commit: r191259 - head/sys/netinet

[Marko Zec]

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.

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).