Netns management overview — pyroute2 0.4.19 documentation

# Netns management overview

Pyroute2 provides basic namespaces management support. Here’s a quick overview of typical netns tasks and related pyroute2 tools.

## Move an interface to a namespace

Though this task is managed not via netns module, it should be mentioned here as well. To move an interface to a netns, one should provide IFLA_NET_NS_FD nla in a set link RTNL request. The nla is an open FD number, that refers to already created netns. The pyroute2 library provides also a possibility to specify not a FD number, but a netns name as a string. In that case the library will try to lookup the corresponding netns in the standard location.

Create veth and move the peer to a netns with IPRoute:

    from pyroute2 import IPRoute
    ipr = IPRoute()
    ipr.link('add', ifname='v0p0', kind='veth', peer='v0p1')
    idx = ipr.link_lookup(ifname='v0p1')[0]
    ipr.link('set', index=idx, net_ns_fd='netns_name')

Create veth and move the peer to a netns with IPDB:

    from pyroute2 import IPDB
    ipdb = IPDB()
    ipdb.create(ifname='v0p0', kind='veth', peer='v0p1').commit()
    with ipdb.interfaces.v0p1 as i:
        i.net_ns_fd = 'netns_name'

## Manage interfaces within a netns

This task can be done with NetNS objects. A NetNS object spawns a child and runs it within a netns, providing the same API as IPRoute does:

    from pyroute2 import NetNS
    ns = NetNS('netns_name')
    # do some stuff within the netns
    ns.close()

One can even start IPDB on the top of NetNS:

    from pyroute2 import NetNS
    from pyroute2 import IPDB
    ipdb = IPDB(nl=NetNS('netns_name'))
    # do some stuff within the netns
    ipdb.release()

## Spawn a process within a netns

For that purpose one can use NSPopen API. It works just as normal Popen, but starts a process within a netns.

## List, set, create and remove netns

These functions are described below. To use them, import netns module:

    from pyroute2 import netns
    netns.listnetns()

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`(nspath=None)

  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, cmdch, brdch, 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 NSPopen class was intended to be a drop-in replacement for the Popen class, but there are still some important differences.

  The NSPopen object implicitly spawns a child python process to be run in the background in a network namespace. The target process specified as the argument of the NSPopen will be started in its turn from this child. Thus all the fd numbers of the running NSPopen object are meaningless in the context of the main process. Trying to operate on them, one will get ‘Bad file descriptor’ in the best case or a system call working on a wrong file descriptor in the worst case. A possible solution would be to transfer file descriptors between the NSPopen object and the main process, but it is not implemented yet.

  The process’ diagram for NSPopen(‘test’, [‘ip’, ‘ad’]):

      +---------------------+     +--------------+     +------------+
      | main python process |<--->| child python |<--->| netns test |
      | NSPopen()           |     | Popen()      |     | $ ip ad    |
      +---------------------+     +--------------+     +------------+

  As a workaround for the issue with file descriptors, some additional methods are available on file objects stdin, stdout and stderr. E.g., one can run fcntl calls:

      from fcntl import F_GETFL
      from pyroute2 import NSPopen
      from subprocess import PIPE

      proc = NSPopen('test', ['my_program'], stdout=PIPE)
      flags = proc.stdout.fcntl(F_GETFL)

  In that way one can use fcntl(), ioctl(), flock() and lockf() calls.

  Another additional method is release(), which can be used to explicitly stop the proxy process and release 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.