[ previous ] [ next ] [ threads ]
 
 From:  "Tonix (Antonio Nati)" <tonix at interazioni dot it>
 To:  Chris Buechler <cbuechler at gmail dot com>, m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] CARP and OUT rules
 Date:  Thu, 08 Sep 2011 00:47:14 +0200
Il 08/09/2011 00:26, Chris Buechler ha scritto:
> On Wed, Sep 7, 2011 at 5:41 PM, Tonix (Antonio Nati)
> <tonix at interazioni dot it>  wrote:
>> Practically speaking instead of several "pass in"
>>
>>    pass in on eth0 proto tcp from any to 100.100.100.100
>>    pass in on eth1 proto tcp from any to 100.100.100.100
>>    pass in on eth2 proto tcp from any to 100.100.100.100
>>    pass in on eth3 proto tcp from any to 100.100.100.100
>>    ...............................
>>    pass in on ethN proto tcp from any to 100.100.100.100
>>
>> it would become simply
>>
>>    pass out on eth5 proto tcp from any to 100.100.100.100
>>
>> This "pass out" rules eliminatex all N rules needed for every incoming
>> interface.
>>
>> So, I feel handling of a rules table 20 times smaller would help a lot rules
>> checking performance.
>>
> That's correct - to an extent. I haven't specifically tested with
> ipfilter and am not extremely familiar with its internals, but the
> more rules you have, the more resources are required to evaluate the
> ruleset. From my testing on other BSD packet filters, it's not really
> relevant unless you're talking about a difference between 50000+ rules
> and a few dozen, it takes an extremely large ruleset to have a
> measurable difference. Even at that, the biggest impact to performance
> is the maximum number of new connections per second achievable, the
> time difference between opening a single connection with 1 rule and
> 100,000 rules is minuscule in the scheme of things in most all
> scenarios.

Thanks Chris for considerations, that makes me feel less guilty when I 
use too much rules :-).

As I told before, main scope is manageability.

Ideally, it would be great to have a two phase FW: first input rules, 
then output rules for survivors. That would cover any need.

But, coming to earth, a general "switch" about "In" or "Out" filtering 
would be enough, and would introduce monowall into big ISP data centers, 
for handling complex situation.

Because monowall is extremely fast and robust, a lot more than any 
comparable product, and speed and robustness are a must for an ISP.
If I have a basic CARP and out rules, with the speed on monowall, I 
don't see any space for other products.

Thanks,

Tonino


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>
>


-- 
------------------------------------------------------------
         Inter@zioni            Interazioni di Antonio Nati
    http://www.interazioni.it      tonix at interazioni dot it
------------------------------------------------------------