On Mon, Jun 28, 2021 at 10:02:41PM -0400, Neal P. Murphy wrote: > On Mon, 28 Jun 2021 10:43:10 +0100 > Kerin Millar <kfm@xxxxxxxxxxxxx> wrote: > > > Now you benefit from atomicity (the rules will either be committed at once, in full, or not at all) and proper error handling (the exit status value of iptables-restore is meaningful and acted upon). Further, should you prefer to indent the body of the heredoc, you may write <<-EOF, though only leading tab characters will be stripped out. > > > > [minor digression] > > Is iptables-restore truly atomic in *all* cases? Packets either see the old table or the new table, no intermediate ruleset state is exposed to packet path. > Some years ago, I found through experimentation that some rules were > 'lost' when restoring more than 25 000 rules. Could you specify kernel and userspace versions? Rules are not 'lost' when restoring large rulesets. > If I placed a COMMIT every 20 000 rules or so, then all rules would > be properly loaded. I think COMMITs break atomicity. Why are you placing COMMIT in every few rules 20 000 rules? > I tested with 100k to 1M rules. iptables is handling very large rulesets already. > I was comparing the efficiency of iptables-restore with another tool > that read from STDIN; the other tool was about 5% more efficient. Could you please specify what other tool are you refering to? iptables-restore is the best practise to restore your ruleset. You should also iptables-restore to perform incremental updates via --noflush.
