Hi Christian,
On Sat, 24 Apr 2021 11:08:20 +0000
"Frömmel, Christian" <christian.froemmel@xxxxxxxxxx> wrote:
> Then our parser combines both into the set with
>
> elements = {
> 123.45.6.0/24 . 80,
> 123.45.6.7 . 80,
> }
>
> When installing this we get
>
> ./debug_username.nft:4:7-23: Error: Could not process rule: File
> exists set user-username_tcp {
> ^^^^^^^^^^^^^^^^^
>
> This isn't "auto-merged" as we expected. To make it a little more
> complex, we have network-ranges and port-ranges on some rules.
> Therefore, the auto-merge would have to "unroll" and merge both parts.
>
> Is there any way to achieve this combined-sets with auto-merge?
The set you describe is implemented by the nft_set_pipapo set back-end,
that allows concatenation of ranges. For reference, "123.45.6.7 . 80"
would be handled by the nft_set_hash back-end, and nft_set_rbtree would
handle "123.45.6.0/24".
The definition of overlap needs to differ slightly between different set
back-ends simply because they inherently allow different types of
overlap.
For nft_set_pipapo, the set you describe has elements that are
completely overlapping, and thus they're not merged, which would happen
instead if they were partially overlapping (thus making "merging"
sensible). Here you want the second element to be ignored, instead.
If you "create" those elements, though, instead of performing an "add",
errors from already existing elements are ignored. From nft(8):
create command is similar to add with the exception that none
of the listed elements may already exist.
I didn't check right now with your set, but it should work.
I know this should be documented in better detail, that's still
(arguably for too long) on my to-do list. For the moment being, the set
examples in these test scripts:
https://git.netfilter.org/nftables/tree/tests/shell/testcases/sets/0044interval_overlap_0
https://git.netfilter.org/nftables/tree/tests/shell/testcases/sets/0044interval_overlap_1
might help clarifying this behaviour.
--
Stefano
