Re: old question revisited: can rely in 'iptables-restore' format?

[/dev/rob0 <rob0@gmx.co.uk>]

On Mon, Aug 20, 2012 at 10:21:37PM -0400, Neal Murphy wrote:
> On Monday 20 August 2012 20:30:26 /dev/rob0 wrote:
> > The main benefit is that iptables-restore is atomic. All changes
> > are committed in one pass. Any error in the ruleset means your
> > existing ruleset is not replaced.
> 
> [Minor digression]
> By 'atomic', do you mean that all of the changes are made with a 
> single COMMIT, regardless of how many tables are accessed and 
> regardless of how many rules are processed?

I don't know. I was hoping that someone familiar with the source 
would answer.

> It's been my experience that there is an implicit COMMIT at every 
> table change, and there is a ballpark limit of around 20,000 rules 
> per commit. Thus:

>   - if the file you are feeding to iptables-restore references one
>     table only and contains fewer than around 20,000 rules, the
>     operation will be atomic.

>   - if the file you are feeding to iptables-restore references more
>     than one table and contains fewer than around 20,000 rules per
>     table, then only the changes *per table* will be atomic.
>   - If the changes to a table contain more than around 20,000 rules,
>     then that operation will require more than one COMMIT and will
>     NOT be atomic.
> 
> When relatively small change sets are involved, I agree that 
> iptables-restore is atomic. But when very large change sets are 
> involved, I disagree: iptables-restore is *not* necessarily 
> atomic. To be pedantic, it would be correct to say that 
> iptables-restore operates atomically only under certain
> conditions.

Interesting, thanks. I think my post was right in the usual case, 
however, and that your examples of >20K rules might be better
handled by ipset(8).
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: