Linux Containers - Network Namespace

• Patchset
• Configuration
• Performances
• Tools
• Status

Description

The network namespace is a private set of network resources assigned to one or several processes. These have their own set of network devices, IP addresses, routes, sockets and so on ... Other processes outside of the namespace cannot access these network resources, neither know they exist.

• virtualization : the processes inside the network namespaces do not know anything about the network resources outside the namespace and use the resources without conflicting with other network namespaces.
  For examples:
  • several network namespaces can have eth0 and lo network devices.
  • several apache servers listening on *:80 can be launched into differents network namespaces.
• isolation : the processes cannot access to the network resources which are outside the namespace.
  For examples:
  • a process cannot sniff traffic related to another network namespace.
  • a process cannot shutdown an interface belonging to another network namespace.

• security : a server can be ran into a network namespace and this one will ensure, if the server is hacked, the rest of network system will not be compromised
• resource management : the resources management acting at the network device can be easily implemented because the network resources can be assigned to a specific set of processes
• traffic control : is more flexible because it can be set by network devices and obviously by network namespaces
• consolidation : a powerful host can aggregate several servers in different network namespaces without impacting the servers' network configurations
• mobility : it is easy to find and checkpoint the network resources because they are by namespace. The virtualization allows to move IP accross the network and avoid conflicts at restart

Utilization

The usage is very simple. A new clone flags, CLONE_NEWNET, has been added to the kernel. This one can be used with the clone syscall or the unshare syscall. The last one is more flexible because it allows to create a new network namespace for the calling process. All the process children will inherit the network namespace from its parent.

You must have CAP_NET_ADMIN capability to create a new network namespace.

After a network namespace creation, only the loopback device exists and it is down. This one is a new instance of the loopback and you can no longer communicate via the initial loopback. That means if you need to do rpc call, you will need to launch rpcd and a new set of rpc servers.

In order to communicate with the outside world a network device is needed but all previous network devices views were lost due to the unshare call. To be able to use a network device, we need an access on it, so the network devices are moved accross the network namespaces. The moving is done with the following rule: "only the network namespace owner can move a network device". When a network device is moved, the source network namespace cannot access the network device anymore and the destination network namespace gains access to the network device. With the network namespace concept, the system at boot is the initial network namespace, so it is possible to move network devices from there to another network namespace. The network devices are released to the initial network namespace when the current network namespace dies.

Concerning sysfs, the device view /sys/class/net stays consistent with the network devices accessibility. More information about sysfs for network namespace can found here

The next step is to setup the network. You have several possibilities:

• if there are more than one NIC on the host, you can assign one to the newly created network namespace and so you have one physical network device, only usable and visible, into your network namespaces.
• the etun device was especially created to allow network communication between namespaces, it acts like the "pipe" but for the network. It is a pair network device: incoming and outgoing traffic received on one end go to the other end. The setup is done in two steps, create the pair devices, move one end to the network namespace. All the rest is usual network configuration.

Interface

Userspace tool

A very trivial userspace tool can be found here, it implements only the unshare mechanism. It is trivial to use, it will launch a command into a new network namespace if specified or will create a new network namespace in the current context otherwise.

The most usual usage is:

netunshare -- /bin/bash

Move network device accross namespaces

The api relies on the sysfs /sys/class/net. If you want to move a network device, you should have the network device name and the pid of the process running into a network namespace. The move can be done via a shell or using a C program with the libsysfs. The network device attribute "new_ns_pid" is used to store the pid which has a new network namespace. Let's pick an example : the system has two NICs, eth0 and eth1, and a process with pid 1234 does the unshare call. We want to move eth1 to the new network namespace.

We simply do:

echo 1234 > /sys/class/net/eth1/new_ns_pid

note : the loopback device __cannot__ be moved across network namespaces.

Pair device management

Creation

First ensure etun module is loaded. The pair device need the network devices names for each end. The api relies on the sysfs /sys/module/etun/parameters/newif. The creation can be done either via a shell script or a C program using libsysfs.

Let's pick an example again: we want to create a pair device with ends name, etun0 and etun1. To create it, we simply do:

echo etun0,etun1 > /sys/module/etun/parameters/newif

Destruction

The destruction is simply done using one of the two ends name. The destroy function will find the other end because they are linked.

echo etun0 > /sys/module/etun/parameters/delif

Configuration

Performances

A set of benchmarking has be done on the network namespace and can be found here.

Currently, the network namespace is not yet optimized. We found some hacks which were able to reduce the overhead by two and we are investigating how to fix that cleanly.

Some discussions about performances can be found here.

Patchset

Because the lxc website is related to containers, the lxc patchset is huge and brings a lot of features not related to the network. In order to focus on the network namespace and to have a patchset more easy to review, there is a patchset only related to the network namespace which is a subset of the lxc patchset. This one can be found here and it applies to the 2.6.20 kernel

Contacts