Re: xdp-filter troubles

Topi Wala <[email protected]> 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