All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Topi Wala <walatopi@gmail.com>
Cc: xdp-newbies@vger.kernel.org
Subject: Re: xdp-filter troubles
Date: Mon, 21 Sep 2020 16:02:54 +0200	[thread overview]
Message-ID: <87zh5jp6r5.fsf@toke.dk> (raw)
In-Reply-To: <CAOfgOft3xQgpxDmrExdJdPoiqcYD=yL0DNRHA6FRkgGKePQTQQ@mail.gmail.com>

Topi Wala <walatopi@gmail.com> 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


  reply	other threads:[~2020-09-21 14:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-21  5:05 Topi Wala
2020-09-21  9:44 ` xdp-filter troubles Toke Høiland-Jørgensen
2020-09-21 13:35   ` Topi Wala
2020-09-21 14:02     ` Toke Høiland-Jørgensen [this message]
2020-09-22  2:28       ` Topi Wala

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zh5jp6r5.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=walatopi@gmail.com \
    --cc=xdp-newbies@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.