Since FW4 with nft
appears to be on the agenda I came across this blog post [1] which seems to make a compelling case and perhaps worth to consider for the FW4 development.
Another consideration perhaps to skip nftables in favour of eBPF, which may benefit also less powerful CPUs, plus the XDP benefits shipping with kernel 5.4.
Upon a closer look the case may not be so compelling, considering each argument made in favour:
-
using structured JSON
- The native NFT format is similarly structured and slightly learner in the amount of bytes [2] (if that matters)
-
faster rule application
firewalld used to make a call to nft for every rule. With libnftables it’s now passing large blobs of JSON that can contain hundreds of rules. This reduces the numbers of round trips to the kernel and yields a significant performance improvement.
- the native NFT file format can contain any (large) number of rules as well
- not sure why they implemented a NFT binary call for every rules in the first place. Invoking
nft -f
just invokes the binary once only and processes the rules specified in the file
-
no fork()ing
Each call to nft would be a matter of forking a new process and waiting on the result. With libnftables there is no more forking.
- that I am not sure, perhaps because of the implementation cited in 2., but as far as I could observe invoking
nft -f
does not fork andnft
not being a daemon process
-
atomic transactions
Internally firewalld builds a set of changes and attempts to apply them all at once. The old nft backend still had to call nft once for every rule so this transaction wasn’t atomic and there were small periods of time between the rules being applied. This time frame is small, but can cause real issues in some scenarios.
- again perhaps a matter of their implementation cited in 2., however invoking
nft -f
the rule set is replaced in atomic fashion [3] (lightening compared to IPT)
-
Instead of building strings that are identical to the nft CLI firewalld needs to generate a python dictionary containing other dictionaries and lists. This will then be converted to JSON before being passed to libnftables.
- they have created a python wrapper (additional code) and whether that is more economic (and faster by a few milliseconds) than invoking
nft -f
I cannot tell.
As a composite I am not so sure whether the case is really that compelling and worth the coding effort.
[2] https://git.netfilter.org/nftables/tree/doc/libnftables-json.adoc
[3] https://wiki.nftables.org/wiki-nftables/index.php/Atomic_rule_replacement