On 5/27/19 2:34 AM, George Wilkie wrote:

On Sat, May 25, 2019 at 09:13:13AM -0600, David Ahern wrote:

quoted

quoted

Using a loopback doesn't work, e.g. if 10.1.1.0/24 was on a global interface:
   ip ro add vrf vrf-a 10.1.1.0/24 dev lo

That works for MPLS when you exit the LSP and deliver locally, so it
should work here as well. I'll take a look early next week.

OK, thanks.

quoted

I would prefer to avoid it if possible. VRF route leaking for forwarding
does not have the second lookup and that is the primary use case. VRL
with local delivery is a 1-off use case and you could just easily argue
that the connection should not rely on the leaked route. ie., the
control plane is aware of both VRFs, and the userspace process could use
the VRF-B path.

Although it isn't always possible to change the userspace process -
may be running in a specific vrf by 'ip vrf exec'

sure, but that is a design choice for the control plane. Effectively,
you have this setup:

    { process }
         |
         |  packet
         |
  +--------------+          +--------------+
  |     VRF A    |          |     VRF B    |
  |              |          |              |
  |              |     <------ route to A  |
  |   +------+   |          |   +------+   |
  +---| ens1 |---+          +---| ens2 |---+
      +------+                  +------+
                                    ^
                                    |
                                    |
                                 packet

ie., the process is potentially bound to VRF-A, and you want it handle
packets from VRF-B and without binding to VRF-B.

I already mentioned one solution that works well if the route is only
used for forwarding (add a route to VRF-B using ens1 as the egress
device) and a solution that works for local delivery (add route to VRF-B
using vrf-A device to do a second lookup).

you are correct that use of loopback here for default VRF does not work
-- the lookup code gets confused because it is a forward path (as
opposed to MPLS which is a local input). I found a couple of solutions
that work for default VRF.

Again, using namespaces to demonstrate within a single node. This is the
base setup:

 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.200.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.200.1.11/24
 ip -netns foo ro add 10.200.2.0/24 via 10.200.1.1

 ip netns add bar
 ip li add veth2 type veth peer name veth12 netns bar
 ip li set veth2 up
 ip addr add dev veth2 10.200.2.1/24
 ip -netns bar li set veth12 up
 ip -netns bar addr add dev veth12 10.200.2.12/24

Cross VRF routing can be done with a veth pair, without addresses:

 ip li add xvrf1 type veth peer name xvrf2
 ip li set xvrf1 up
 ip li set xvrf2 master vrf-b up

 ip ro add vrf vrf-b 10.200.2.0/24 dev xvrf2
 ip ro add 10.200.1.0/24 dev vrf-b

or with addresses:

 ip li add xvrf1 type veth peer name xvrf2
 ip li set xvrf1 up
 ip addr add dev xvrf1 10.200.3.1/30
 ip li set xvrf2 master vrf-b up
 ip addr add dev xvrf2 10.200.3.2/30

 ip ro add vrf vrf-b 10.200.2.0/24 via 10.200.3.1 dev xvrf2
 ip ro add 10.200.1.0/24 via 10.200.3.2 dev xvrf1

Yes, this does have a double FIB lookup - one in VRF-B and again in
VRF-A, but I contend this is a design choice. Bind the process to VRF-B
and it works with 1 lookup.