Re: [RFC PATCH 00/29] net: VRF support

Le 06/02/2015 22:22, Eric W. Biederman a écrit :

Having looked at this problem, I am currently convinced that network
namespaces can be improved to the point where they can reasonably
act as VRFS.

We are using netns this way at 6WIND.

Further I think code maintenance argues that this VRF proposal is a bad
direction to go.

David Ahern [off-list ref] writes:

quoted

On 2/5/15 9:14 PM, Eric W. Biederman wrote:

quoted

David Ahern [off-list ref] writes:

quoted

On 2/5/15 6:33 PM, Stephen Hemminger wrote:

quoted

It is still not clear how adding another level of abstraction
solves the scaling problem. Is it just because you can have one application
connect to multiple VRF's? so you don't need  N routing daemons?

quoted

quoted

quoted

All of those options are rather heavyweight and the number of 'things' is linear
with the number of VRFs. When multiplied by the number of services needed for a
full-featured product the end result is a lot of wasted resources.

If all you want is a single listening socket there are other
implementation possibilities that are focused on solving just that
problem, and would be much more generally applicable.

These are examples of the higher level problem -- the current need for
replicating processes/threads/sockets per namespace, not to mention the memory
consumed by the creation of the namespace itself which is fairly high. i.e., The
problem is more than just a listening socket of a single process.

Sometimes replication is simpler and more efficient, so I do not believe
this is a fundamental design problem.

That said.  Having N listening sockets is arguably a mis-feature of the
berkely sockets layer, and is fixable by adding support for adding
features for listening sockets to listen on more than one address.  So
by adding an feature to teach a listening socket how to listen on
additional addresses that is fixable.  SCTP and MPTCP have even done
some work in that area, so it may just be a matter of generalizing
earlier solutions.  More likely we would want to build on Nicolas
Dichtels work on adding ids to other network namespaces and have
our VRF any sockets listen on any network namespace that we an for.

I agree, it would be great to have this kind of feature. Any help to
achieve it is welcomed :)

Similarly we can build on Nicolas Dichtel's work of implementing in
kernel ids for other network namespaces to provide proc files or
netlink messages that report on multiple network namespaces at once.
Assuming of course that such interfaces are shown to be worth
implementing.

Same here. At least, we should have a try to have a status or to see which
problems can block.

I believe that with small focused changes we can make the existing
userspace API efficient to work with for programs that want to work
with multiple network namespaces (or VRFs) at once.

Yes, some work remains into this area.


Regards,
Nicolas