Re: [PATCH 0/6] netns: add linux-vrf features via network namespaces

[ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)]

Vivien Chappelier <vivien.chappelier-L+G57L1VLRbR7s880joybQ@public.gmane.org> writes:

> To bring back the discussion you had with Eric W. Biederman, it seems to 
> me that the only real issue is on the addition of the global nsid index 
> that is not really fit to be used hierarchically. However, I don't 
> understand why having both this global nsid interface and the pid 
> interface would hurt, as the goals of isolation and VRF-like support are 
> really separate.

A global nsid breaks migration, it breaks nested containers, in general it
just hurts.  So it is a bad choice for an interface.

Personally if I have vrf I want to set up a test environment in a container so
I can isolate it from the rest of the system.   Allowing me to play with the
user space side of the functionality without  So these things are not completely
separate concerns.

So from a design point of view I see the following questions.
1) How do we pin a network namespace to allow for routing when no process uses it?
2) How do we create sockets into that pinned network namespace?
3) How do we enter that network namespace so that sockets by default are created in it?

All of these are technically easy things to implement and design wise a challenge.

The best solution I see at the moment is to have something (a fs) we can mount in
the filesystem, keeping the network namespace alive as long as it is mounted.

i.e
mount -t netns none /dev/nets/1
mount -t netns -o newinstance none /dev/nets/2

(The new instance parameter creates the network namespace as well as capturing the
 current one)

char netns[] = "/dev/nets/2"
fd = socket();
err = setsockopt(fd, SOL_SOCKET, SO_NETPATH, netns, strlen(netns) + 1);

Eric