Shared publicly  - 
 
Networking in +systemd - udev

As explained in my previous post, I have been working on networking in systemd, and in particular I have introduced (wait for it...) systemd-networkd, or networkd among friends.

The first thing we settled on when deciding what networkd should do, was what it should not: networkd should not configure the really low-level settings of the network interfaces, that should be udev's job. The main reason for this is that some of these low-level settings (e.g. mac address and interface name) are not really supposed to be changing at run-time, so if we want to change them we better do that before any applications can see them (this assumes of course, that applications are well-behaved and only ever accesses network devices after getting an ADD event via libudev, but more on that later). Doing the low-level configuration in  udev is particularly important if we assume that not only networkd, but also other network managment daemons will be running on the system, it then makes sense to put this common, low-level functionality somewhere it applies equally to all.

So the first real functionality I added was to support for .link files to udev. Whenever a network device appears, udev will look for the first 'matching' .link file in /{etc,run,lib}/systemd/network and apply the settings described therein. We allow matching on a range of properties, such as device type, device path, mac address, driver, etc. If all the listed properties match a given device, the file is applied.

We currently support setting the interface name, or to specify a prioritized list of policies by which the name should be chosen. The default .link file uses this functionality to replace the udev rule implementing the predictable interface names, but it is now simpler (i.e., no udev rule hacking) to change the policy to be used, or to disable it altogether.

Similarly, we support setting the MAC address, or to specify one of two policies by which it should be set. These policies are not enabled by default, and probably only applies to two very narrow segments of users: people with extremely cheap/crappy hardware that doesn't come with a MAC address and tinfoilhat users. The first policy, 'random', will simply randomize the MAC address on every boot, so that if you move around a lot, it will be a bit harder to track you. The second policy, 'persistent', only does something if your hardware does not already contain a persistent MAC address (as all sane hardware should). In this case, we will generate a uniformly distributed, but predictable MAC address, which is guaranteed to be stable between reboots for any given device.

We can also set the MTU, the speed, duplex mode and wake-on-lan setting, assuming these are supported by the hardware.

Lastly, a few words about what this means for networking applications. Short version: nothing. Long version: Since time immemorial udev has had support for the NAME= key which allows the admin to configure the names of network interfaces. More recently, this was beefed up with a set of default policies which would assign predictable names to the network interfaces, guaranteed to be stable between reboots. This feature was much discussed, but the important message for people working with network interfaces, is that udev may configure their low-level properties, such as name, during early boot, so if you start fiddling with the network interface before libudev tells you it is ready, you may end up having a bad time. This was always the case, but may be even more relevant now as people hopefully start using more of these features. So be aware :-)
10
1
Stefan Brüns's profile photoTom Gundersen's profile photosystemd's profile photo
 
On question regarding the renaming of devices:
If one chooses to have "old school" interface names e.g. eth0, eth1 ..., and wants to make these names fixed based on some udev property (pci id, mac address ...), it might happen that interfaces names, as coming from the kernel, are just switched.

When eth0 appears, will renaming it to eth1 be guaranteed to succeed (because it will happen before eth1 is added), and will the second interface automatically get an unused name (either eth0 or eth2 would be fine here, first case nothing happens, second case it will be renamed to eth0)?

For me, the new predictable (I would prefer deterministic ...) are fine, but there are people used to the old names and completely unwilling to change this ...

Thanks, Stefan
 
udev will no longer (for some time I think) allow you to rename your devices within the kernel namespace. I.e., you cannot rename your device eth0 to eth1. If you want something like that, you should rename them to lan0, lan1, or some other such naming scheme.
Add a comment...