Topi Wala <walatopi@xxxxxxxxx> writes: > Sorry about the subject. I had to forward after using text (default is > http in gmail). > My kernel version is 5.7.17 (quite new). I am using xdp (ip link show > on the device shows the xdp, not xdpgeneric). > I'm using bpftool, since this is to deploy to a third party, and using > standard linux tools (bpftool, iproute2) is fine, userspace binaries > are not. Heh, that's an interesting policy - I'm guessing whoever set it doesn't really understand BPF... :) > Is there anything I miss by not using the xdp-filter binary? Well, a nicer user interface? But no, technically the BPF side should work just fine, as long as you populate the maps correctly. Just don't expect any future changes to xdp-filter to take your... interesting... use case into account :) > However, I think I have figured out the issue, and I'm quite surprised by it. > It appears that as soon as the xdpfilter program is attached, the arp > entry for that IP is discarded from all the entities connected to that > bridge. > The peer node consequently does an ARP before ping, and since ARP is > not an IP packet, it doesn't show up in the bpf log. > Since the remote node doesn't get an ARP response (arp request is > dropped), it doesn't send the ping packet at all. Hmm, installing an XDP program does call the netdev notifiers, so I guess the iface state can flip, causing the neighbour entries to be evicted. In general, it's probably safest to consider loading an XDP program to be a potentially destructive event (some physical devices will even reconfigure the hardware when this happens). This is only on first install, though, swapping between already-installed XDP programs should not have such issues. You're not the first person to run into the ARP behaviour, BTW. I guess it may make sense to parse neighbour requests and include them in the IP filter; feel free to open an issue in the xdp-tools repo for this (or even better, a pull request!). -Toke
|