Why I'm switching to systemd's networkd stuff for my networking

January 21, 2015

Today I gave in to temptation and switched my Fedora 21 office workstation from doing networking through Fedora's old /etc/rc.d/init.d/network init script and its /etc/sysconfig/network-scripts/ifcfg-* system to using systemd-networkd. Before I write about what you have to set up to do this, I want to ramble a bit about why I even thought about it, much less went ahead.

The proximate cause is that I was hoping to get a faster system boot. At some point in the past few Fedora versions, bringing up my machine's networking through the network init script became the single slowest part of booting by a large margin, taking on the order of 20 to 30 seconds (and stalling a number of downstream startup jobs). I had no idea just what was taking so long, but I hoped that by switching to something else I could improve the situation.

The deeper cause is that Fedora's old network init script system is a serious mess. All of the work is done by a massive set of intricate shell scripts that use relatively undocumented environment variables set in ifcfg-* files (and the naming of the files themselves). Given the pile of scripts involved, it's absolutely no surprise to me that it takes forever to grind through processing all of my setup. In general the whole thing has all of the baroque charm of the evolved forms of System V init; the best thing I can say about it is that it generally works and you can build relatively sophisticated static setups with it.

(While there is some documentation for what variables can be set hiding in /usr/share/doc/initscripts/sysconfig.txt, it's not complete and for some things you get to decode the shell scripts yourself.)

What systemd's networkd stuff brings to the table for this is the same thing that systemd brings to the table relative to SysV init scripts: you have a well documented way of specifying what you want, which is then directly handled instead of being run through many, many layers of shell scripts. As an additional benefit it gets handled faster and perhaps better.

(I firmly believe that a mess of fragile shell scripts that source your ifcfg-* files and do magic things is not the right architecture. Robust handling of configuration files requires real parsing and so on, not shell script hackery. I don't really care who takes care of this (I would be just as happy with a completely separate system) and I will say straight up that systemd-networkd is not my favorite implementation of this idea and suffers from various flaws. But I like it more than the other options.)

In theory NetworkManager might fill this ecological niche already. In practice NetworkManager has never felt like something that was oriented towards my environment, instead feeling like it targeted machines and people who were going to do all of this through GUIs, and I've run into some issues with it. In particular I'm pretty sure that I'd struggle quite a bit to find documentation on how to set up a NM configuration (from the command line or in files) that duplicates my current network setup; with systemd, it was all in the manual pages. There is a serious (re)assurance value from seeing what you want to configure be clearly documented.

(My longer range reason for liking systemd's move here is that it may bring more uniformity to how you configure networking setups across various Linux flavours.)

Comments on this page:

By Albert at 2015-01-21 04:28:13:

I'm pretty sure I saw an ifcfg man page some time in the past where all the variables used in the ifcfg-* files were documented (similarly there were ifcfg-bridge, ifcfg-vlan etc. man pages to document extra variables used for those types of interfaces). Google does confirm that they exist, however I can't find them in any of the redhat/fedora/centos systems I have access to.

By Garth at 2015-06-25 16:34:47:

A quick question on networkd - does it support policy routing and associated custom route tables?

Currently having all sorts of grief using ifcfg- files with Fedora 22 Server, and seeing your posts has prompted me to start thinking of the switch to networkd - IFF it supports policy routing and multiple custom routing tables.


By cks at 2015-06-25 16:51:52:

Networkd doesn't seem to have any support for policy routing and the things you need to support it. In my setup I deal with this by having my 'set everything up' systemd .service (which runs some scripts to do all the work) specify that it is run after systemd-networkd-wait-online.service. This is not perfect (although it works for me) and it definitely wouldn't cope with a dynamic situation where devices are coming and going and you need to reconfigure things as they do.

It's unfortunate that as far as I know you can't get networkd to easily notify you of networking changes in a way that you can react to. It probably emits DBus notifications about things, but I don't think there's anything beyond that.

(I imagine the systemd people will fix this someday but that they also consider it out of scope for the early iterations of networkd. Possibly they feel that that sort of sophistication actually belongs in NetworkManager, at which point you have other problems.)

By Anon at 2016-09-29 02:14:43:

You can get systemd to run a program each time the networking is modified (but be aware this happens every time a DHCP lease is renewed) by using a path activated service as hinted at by https://www.joachim-breitner.de/blog/664-Switching_to_systemd-networkd#comment_1 .

Written on 21 January 2015.
« A gotcha with Python tuples
How to set up static networking with systemd-networkd, or at least how I did »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Jan 21 02:08:42 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.