The probe would roughly be as follows: create a new netns, add a route in there, assign a BPF prog to the interface in the netns which does a fib lookup, ensure the neighbor resolution of the fib lookup fails but the route lookup succeeds and finally test whether the fib_params->ifindex output is non-zero while the input was zero.

This issue has been automatically marked as stale because it has not
had recent activity. It will be closed if no further activity occurs.

This issue has not seen any activity since it was marked stale.
Closing.

The probe would roughly be as follows: create a new netns, add a route in there, assign a BPF prog to the interface in the netns which does a fib lookup, ensure the neighbor resolution of the fib lookup fails but the route lookup succeeds and finally test whether the fib_params->ifindex output is non-zero while the input was zero.

@borkmann Would there be a way to test this using prog_run that doesn't involve sending a packet? Our netns tooling isn't great at the moment, it still shells out to ip2 and I'd like to avoid that in new code. Reworking it first will take time and will be annoying to backport.

Triggering a prog by sending a packet is going to be error-prone, and we'd need to write the retcode to a map instead of receiving it from prog_run.

Maybe we can find something that works from the hostns? I understand we need to induce a failed fib lookup and a successful route lookup on the same ifindex? If we only need to read out fib_params->ifindex after the call, why do we need the route lookup?

The probe would roughly be as follows: create a new netns, add a route in there, assign a BPF prog to the interface in the netns which does a fib lookup, ensure the neighbor resolution of the fib lookup fails but the route lookup succeeds and finally test whether the fib_params->ifindex output is non-zero while the input was zero.

@borkmann Would there be a way to test this using prog_run that doesn't involve sending a packet? Our netns tooling isn't great at the moment, it still shells out to ip2 and I'd like to avoid that in new code. Reworking it first will take time and will be annoying to backport.

I would hope we can do without sending a packet. Just calling bpf_fib_lookup() with a bpf_fib_lookup struct that matches the route setup in the netns.

Triggering a prog by sending a packet is going to be error-prone, and we'd need to write the retcode to a map instead of receiving it from prog_run.

Maybe we can find something that works from the hostns? I understand we need to induce a failed fib lookup and a successful route lookup on the same ifindex? If we only need to read out fib_params->ifindex after the call, why do we need the route lookup?

We basically need to control that the routing succeeds, but the kernel can't provide a L2 resolution for the next-hop. Controlling that from hostns would be difficult I believe.

Team,

I've been looking into this issue as my first contrib. I think the probe is almost done here (still need to check ret value of lookup to make sure it fails). It's follows a similar approach to what Paul did in another probe.

On this:

ensure the neighbor resolution of the fib lookup fails but the route lookup succeeds and finally test whether the fib_params->ifindex output is non-zero while the input was zero.

I think ifindex can't be 0 (see). The probe needs to create a tap iface or something, and inject the pkt from a valid ifindex (e.g. ifindex=lo) and check that the call returns the params with ifindex=tap.

Let me know if my understanding is correct, or I am missing s/t.

I think ifindex can't be 0 (see). The probe needs to create a tap iface or something, and inject the pkt from a valid ifindex (e.g. ifindex=lo) and check that the call returns the params with ifindex=tap.

Ack, I think that's correct. The bpf_fib_lookup struct we pass in must provide a valid ifindex. So the check needs to be whether the ifindex field is updated after the failed FIB lookup.