svn commit: r191259 - head/sys/netinet

[Kip Macy]

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