Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 20 Apr 2009 00:01:25 -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:  <3c1674c90904200001s1d03c7d8udcd2dd4cf99984fd@mail.gmail.com>
In-Reply-To: <200904200844.12344.zec@freebsd.org>
References:  <200904190444.n3J4i5wF098362@svn.freebsd.org> <200904192221.55744.zec@freebsd.org> <3c1674c90904191405v56298134g286ea31ee4680769@mail.gmail.com> <200904200844.12344.zec@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> ... 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.

If your normal operating conditions are DDOS then you have more
serious problems. I said that the system would not collapse as you
were in fact claiming, not that it would perform optimally.


>
>> So the added overhead is simply the
>> extra cache misses up to the collision depth for the bucket. Are you
>> two familiar with CAMs?
>
> Not really, but I've heared of anecdotes that Ciscos that were capped at 256K
> FIB entries in CAM had to fall back to lookups in software once the size of
> DFZ table exceeded the 256K figure - so everybody rushed to get rid
> of^H^H^H^H upgrade such hardware around 1.5 years ago in anticipation of DFZ
> table bloom.

If your memory is too small for your routing table you will have a
problem. If your flow table is too small you will have a problem.
However, on modern hardware, when running FreeBSD, unless every packet
you are seeing is coming from a different source you'll be rate
limited by the number of kpps your system can handle long before you
run out of space to store a collision free flow table.

>
> But it seems to me that CAM lookups are pretty resilient against DoSing by
> throwing malicious synthetic flows on them, whereas flow caches will melt
> down easily.

Actually a CAM is a hardware implementation of a hash table. It has
the same limitations. To claim that routers don't use flow tables
because they are handled in hardware is a very strange thing to say.

-Kip



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3c1674c90904200001s1d03c7d8udcd2dd4cf99984fd>