On Mon, 20 Apr 2009, Marko Zec wrote:
... 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.
... which means you fall back to the ordinary routing lookups, but only
after you have wasted cycles to compute a hash and found out that it doesn't
match anything in your cache -> in this case I would expect only a
degradation in performance, not an improvement.
The most recent example I'm aware of in our tree along those lines was from
the 4.x time range, I believe. My memory is a bit hazy, but it goes something
like this: in an initial analysis, we believed that the pain associated with a
synflood was from connection state and hash lookups of that state. Actually,
it turned out that much of it was from the creation of cloned routes for every
remote IP address from which we received a SYN, as we would clone the route
and cache it very early. Features like the syncache and syncookies were very
important for mitigating SYN flood overhead, but in part because avoiding
allocating routing-related state was actually just as, if not more, important
as the "ordinary" connection state.
Many of the concerns brought up in the discussion so far are reasons that I
asked Kip to do the following with the flowcache:
(1) Make this a kernel option
(2) Disable it by default
I would also agree with the view that if/when our routing table is more
up-to-snuff, we might well want to lose the flowcache again, as arguably a
revised routing table implementation, (combined with connection-oriented
route/llentry caching) should not require or benefit from a flowcache.
However, there's quite a bit of work required to get us there. Happily Kip
already has a patch for route/llentry caching, but the historic opacity of the
routing code is still hurting us in seeing optimization of the base routing
table.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
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"
