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

Eric W. Biederman ebiederm at xmission.com
Fri Oct 31 11:59:38 PDT 2008


Daniel Lezcano <dlezcano at fr.ibm.com> writes:

> Andreas B Aaen wrote:

>> Ok. Here is my use case.
>> I need a to talk to 500 IPv4 networks with possible overlapping IP
>> addresses. The packages arrive on 500 VLANs. I want one process to listen to a
>> port on each of these networks. I don't want 500 processes that runs in each
>> their network namespace and then communicate with each other through e.g. unix
>> sockets. This just complicates the task.
>
> Why don't you unshare 500 times in the same process ? In each namespace you
> create a socket control and the fd number is the identifier of your namespace.

That is the other good option I have thought of for doing this.
It is certainly a bit easier to implement.

There are problems with application restart.  So I am concerned with
how well use sockets as identifiers will scale.  But I don't have
any problems in principle.

There is a similar use case where simply have several disjoint domains
that you are performing software routing between and except for
configuration the kernel doesn't need any special support.

I do think just using unshare for the creation and not implementing
a newinstance filesystem option for now makes sense.  That way we can
support mounting of /proc/net and sysfs in those network namespaces
without having to teach them how to parse options as well.

Making the application creation loop something like:
for name in $(seq 1 500) ; do 
	unshare(CLONE_NEWNS);
	mkdir /dev/vrf/$name/proc
	mkdir /dev/vrf/$name/sys
	mkdir /dev/vrf/$name/handle
	mount -t netns none /dev/vrf/$name/handle
	mount -t proc/net none /dev/vrf/$name/proc
	mount -t sysfs none /dev/vrf/$name/sys
done

Eric


More information about the Containers mailing list