Linux Network Configuration

Tue 12 August 2014

This concerns the proliferation of netlink libraries and a lack of direction and documentation.

Background:

I've configured a router with netem (see Bandwidth Throttling with NetEM Network Emulation and netem example rules) to test Tieline devices under various delay and loss network conditions.

It's not really feasible for the tester to use 'tc' on the command line for the various tests, so my simple requirement is to build a little web interface. It's really easy to hack something together quickly (parsing the output of iproute2), but I've been developing a bit of an allergy for this kind of hacking things together.

I'd like to use a scripting language (Python or Perl, not C) for the webby stuff, so I started looking at what modules these languages provide for netlink, which seems like a better idea than parsing output of "tc" and "ip". I couldn't find anything that plays well with netem, but the python bindings for libnl seems to be closest to what I need.

This led me to look at the larger landscape for userspace netlink libraries...

Existing Netlink Libraries:

There are a few different userspace netlink "libraries", with somewhat different goals. The libnl documentation makes the distinction between the different subsystems clear in this diagram:

libnl netlink subsystem diagram

libnl:

seems to be aimed at general use,
includes Python bindings,
used by NetworkManager, libvirt, libpcap, etc.
decent documentation.

However, libnl is not the only netlink library in use.

libmnl:

available for general use.
used by nftables

libnetlink:

internal to iproute2, not for general use.

sd-rtnl:

internal to systemd-networkd, not for general use.

Network Configuration Managers

Lets look at this from another angle: what do the typical network managers / configuration applications use?

NetworkManager:

mature
maintained
uses libnl for direct netlink comms
C
provides DBus interface

Connmann:

maturity / maintenance concerns
C

Wicd:

unmaintained
Python
calls external tools like ifconfig
provides DBus interface

netctl Arch:

maintained
Bash
calls external tools like iproute2, etc.

netifd (OpenWRT):

active / maintained
C

systemd-networkd:

active / maintained
C
uses internal sd-rtnl

vyconfd:

maintenance concerns after vyatta sold to brocade.
Python
external iproute2, etc. tools?

LNST:

Python
external tools or NetworkManager via DBus

netcf:

tries to bridge distro-specific network config files with its own and provides a C library.
does not seem to modify the state directly.
seems to be used by virsh

ncfg:

does it, or will it matter?

I also fell down the rabbit warren of looking what the various SDN and router OS projects are doing - and I'm still recovering from the experience - so I'll write about that when I have a better understanding of it.

Back to solving the problem:

Remember that the initial problem was how to configure Netem.

Option 1: the quick and easy hack. This is what I ended up doing at work, for now, because it's that kind of place.

exec tc

Option 2:

Use a network manager with a dbus interface. Both NetworkManager and Wicd can do this.

Alternative 2:

Use libnl's python bindings.

Conclusion

Basically, many projects for network configuration have not progressed past shell scripting and iproute2 - some kind of lowest common denominator - and make a large effort to tie individual tools together into something with a semi-coherent interface. I believe there is a need for a good netlink library for one of the popular scripting languages, so that we can move past the old crufty shell scripts and parsing output of stand-alone tools.

On the other hand, many of these basic tools have implemented their own abstractions for using the netlink kernel interface. A Grand Unified Netlink Userspace certainly seems like it would be an improvement over the status quo, but each netlink library probably exists for good reason and a merger seems unlikely.

libnl seems like the natural choice for mere mortals. I'll post some examples as I learn more about it.