Optimizing rule loading, iptables-1.3.0 and iptables-batch

Robert Hardy rhardy at webcon.ca
Sun Sep 26 21:24:31 CEST 2004


On Wed, 8 Sep 2004, Ludwig Nussel wrote:
> Robert Hardy wrote:
>> As a side note for the same ~30000 rules:
>> Time to load rules via iptables-batch using CIDR syntax: 23 mins 13 secs
>> Time to load rules via iptables-batch using IPRANGE syntax: 26 mins 36 secs
>> Time to load rules via iptables-restore (originally using CIDR syntax): 4
>> mins 25 secs
>>
>> The time to process the rules set isn't linear with size. In general if you
>> double a rule set it takes four times longer to load.
>>
>> At 30000 rules iptables-restore is still 5 times faster than iptables-batch.
>
> Wow, when I said 'lot' I for sure didn't think about that many :-) I
> was thinking in the order of like saving two seconds out of four
> when using the plain iptables command. The reason why iptables-batch
> takes longer most probably is because it commits after every rule
> whereas iptables-restore usually only does that once for each table.
> It can do so because rules are grouped by table and are not mixed.
> Maybe it's possible to reuse the handles in iptables-batch and do
> the commit at the end. I'll check that.

I thought I should point out that the improvements present in
iptables-1.3.0-20040925 totally rock! Good work!

I built up an i686 rpm based on that snapshot. Not only does it work well
(2004090x segfaulted on me), it is very fast.

I repeated my performance testing. On a P4 2.4GHz iptables-restore now takes
a couple of seconds to restore ~30000 rules. Even a 400MHz Celeron can
restore ~30K rules in 28 seconds.

This is a major improvement to say the least. It would awesome if you could
somehow harness this performance in iptables-batch.

Regards,
Rob

-- 
---------------------"Happiness is understanding."----------------------
Robert Hardy, B.Eng Computer Systems                  C.E.O. Webcon Inc.
rhardy <at> webcon <dot> ca    GPG Key available          (613) 276-7327



More information about the netfilter-devel mailing list