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.pdf)
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
