Network namespaces management

Pyroute2 provides basic namespaces management support. The netns module contains several tools for that.

Please be aware, that in order to run system calls the library uses ctypes module. It can fail on platforms where SELinux is enforced. If the Python interpreter, loading this module, dumps the core, one can check the SELinux state with getenforce command.

pyroute2.netns.create(netns, libc=None)

Create a network namespace.

pyroute2.netns.listnetns()

List available network namespaces.

pyroute2.netns.remove(netns, libc=None)

Remove a network namespace.

pyroute2.netns.setns(netns, flags=64, libc=None)

Set netns for the current process.

The flags semantics is the same as for the open(2) call:

  • O_CREAT – create netns, if doesn’t exist
  • O_CREAT | O_EXCL – create only if doesn’t exist

NetNS

A NetNS object is IPRoute-like. It runs in the main network namespace, but also creates a proxy process running in the required netns. All the netlink requests are done via that proxy process.

NetNS supports standard IPRoute API, so can be used instead of IPRoute, e.g., in IPDB:

# start the main network settings database:
ipdb_main = IPDB()
# start the same for a netns:
ipdb_test = IPDB(nl=NetNS('test'))

# create VETH
ipdb_main.create(ifname='v0p0', kind='veth', peer='v0p1').commit()

# move peer VETH into the netns
with ipdb_main.interfaces.v0p1 as veth:
    veth.net_ns_fd = 'test'

# please keep in mind, that netns move clears all the settings
# on a VETH interface pair, so one should run netns assignment
# as a separate operation only

# assign addresses
# please notice, that `v0p1` is already in the `test` netns,
# so should be accessed via `ipdb_test`
with ipdb_main.interfaces.v0p0 as veth:
    veth.add_ip('172.16.200.1/24')
    veth.up()
with ipdb_test.interfaces.v0p1 as veth:
    veth.add_ip('172.16.200.2/24')
    veth.up()

Please review also the test code, under tests/test_netns.py for more examples.

By default, NetNS creates requested netns, if it doesn’t exist, or uses existing one. To control this behaviour, one can use flags as for open(2) system call:

# create a new netns or fail, if it already exists
netns = NetNS('test', flags=os.O_CREAT | os.O_EXIST)

# create a new netns or use existing one
netns = NetNS('test', flags=os.O_CREAT)

# the same as above, the default behaviour
netns = NetNS('test')

To remove a network namespace:

from pyroute2 import NetNS
netns = NetNS('test')
netns.close()
netns.remove()

One should stop it first with close(), and only after that run remove().

class pyroute2.netns.nslink.NetNS(netns, flags=64)

NetNS is the IPRoute API with network namespace support.

Why not IPRoute?

The task to run netlink commands in some network namespace, being in another network namespace, requires the architecture, that differs too much from a simple Netlink socket.

NetNS starts a proxy process in a network namespace and uses multiprocessing communication channels between the main and the proxy processes to route all recv() and sendto() requests/responses.

Any specific API calls?

Nope. NetNS supports all the same, that IPRoute does, in the same way. It provides full socket-compatible API and can be used in poll/select as well.

The only difference is the close() call. In the case of NetNS it is mandatory to close the socket before exit.

NetNS and IPDB

It is possible to run IPDB with NetNS:

from pyroute2 import NetNS
from pyroute2 import IPDB

ip = IPDB(nl=NetNS('somenetns'))
...
ip.release()

Do not forget to call release() when the work is done. It will shut down NetNS instance as well.

remove()

Try to remove this network namespace from the system.

pyroute2.netns.nslink.NetNServer(netns, rcvch, cmdch, flags=64)

The netns server supposed to be started automatically by NetNS. It has two communication channels: one simplex to forward incoming netlink packets, rcvch, and other synchronous duplex to get commands and send back responses, cmdch.

Channels should support standard socket API, should be compatible with poll/select and should be able to transparently pickle objects. NetNS uses multiprocessing.Pipe for this purpose, but it can be any other implementation with compatible API.

The first parameter, netns, is a netns name. Depending on the flags, the netns can be created automatically. The flags semantics is exactly the same as for open(2) system call.

...

The server workflow is simple. The startup sequence:

1. Create or open a netns.

2. Start `IPRoute` instance. It will be used only on the low level,
   the `IPRoute` will not parse any packet.

3. Start poll/select loop on `cmdch` and `IPRoute`.

On the startup, the server sends via cmdch the status packet. It can be None if all is OK, or some exception.

Further data handling, depending on the channel, server side:

1. `IPRoute`: read an incoming netlink packet and send it unmodified
   to the peer via `rcvch`. The peer, polling `rcvch`, can handle
   the packet on its side.

2. `cmdch`: read tuple (cmd, argv, kwarg). If the `cmd` starts with
   "send", then take `argv[0]` as a packet buffer, treat it as one
   netlink packet and substitute PID field (offset 12, uint32) with
   its own. Strictly speaking, it is not mandatory for modern netlink
   implementations, but it is required by the protocol standard.

NSPopen

The NSPopen class has nothing to do with netlink at all, but it is required to have a reasonable network namespace support.

class pyroute2.netns.process.proxy.NSPopen(nsname, *argv, **kwarg)

A proxy class to run Popen() object in some network namespace.

Sample to run ip ad command in nsname network namespace:

nsp = NSPopen('nsname', ['ip', 'ad'], stdout=subprocess.PIPE)
print(nsp.communicate())
nsp.wait()
nsp.release()

The only difference in the release() call. It explicitly ends the proxy process and releases all the resources.

release()

Explicitly stop the proxy process and release all the resources. The NSPopen object can not be used after the release() call.

Table Of Contents

Previous topic

IPDB module

Next topic

Modules in progress

This Page