On 3/30/26 15:21, Dion Bosschieter wrote:
On 3/27/26 17:58, Daniel P. Berrangé wrote:
On Mon, Feb 16, 2026 at 11:42:36AM +0100, Dion Bosschieter wrote:
Unsupported nwfilter features (for now): - STP filtering - Gratuitous ARP filtering - IPSets (potential future support via nft sets)
IPSets via nft sets could work if the user predefines the nft sets in the table where they are going to be referenced. This requires the user to create the libvirt table first before starting libvirt. That is not ideal, but could be a solution.
Not something that needs to happen premerge is my opinion.
- Reject due to filtering in pre/postrouting, using drop instead of reject, copying logic from existing ebiptables ebtables actions
I should take a 2nd look at changing the _inet table to an inet table type, this way we can support reject and be more compatible with ebiptables.
I tried to use the inet type in combination with the forward and input hook, but I think this causes more issues than it solves (ability to reject). Overall the nft prerouting & postrouting design is easier to read and understand than having the iptables libvirt-host-in, libvirt-in, libvirt-in-post, libvirt-out design. I also seem to have issues seeing packets with the forward hook in nft, that might be due to the bridge-nf-call-iptables sysctl (https://netdevconf.info/1.1/proceedings/papers/Bridge-filter-with-nftables.p...)
What are your thoughts on these gaps ?
Looking at what worked for adding rarp support, I think the same can be done for STP, it requires a bit of, to see if the rules indeed match.
The Gratuituous ARP gap triggers a warning in libvirt-tck tests.
I finally was able to get garp support working, this also requires a bit of work and is not pretty. I'll describe below what solution seems to work. Tested by sending garp traffic using arping -I br0 -A 192.168.1.1
nftables nft command doesn't support field to field matching a simple arp saddr ip == arp daddr ip, would otherwise suffice.
From ebtables man page: [!] --arp-gratuitous Checks for ARP gratuitous packets: checks equality of IPv4 source address and IPv4 destination address inside the ARP header.
Something that could work though is creating an nftables concatenation set: { type ipv4_addr . ipv4_addr }
Creating 1 set to match against, would mean we will have list all ipv4 ips in that set. That is not a solution.
Creating 4 sets to match against combined with netmasking would however work.
garp-1 { 0.0.0.0 . 0.0.0.0, 1.0.0.0 . 1.0.0.0, ... garp-2 { 0.0.0.0 . 0.0.0.0, 0.1.0.0 . 0.1.0.0, ... garp-3 { 0.0.0.0 . 0.0.0.0, 0.0.1.0 . 0.0.1.0, ... garp-4 { 0.0.0.0 . 0.0.0.0, 0.0.0.1 . 0.0.0.1, ...
For full sets, see: https://gist.github.com/ dionbosschieter/01665ef03d19950c37e8231bd00d1736
And finally the garp rule:
arp saddr ip & 255.0.0.0 . arp daddr ip & 255.0.0.0 @garp-1 arp saddr ip & 0.255.0.0 . arp daddr ip & 0.255.0.0 @garp-2 arp saddr ip & 0.0.255.0 . arp daddr ip & 0.0.255.0 @garp-3 arp saddr ip & 0.0.0.255 . arp daddr ip & 0.0.0.255 @garp-4 counter packets 3 bytes 132 accept comment "priority=-500"
I can add that the garp sets get added to the _ethernet table. After that adding the rule itself is trivial.
I can submit this in a v6 as well. I am not a fan of having a static set with 1024 entries in it. But I don't see other solutions to support garp filtering. Kind regards, Dion