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

Looking for hackers with the skills:

networking c systemd

This project is part of:

Hack Week 19


Comments

  • mkubecek
    about 2 months 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.

  • bmwiedemann
    about 2 months 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.

Similar Projects

Integrate Firecracker (microVMs) with a Cloud Foundry app runtime scheduler by tassis

Description

[Firecracker](https://firecrac...


Give avahi some love by e_bischoff

Avahi is (among others) a domain names auto-con...


ethtool ops for netdevsim by mkubecek

This can be seen as a subproject of [ethtool ne...


Hammer an Envoy service mesh onto a SAP S4/HANA landscape and watch everything explode. by STorresi

Although CNCF projects are almost exclusively r...


netlink interface for ethtool by mkubecek

There seems to be an overall consensus that the...


dmidecode: no more open-coded printfs by jdelvare

There's a long standing request to extend the o...


netlink interface for ethtool by mkubecek

There seems to be an overall consensus that the...


Improving picotm by tdz

Picotm is a system-level transaction manager. I...


ethtool ops for netdevsim by mkubecek

This can be seen as a subproject of [ethtool ne...


Migrate more OBS service scripts to pure systemd by enavarro_suse

Following the work started in the last hackweek...