Re: RFC: Network namespaces in NM



On 20.02.2016 00:39, Thomas Haller wrote:
On Thu, 2016-02-04 at 12:21 +0100, Stjepan Groš wrote:
Hi!

Is anyone working on network namespaces support in NetworkManager? Or
was thinking what is a "proper way" of implementing them?

I'm experimenting with adding support to NM and what I implemented so
far is:

1. Added objects NMNetnsController which would control all network
namespaces managed by NM.

2. Each network namespace is represented with an object NMNetns and
exposed on DBus. There are no methods so far but only a property name
which contains network namespace's name on the filesystem.

3. NMNetnsController exposes object NetworkNamespacesController with
methods AddNetworkNamepace and ListNetworkNamespaces. The first one
take a name as an argument and creates a new (iproute2 compatible)
network namespace, while the second one provides a list of existing
namespaces.

4. When new network namespace is created (using  AddNetworkNamepace
method) a new, private, platform layer is instantiated and loopback
interface within namespace activated. Note that new platform layer
has to be created because once a socket is opened in one network
namespace it is bound to the given namespace no matter which
namespace is active so current singleton object wouldn't work without
heavy refactoring!

What I intend to do next is:

1. NM has to monitor devices/IP addresses in new network namespaces
properly.

2. Methods that would allow an IPv4 or IPv6 address to be assigned in
some network namespace.

All the code is here:

https://github.com/sgros/MIF_NetworkManager

and since this is PoC, there are A LOT OF BUGS AND MISSING FEATURES.

So, what do you think? Any comments, suggestions, critiques, etc?

SG

P.S. To be able to run patched NM you also need patched libndp
library available here:

https://github.com/sgros/MIF_libndp
Hi Sjepan,


I think adding namespace support to platform needs to be more
elaborate. There is also udev, ethtool, sysctl, which must be
considered and the NMPlatform instance must transparently switch
namespace as needed.

I did that here:
https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=th/platform-netns

I agree that it should be a bit more thought out. That's the reason I still consider my approach to be experimental.

If I got it right, you made NMPlatform object network namespace aware and you still have a single NMPlatform object (singleton)? Where do you intend to introduce management of network namespaces, e.g. where will you create/delete them?

I took a bit different approach. There is still "main" NMPlatform object but I added new NMPlatform object per network namespace (as well as NMDefaultRouteManager and NMRouteManager objects). The idea is that "main" NMPlatform object takes care of stuff common to each network namespace. Additionally, NMNetnsController is a new singleton object that takes care of managing network namespaces and each network namespace is represented/managed by NMNetns object. The exception is the root (main) network namespace that is still managed by NMManager object and has a "phony" NMNetns object. Maybe at some point parts of NMManager should move to NMNetns (or vice versa), but now it is so.

What works now is:

1. I can create/delete/list network namespaces (via NMNetnsController object).
2. Each network namespace is represented by NMNetns which tracks device changes in its network namespace (adding/removing device), and also tracks addresses on devices and routes.

I also added a method to NMNetns object that allows device to be moved to some other network namespace. But I'm not satisfied with it. One big reason is the root network namespace that is not represented by NMNetns object and thus there is no way to move device from root network namespace to another one.

What I'm trying to do now is to add a boolean option "netns-isolate" to each setting which will cause new network namespace to be created when this setting is activated and then device to be moved into this network namespace.

SG


Thomas

Attachment: signature.asc
Description: OpenPGP digital signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]