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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 27 May 2019 09:34:02 +0100
From:   George Wilkie <>
To:     David Ahern <>
Cc:     Shrijeet Mukherjee <>,
        "David S. Miller" <>,
        Alexey Kuznetsov <>,
        Hideaki YOSHIFUJI <>,
Subject: Re: [PATCH net-next] vrf: local route leaking

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'

Powered by blists - more mailing lists