From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Timo Sigurdsson <public_timo.s@silentcreek.de>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: Moving from ipset to nftables: Sets not ready for prime time yet?
Date: Thu, 30 Jul 2020 21:27:45 +0200 [thread overview]
Message-ID: <20200730192745.GA5293@salvia> (raw)
In-Reply-To: <20200702223010.C282E6C848EC@dd34104.kasserver.com>
On Fri, Jul 03, 2020 at 12:30:10AM +0200, Timo Sigurdsson wrote:
> Hi,
>
> I'm currently migrating my various iptables/ipset setups to nftables. The nftables syntax is a pleasure and for the most part the transition of my rulesets has been smooth. Moving my ipsets to nftables sets, however, has proven to be a major pain point - to a degree where I started wondering whether nftables sets are actually ready to replace existing ipset workflows yet.
[...]
> 2) Atomic reload of large sets unbearably slow
> Moving on without the auto-merge feature, I started testing sets with actual lists I use. The initial setup (meaning populating the sets for the first time) went fine. But when I tried to update them atomically, i.e. use a script file that would have a 'flush set' statement in the beginning and then an 'add element' statement with all the addresses I wanted to add to it, the system seemed to lock up. As it turns out, updating existing large sets is excessively slow - to a point where it becomes unusable if you work with multiple large sets. I reported the details including an example and performance indicators here [4]. The only workaround for this (that keeps atomicity) I found so far is to reload the complete firewall configuration including the set definitions. But that has other unwanted side-effects such as resetting all counters and so on.
>
> 3) Referencing sets within a set not possible
> As a workaround for the auto-merge issues described above (and also for another use case), I was looking into the possibility to reference sets within a set so I could create a set for each source list I use and reference them in a single set so I could match them all at once without duplicating rules for multiple sets. To be clear, I'm not really sure whether this is supposed to work all. I found some commits which suggested to me it might be possible [5][6]. Nevertheless, I couldn't get this to work.
For the record, these two issues are now fixed in git.
Thank you for reporting.
next prev parent reply other threads:[~2020-07-30 19:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-02 22:30 Moving from ipset to nftables: Sets not ready for prime time yet? Timo Sigurdsson
2020-07-03 9:28 ` Stefano Brivio
2020-07-03 10:24 ` Jozsef Kadlecsik
2020-07-03 13:38 ` Stefano Brivio
2020-07-03 14:03 ` Timo Sigurdsson
2020-07-30 19:27 ` Pablo Neira Ayuso [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-07-02 23:18 Timo Sigurdsson
2020-07-03 7:04 ` G.W. Haywood
2020-07-03 10:39 ` Reindl Harald
2020-07-08 7:51 ` Trent W. Buck
2020-07-08 10:16 ` Reindl Harald
2020-07-08 10:36 ` Pablo Neira Ayuso
2020-07-08 10:48 ` Reindl Harald
2020-07-09 4:40 ` Trent W. Buck
2020-07-14 13:27 ` Timo Sigurdsson
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=20200730192745.GA5293@salvia \
--to=pablo@netfilter.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=public_timo.s@silentcreek.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.