lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 29 May 2019 21:29:22 -0600
From:   David Ahern <>
To:     George Wilkie <>
Cc:     Shrijeet Mukherjee <>,
        "David S. Miller" <>,
        Alexey Kuznetsov <>,
        Hideaki YOSHIFUJI <>,
Subject: Re: [PATCH net-next] vrf: local route leaking

On 5/27/19 2:34 AM, George Wilkie wrote:
> On Sat, May 25, 2019 at 09:13:13AM -0600, David Ahern wrote:
>>> Using a loopback doesn't work, e.g. if was on a global interface:
>>>    ip ro add vrf vrf-a 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.
>> 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 |---+
      +------+                  +------+

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
 ip li set veth1 vrf vrf-b up
 ip -netns foo li set veth11 up
 ip -netns foo addr add dev veth11
 ip -netns foo ro add via

 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
 ip -netns bar li set veth12 up
 ip -netns bar addr add dev veth12

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 dev xvrf2
 ip ro add 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
 ip li set xvrf2 master vrf-b up
 ip addr add dev xvrf2

 ip ro add vrf vrf-b via dev xvrf2
 ip ro add via 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.

Powered by blists - more mailing lists