On 5/24/19 2:05 AM, George Wilkie wrote: > If have an interface in vrf A: > > 10.10.2.0/24 dev ens9 proto kernel scope link src 10.10.2.2 > local 10.10.2.2 dev ens9 proto kernel scope host src 10.10.2.2 > > and want to leak it into vrf B, it is not sufficient to leak just > the interface route: > > ip route add 10.10.2.0/24 vrf B dev ens9 > > as traffic arriving into vrf B that is destined for 10.10.2.2 will > not arrive - it will be sent to the ens9 interface and nobody will > respond to the ARP. > > In order to handle the traffic locally, the local route must also > be leaked to vrf B: > > ip route add local 10.10.2.2 vrf B dev ens9 > > However, that still doesn't work as the traffic is processed in > the context of the input vrf B and does not find a socket that is > bound to the destination vrf A.
I presume you mean traffic arrives on another interface assigned to VRF B with the final destination being the local address of ens9 in VRF-A. I think this codifies the use case: ip li add vrf-a up type vrf table 1 ip route add vrf vrf-a unreachable default ip li add vrf-b up type vrf table 2 ip route add vrf vrf-b unreachable default ip ru add pref 32765 from all lookup local ip ru del pref 0 ip netns add foo ip li add veth1 type veth peer name veth11 netns foo ip addr add dev veth1 10.1.1.1/24 ip li set veth1 vrf vrf-b up ip -netns foo li set veth11 up ip -netns foo addr add dev veth11 10.1.1.11/24 ip -netns foo ro add 10.1.2.0/24 via 10.1.1.1 ip netns add bar ip li add veth2 type veth peer name veth12 netns bar ip li set veth2 vrf vrf-a up ip addr add dev veth2 10.1.2.1/24 ip -netns bar li set veth12 up ip -netns bar addr add dev veth12 10.1.2.12/24 If you do route leaking this way: ip ro add vrf vrf-b 10.1.2.0/24 dev veth2 ip ro add vrf vrf-a 10.1.1.0/24 dev veth1 yes, you hit problems trying to connect to a local address. If you do route leaking this way: ip ro add vrf vrf-b 10.1.2.0/24 dev vrf-a ip ro add vrf vrf-a 10.1.1.0/24 dev vrf-b you do not.
