Re: Optimizing rule loading, iptables-1.3.0 and iptables-batch

[Ludwig Nussel <ludwig.nussel@suse.de>]

Robert Hardy wrote:
> On Tue, 7 Sep 2004, Henrik Nordstrom wrote:
> >On Tue, 7 Sep 2004, Robert Hardy wrote:
> >>iptables-restore still only allows you to save and restore whole tables.
> >
> >Not entirely true. There is the --noflush (-n) option to iptables-restore 
> >which allows you to do any kinds of operations you please.
> 
> >Load a user chain:
> >
> >iptables-restore --noflush << EOF
> >*filter
> >-F userchain
> >-A userchain .....
> >COMMIT
> >EOF
> 
> Ah Good! I obviously missed that somehow....
> 
> 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.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   SUSE LINUX AG, Development
 V_/_  http://www.suse.de/