On 10/7/22 18:47, Mike Manning wrote:

Hi Maximilien,

Apologies that you have now hit this issue. Further to David's reply
with the link for the rationale behind the change, the bisected commit
you found restores backwards compatibility with the 4.19 kernel to allow
a match on an unbound socket when in a VRF if tcp_l3mdev_accept=1, the
absence of this causing issues for others. Isolation between default and
other VRFs as introduced by the team I worked for back in 2018 and
introduced in 5.x kernels remains guaranteed if tcp_l3mdev_accept=0.

There is no appetite so far to introduce yet another kernel parameter to
control this specific behavior, see e.g.
https://lore.kernel.org/netdev/f174108c-67c5-3bb6-d558-7e02de701ee2@gmail.com/ (local)

Ok, I do understand it's tricky to satisfy both side and adding a 
parameter for each cases is probably not sustainable ^^'

Is there any possibility that you could use tcp_l3mdev_accept=0 by
running any services needed in the VRF with 'ip vrf exec <vrf> <cmd>'?

Yes, we will try to do that, there was some complication but it's 
probably easier and better for the future.

Is the problem specific to using NAT for eth2 in the VRF, i.e. have you
tried on another interface in that VRF, or on eth2 without NAT config?

If we try to NAT on another interface in the VRF it doesn't work. 
Without NAT it does work.

No doubt you are doing this, but can I also check that your VRF config
is correct according to
https://www.kernel.org/doc/Documentation/networking/vrf.txt , so
reducing the local lookup preference, etc., e.g.

Yes, rules/preferences are correct - I think by ifupdown2 during 
interface activation.

So we will try to not to have to use tcp_l3mdev_accept=1 to make it 
working as expected.

Thanks for you help and have a nice day :)

-- 
Maximilien Cuony