Re: [RFC net-next 0/3] Proposal for VRF-lite

[Nicolas Dichtel <nicolas.dichtel@6wind.com>]

Le 09/06/2015 12:15, Thomas Graf a écrit :
> On 06/08/15 at 11:35am, Shrijeet Mukherjee wrote:
> [...]
>> model with some performance paths that need optimization. (Specifically
>> the output route selector that Roopa, Robert, Thomas and EricB are
>> currently discussing on the MPLS thread)
>
> Thanks for posting these patches just in time. This explains how
> you intent to deploy Roopa's patches in a scalable manner.
>
>> High Level points
>>
>> 1. Simple overlay driver (minimal changes to current stack)
>>     * uses the existing fib tables and fib rules infrastructure
>> 2. Modelled closely after the ipvlan driver
>> 3. Uses current API and infrastructure.
>>     * Applications can use SO_BINDTODEVICE or cmsg device indentifiers
>>       to pick VRF (ping, traceroute just work)
>
> I like the aspect of reusing existing user interfaces. We might
> need to introduce a more fine grained capability than CAP_NET_RAW
> to give containers the privileges to bind to a VRF without
> allowing them to inject raw frames.
>
> Given I understand this correctly: If my intent was to run a
> process in multiple VRFs, then I would need to run that process
> in the host network namespace which contains the VRF devices
> which would also contain the physical devices. While I might want
> to grant my process the ability to bind to VRFs, I may not want
> to give it the privileges to bind to any device. So we could
> consider introducing CAP_NET_VRF which would allow to bind to
> VRF devices.

If I understand correctly, all existing applications should also be modified
if I want to run them into a VRF/MRF (see my previous email)?

ssh, dhcp, httpd, etc should be runnable per MRF without modifications of
their source code. So, it becomes a netns. What's about an IKE dameon?

It makes sense to have both: netns and MRF ; each can have their own logics
of VRF-like behavior depending on how a VRF is defined by the end users.