Re: VRF Issue Since kernel 5

[David Ahern <dsahern@gmail.com>]

On 4/1/20 2:35 PM, Maximilian Bosch wrote:
> Hi!
> 
>> This should work:
>>     make -C tools/testing/selftests/net nettest
>>     PATH=$PWD/tools/testing/selftests/net:$PATH
>>     tools/testing/selftests/net/fcnal-test.sh
> 
> Thanks, will try this out later.
> 
>> If you want that ssh connection to work over a VRF you either need to
>> set the shell context:
>>     ip vrf exec <NAME> su - $USER
>>
> 
> Yes, using `ip vrf exec` is basically my current workaround.

that's not a workaround, it's a requirement. With VRF configured all
addresses are relative to the L3 domain. When trying to connect to a
remote host, the VRF needs to be given.

> 
>> or add 'ip vrf exec' before the ssh. If it is an incoming connection to
>> a server the ssh server either needs to be bound to the VRF or you need
>> 'net.ipv4.tcp_l3mdev_accept = 1'
> 
> Does this mean that the `*l3mdev_accept`-parameters only "fix" this
> issue if the VRF is on the server I connect to?

server side setting only.

> 
> In my case the VRF is on my local machine and I try to connect through
> the VRF to the server.
> 
>> The tcp reset suggests you are doing an outbound connection but the
>> lookup for what must be the SYN-ACK is not finding the local socket -
>> and that is because of the missing 'ip vrf exec' above.
> 
> I only experience this behavior on a 5.x kernel, not on e.g. 4.19
> though. I may be wrong, but isn't this a breaking change for userspace
> applications in the end?

I do not see how this worked on 4.19. My comment above is a fundamental
property of VRF and has been needed since day 1. That's why 'ip vrf
exec' exists.