On Tue, Jun 9, 2015, at 14:30, Nicolas Dichtel wrote: > 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.
Agreed, the idea is to have a prctl in the end which gets inherited by fork. current->rt_table_id or some kind of vrf specifier in task_struct would make that possible then. A helper tool like ip route exec table 100 /bin/bash would then start a session bound to a specific routing instance. Bye, Hannes -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
