SUSE Hack Week: make "predictable network interface names" more predictable

Since the so-called "predictable names" for network interfaces were introduced, the concept and mainly its implementation has been a target of a lot of critique and sometimes even hate. On the other hand, similar idea works reasonably well for block devices.

In my opinion, the main reason why "predictable names" reception was not nearly as good as for block devices is the difference in how the implementation works. For block devices, the device name provided by kernel is preserved and other names based on multiple naming schemes (by path, by UUID, by various device identifiers) are created as symlinks so that all of them (including the original kernel one) can be used simultaneously. On the other hand, network interface has only one name and as it is not represented by a file, symlinks cannot be used for aliases. Therefore even if there are multiple naming schemes (e.g. based on BIOS enumeration, bus address etc.), only one of them can be used for each network device and it's rather unpredictable which one is it going to be. Moreover, some of the generated names are rather long, ugly and inconveninent and unlike with block devices, one cannot just ignore them and use a different name (e.g. one provided by kernel).

Since version 5.5, linux kernel supports so-called alternative names which can be set for a network interface in addition to its name. Any of the alternative names can be used to identify the network interface and as their use has been incorporated into the basic net device lookup functions, even the old ioctl based userspace utilities can use the alternative names (some of them may not allow names longer than IFNAMSIZ - 1, though).

The goal of this project would be to add support for alternative names to udev, in particular:

implement SYMLINK+="..." for network interfaces to add an alternative name
let udev rules for "predictable names" preserve the kernel name and add altnames for (all) applicable naming schemes
this should be only done if kernel supports altnames

No Hackers yet

Join this project Leave this project

Looking for hackers with the skills:

networking c systemd

This project is part of:

Hack Week 19

Activity

over 3 years ago: bmwiedemann liked this project.

over 3 years ago: mkubecek added keyword "networking" to this project.

over 3 years ago: mkubecek added keyword "c" to this project.

over 3 years ago: mkubecek added keyword "systemd" to this project.

over 3 years ago: mkubecek originated this project.

Comments

over 3 years ago by mkubecek | Reply

Note: I definitely won't be working on this in the first days of Hackweek 19 and it's not very likely that I get to it in Hackweek 19 at all. The project is rather meant as a tip for developers who may find it interesting.

over 3 years ago by bmwiedemann | Reply

My experience from the 'predictable' network names was that I added a graphics card to a machine and that caused the network to stop working, because the name changed (one number got increased by 1) and then the /etc/sysconfig/network/ifcfg- file did not apply anymore. Would have been no problem with old-style eth0, because there is only 1 network device in the system. So I hope, this work could help there in the future.

No Hackers yet

Looking for hackers with the skills:

This project is part of:

Activity

Comments

over 3 years ago by mkubecek | Reply

over 3 years ago by bmwiedemann | Reply

Similar Projects

networking

mrouted: Join multicast groups via IPIP or GRE tunnels by e_bischoff

Goal for this Hackweek

unbound resolvconf by michals

c

Dictu Language by bdowns328

Port OTPClient to GTK >= 4.10 by pstivanin

Project Description

Package libfyaml by tinita

Project Description

Complete the port of flatpak to appstream from appstream-glib by ldragon

systemd

Use systemd Service Templates to manage OBS workers by enavarro_suse

Project Description