From: "Neal P. Murphy" <neal.p.murphy@alum.wpi.edu>
Cc: netfilter-devel@vger.kernel.org, netfilter@vger.kernel.org
Subject: Re: Reload IPtables
Date: Mon, 28 Jun 2021 22:02:41 -0400 [thread overview]
Message-ID: <20210628220241.64f9af54@playground> (raw)
In-Reply-To: <20210628104310.61bd287ff147a59b12e23533@plushkava.net>
On Mon, 28 Jun 2021 10:43:10 +0100
Kerin Millar <kfm@plushkava.net> 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? Some years ago, I found through experimentation that some rules were 'lost' when restoring more than 25 000 rules. If I placed a COMMIT every 20 000 rules or so, then all rules would be properly loaded. I think COMMITs break atomicity. I tested with 100k to 1M rules. I was comparing the efficiency of iptables-restore with another tool that read from STDIN; the other tool was about 5% more efficient.
next prev parent reply other threads:[~2021-06-29 2:02 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <08f069e3-914f-204a-dfd6-a56271ec1e55.ref@att.net>
2021-06-25 19:24 ` Reload IPtables slow_speed
2021-06-25 20:51 ` David Hajes
2021-06-25 21:30 ` slow_speed
2021-06-25 22:20 ` Stephen Satchell
[not found] ` <cd80bdd2-7816-f27f-d3fe-5042d213700e@satchell.net>
2021-06-25 22:37 ` slow_speed
2021-06-25 23:43 ` Reindl Harald
2021-06-25 23:47 ` slow_speed
2021-06-25 23:52 ` Reindl Harald
2021-06-26 7:19 ` David Hajes
2021-06-26 10:13 ` Reindl Harald
2021-06-26 10:27 ` David Hajes
2021-06-26 10:43 ` Reindl Harald
2021-06-26 10:54 ` David Hajes
2021-06-28 7:32 ` Alessandro Vesely, Alessandro Vesely
2021-06-28 7:46 ` Reindl Harald
2021-06-28 9:23 ` Alessandro Vesely, Alessandro Vesely
2021-06-28 9:43 ` Kerin Millar
2021-06-29 2:02 ` Neal P. Murphy [this message]
[not found] ` <20210629083652.GA10896@salvia>
2021-06-29 8:37 ` Pablo Neira Ayuso
2021-07-01 1:49 ` Neal P. Murphy
2021-06-29 9:10 ` Kerin Millar
2021-06-28 10:17 ` Reindl Harald
2021-06-28 11:47 ` Alessandro Vesely, Alessandro Vesely
2021-06-28 12:03 ` Reindl Harald
2021-06-28 13:46 ` Kerin Millar
2021-06-28 16:35 ` Reindl Harald
2021-06-28 17:10 ` Kerin Millar
2021-06-28 17:16 ` Reindl Harald
2021-06-28 17:35 ` Alessandro Vesely, Alessandro Vesely
2021-06-28 18:15 ` Reindl Harald
2021-06-28 13:36 ` Stephen Satchell
2021-06-27 14:56 ` slow_speed
2021-06-27 15:46 ` G.W. Haywood
2021-06-27 18:29 ` Stephen Satchell
2021-06-27 18:11 ` Kerin Millar
2021-06-27 18:32 ` slow_speed
2021-06-27 18:57 ` Reindl Harald
2021-06-27 20:57 ` slow_speed
2021-06-27 21:33 ` Reindl Harald
2021-06-27 19:07 ` Kerin Millar
2021-06-27 19:10 ` Kerin Millar
2021-06-27 19:56 ` Stephen Satchell
2021-06-27 20:12 ` Kerin Millar
2021-06-27 20:20 ` Reindl Harald
2021-06-27 19:43 ` Stephen Satchell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210628220241.64f9af54@playground \
--to=neal.p.murphy@alum.wpi.edu \
--cc=netfilter-devel@vger.kernel.org \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox