> Hmm, such a scheme raises suspicion that in your particular case very few flow
> cache lookups could be serviced from CPU caches. 16MB + 80MB sounds to be in
> range with memory footprint of a DFZ table stored in our normal radix tree -
> so where's the benefit of the flow cache?
>
Well its a co
On Mon, 20 Apr 2009, Kip Macy wrote:
... 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 improv
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 flow
On Monday 20 April 2009 09:47:37 Kip Macy wrote:
> On Mon, Apr 20, 2009 at 12:29 AM, Marko Zec wrote:
> > On Monday 20 April 2009 09:01:25 Kip Macy wrote:
> > ...
> >
> >> > But it seems to me that CAM lookups are pretty resilient against
> >> > DoSing by throwing malicious synthetic flows on them
[snip]
People, you are missing a few points here:
- if you want to run a DFZ router or do not like flowtables, turn
them off. There is a kernel option for that.
- if you use it and it doesn't perform but you have a valid setup,
tune it.
- if you are under a (D)DoS your least problem m
On Mon, Apr 20, 2009 at 12:29 AM, Marko Zec wrote:
> On Monday 20 April 2009 09:01:25 Kip Macy wrote:
> ...
>> > 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.
>>
>> Actuall
On Monday 20 April 2009 09:01:25 Kip Macy wrote:
...
> > 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
> ... 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 c
On Sunday 19 April 2009 23:05:55 Kip Macy wrote:
> On Sun, Apr 19, 2009 at 1:21 PM, Marko Zec wrote:
> > On Sunday 19 April 2009 19:13:37 Kip Macy wrote:
> >> On Sun, Apr 19, 2009 at 3:18 AM, Andre Oppermann
> >> wrote:
> >
> > ...
> >
> >> > I have another question on the flowtable: What is the
On Sun, Apr 19, 2009 at 1:21 PM, Marko Zec wrote:
> On Sunday 19 April 2009 19:13:37 Kip Macy wrote:
>> On Sun, Apr 19, 2009 at 3:18 AM, Andre Oppermann wrote:
> ...
>> > I have another question on the flowtable: What is the pupose of it?
>> > All router vendors have learned a long time ago that
On Sunday 19 April 2009 19:13:37 Kip Macy wrote:
> On Sun, Apr 19, 2009 at 3:18 AM, Andre Oppermann 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
On Sun, Apr 19, 2009 at 3:18 AM, Andre Oppermann wrote:
> Robert Watson wrote:
>>
>> On Sun, 19 Apr 2009, Kip Macy wrote:
>>
>>> Author: kmacy
>>> Date: Sun Apr 19 04:44:05 2009
>>> New Revision: 191259
>>> URL: http://svn.freebsd.org/changeset/base/191259
> I have another question on the flowtabl
Robert Watson wrote:
On Sun, 19 Apr 2009, Kip Macy wrote:
Author: kmacy
Date: Sun Apr 19 04:44:05 2009
New Revision: 191259
URL: http://svn.freebsd.org/changeset/base/191259
Log:
- Allocate a small flowtable in ip_input.c (changeable by tuneable)
- Use for accelerating ip_output
If you ant
On Sun, 19 Apr 2009, Kip Macy wrote:
Author: kmacy
Date: Sun Apr 19 04:44:05 2009
New Revision: 191259
URL: http://svn.freebsd.org/changeset/base/191259
Log:
- Allocate a small flowtable in ip_input.c (changeable by tuneable)
- Use for accelerating ip_output
If you anticipate the flowtable
Author: kmacy
Date: Sun Apr 19 04:44:05 2009
New Revision: 191259
URL: http://svn.freebsd.org/changeset/base/191259
Log:
- Allocate a small flowtable in ip_input.c (changeable by tuneable)
- Use for accelerating ip_output
Modified:
head/sys/netinet/ip_input.c
head/sys/netinet/ip_output.c
15 matches
Mail list logo