linux and predictable network interface names

[madires]

A few years ago linux interface names were a bit messy as the naming was based on the classic method of 'first come, first served'. The first NIC found became eth0, the second eth1, and so on. If you have only a single ethernet and/or WiFi interface this doesn't matter much. They were always eth0 or wlan0. But with multiple NICs it's a different story. At first (before udev) we had to play with the loading order of driver modules and module options to tie specific names to specific NICs. With udev this became much simpler, by adding a rule to tie eth2 to MAC 00:11:22:33:44:55, for example. Then came systemd/udev v197 with predictable network interface names. Your eth0 is now enp2s0 or something similar ( 'en' for ethernet, 'p' for bus path and 's' for slot). The idea is that the NIC's location is used to determine the interface name, so it won't change by removing other NICs or adding new ones.

Are the interface names really predictable now? If your NIC is enp4s0 and you move it to the next slot it becomes enp4s1 (in case of the same bus path). However, if the next slot has a different bus path you might get enp3s3. It's hard to figure out which name a new NIC will get before plugging it in. With multi-port NICs it's even more fun. When I replace the single-port NIC named enp4s0 with a specific dual-port NIC I suddenly get enp5s4 and enp5s5. Despite the naming scheme providing additional levels for function ('f''), port name ('n') or device port ('d') there are many reports of other users about inconsistent and strange interface naming for multi-port NICs. Not so predictable at all!

Any solution? There is a new way to tie the interface names to specific MACs (for systemd/udev). Below /etc/systemd/network create a link-file for each interface. The name should start with '10' to ensure early processing. For example:
10-eth0.link

Code: [Select]

[Match]
MACAddress=00:11:22:33:44:55

[Link]
Name=eth0

You can change the interface name also to something more convenient like 'office' or 'dmz0'.

[DiTBho]

kernel 2.6.37
korina (SoC built-in) ---> eth0
via-rhine ---> eth1
via-rhine ---> eth2

kernel 2.6.39
via-rhine ---> eth0
via-rhine ---> eth1
korina (SoC built-in) ---> eth2

and my solution was?
swap the position of .o files in the Makefile, problem solved

[bitwelder]

Nice. What happens if with that trick you bind the name of a certain NIC to e.g. enp2s0 but then there is also another NIC in bus 2 port 0 which should get automatically a name, i.e. in case of overlaps between forced names and autoassigned ones?

[madires]

No idea! Let's play. I tried to tie eth0 to two different MACs. The onboard ethernet got eth0 and the additional NIC surprisingly eth1. Apparently there's some failsafe guard.

[ejeffrey]

There isn't really a way to do it that satisfies every expectation, because people's expectations are not self-consistent.  In addition, in devices like firewalls, it's often more desirable for the system to fail, than to e.g., accidentally use the LAN profile on the WAN port.  The kernel still uses ethX names if you don't override it, but udev renames them, so it's a bit up to the distribution exactly how persistent names are implemented.

There are basically three current naming conventions for automatically assigned names, but not all distributions use them exactly the same:

eno?: this is used for devices that are identifiable as built into the motherboard.  The idea is that because they are built into the motherboard, their order never changes.  This is the most convenient because eno0 will almost always be present on any device with an built in NIC, regardless of the other hardware configuration.

enp?s?: This is generally used for internal PCIe network interfaces that are not built into the motherboard.  Because it is path based, the idea is that a given NIC should keep the same name when other hardware is added or removed.  Different systems will have different numbering, but you can generally replace a broken device with a similar one in the same location to keep the name.  However, as you have seen if you have a multi-port NIC with an onboard PCIe interface, that doesn't always work.

enx???: this is commonly used for USB network interfaces, and includes the MAC address in the name.  This means a given physical device gets the same name regardless of which port you plug it into, but it's a bit unwieldy, and also has the problem that if even if you ship identical hardware configurations, the NICs won't have predictable names.

Of course, you can create custom names such as wan0, lan0 and assign them however you see fit.  This makes it easy to change your configuration later, but generally means that after changing your network hardware configuration you may need to log in locally or through out-of-band management to update the configuration before the network will start up properly.

[golden_labels]

A matter of perspective.

For someone not seeing the history, word “predictable” is ambiguous and they will replace it with their own subjective expectations. Which, of course, means the existing scheme must fail to meet those expectation in majority of cases.

For someone seeing the history, and that were people who invented name “predictable”, the context is clear and it’s “predictable relative to what it was before”. It doesn’t mean it fits any particular, subjective expectations. It means there is a quite stable way of predicting the name from some objective features.

People too often miss the context in which something was named. :(

[madires]

I'd call the new naming scheme 'persistent' instead of 'predictable' because that's actually the goal, i.e. the interface name stays the same. 'Predictable' means that you can predict the interface name before plugging in a new NIC, like for Cisco or Juniper routers. Huge difference!

[shapirus]

Any solution? There is a new way to tie the interface names to specific MACs (for systemd/udev). Below /etc/systemd/network create a link-file for each interface. The name should start with '10' to ensure early processing. For example:
10-eth0.link

Code: [Select]

[Match]
MACAddress=00:11:22:33:44:55

[Link]
Name=eth0

You can change the interface name also to something more convenient like 'office' or 'dmz0'.

Is there a wheel that systemd has not reinvented yet?

[Nominal Animal]

Is there a wheel that systemd has not reinvented yet?

Probably not.

In all seriousness, I do wonder how large fraction of the design choices in systemd and related subsumed services is due to lingering anger at the Linux kernel developer community, who rejected Lennart Poettering for his poor code quality and unacceptably high number of bugs.  That can be a core source for animosity for life, for someone so socially oriented as he is.

I mean, those reinvented wheels are nowhere near the best known and time-tested ones, quite the opposite.  I guess LP is now finally at home, working for MS, whose design choices LP has always emulated whenever possible.  He definitely always detested Unix philosophy and composability, for example.

With respect to predictable network interface names, consider udev (which Greg KH and Kay Sievers started developing in 2003, even though it got subsumed later on).  It solves the same problem in a much more controllable manner.  I personally have character device symlinks to all my own USB-Serial-MCU projects, so my apps and services can interface to them worry-free.  For ATmega32u4 (Pro Micro clones using Arduino Leonardo), I even have a small script wrapping avrdude, so that whenever I update their firmware, it ignores the Arduino "port", resetting the target (which detaches its usb port), and targeting avrdude to the appearing USB Serial device whose Vendor:Product matches the ones used in mine.

The issues with predictable network interface names is the exact same as with predictable character device names associated with external devices and peripherals.  One utility I've considered writing time and again is actually a GTK and/or Qt "USB device selector", which not only provides a graphical interface to select devices (showing connectivity, including hubs) and access their properties in Linux.  (I have not yet, because I still do not have the social or mental wherewithal to fight with upstreams as to exactly why such a thing is a good thing.  GTK, for example, will reject such until there is a Windows port also; and Qt development has switched to Qt 6, but I'm still solidly on Qt 5.)

[madires]

Is there a wheel that systemd has not reinvented yet?

If you think something can't get any worse it will get even more worse.

[shapirus]

If you think something can't get any worse it will get even more worse.

yeah at some point I was surprised to find some weird "127.0.0.53" in /etc/resolv.conf which ended up pointing to yet another abomination called "systemd-resolved". wtf? why? what was wrong with the regular system resolver? what was wrong with bind9 (powerdns etc.) recursor for those who needed extra features? why solve a problem that does not exist? why allow this crap to get into the distros?

[magic]

There used to be a bunch of rulse in udev where each new NIC would get assigned sequential ethN name which was remembered together with its MAC address and re-applied when the same NIC was connected to the machine again.

IIRC this feature was called "persistent network interface names". I suppose you could find those udev rules and associated scripts and use them today. Perhaps they are still part of s***d, disabled by default.

But really, just rm -rf /sbin/*systemd*

[shapirus]

But really, just rm -rf /sbin/*systemd*

jokes aside, systemd-free distros do exist. not too mainstream, unfortunately, but actually usable. I didn't have experience with them on a regular computer, but I did install Devuan on a mini-pc which I use as an embedded system to run Pianoteq and serve as an external "brain" for my digital piano whose native sound I do not like. Works very well.

[madires]

IIRC this feature was called "persistent network interface names". I suppose you could find those udev rules and associated scripts and use them today. Perhaps they are still part of s***d, disabled by default.

Not any longer. During the transition from udev rules to the new naming scheme you could set kernel parameters to tell systemd to use the old udev rules (net.ifnames=0, or biosdevname=0 for the Dell tool). But that was dropped by many current distributions.

[magic]

Surely you could deactivate the current udev rules and manually install the old ones to /etc/udev/rules.d if you really can't live with the new system.

Or did they screw that up as well? Not gonna lie, it feels good being out of the loop regarding latest systemd drama

[madires]

I'd also prefer a SysV init plus udev over systemd/udev. Debian's bullseye (Debian 11) dropped support for /etc/udev/rules.d/70-persistent-net.rules. Simply adding it again wouldn't work without changing other stuff too. Anyhow, each new dist upgrade would require you to figure out how add the the old scheme again, which is like working against the distribution. But there are alternatives without systemd , e.g. Devuan or Slackware (more: https://en.wikipedia.org/wiki/Category:Linux_distributions_without_systemd).

[Nominal Animal]

Configurability is the other part that completes composability.

For example, Gnome folks do not believe in configurability, and prefer to remove user-accessible knobs whenever possible.  They are also stuck in the same mindset, I call it "Microsoftism", where the component is not a modular library, but an encompassing framework which does not modularily connect to outside, but targets being the end-all, be-all to all needs within the framework walls.
Essentially the opposite to Unix philosophy.

(Feel free to tell me the proper name of that.  I only use "Microsoft" as the example here, because I was there when they really, really tried hard to enforce those walls.  Nowadays its behaviour is very different, especially with respect to free/open source projects.  You still see vestiges of the approach in for example how hard MS pushes the Edge browser on their end users.)

Now, there are scenarios where that approach is warranted; for example, it makes it easier to distribute proprietary software.  In the Unix/Linux/BSD realm, it does not fit well.  This is why many Linux GUI users I know never jumped to Gnome 3, and instead use MATE or Cinnamon, both Gnome 2 forks made when it became obvious Gnome 3's design goals are in the La-La Land.

Ever since I found out I no longer need to conform to the workflow that a vendor provides, and instead can modify my computer/software/tools to conform to my own workflow, I haven't looked back.  I just don't feel the same utter limitlessness when someone else dictates a workflow for me.  Configurability and composability are key factors in this.  Sure, it takes time and effort to adjust things to exactly the way I like them, but that is my choice.
Because of this, I can only sneer at and ridicule people when they say they want to take choice and configurability away from end users.

To me, it's like they are telling me how they wished everyone was forced to wear the same coveralls, made from stretchy fabric so that one size fits all.  Getting anything else but the base blue color would cost more, and the options also limited to just a few colors.  Think how much easier it would make the world of fashion to navigate!  Surely it would be worth it?

[BradC]

jokes aside, systemd-free distros do exist. not too mainstream, unfortunately, but actually usable. I didn't have experience with them on a regular computer, but I did install Devuan on a mini-pc which I use as an embedded system to run Pianoteq and serve as an external "brain" for my digital piano whose native sound I do not like. Works very well.

I'm running Devuan on all our servers, my desktop and laptop and my sons desktop. After running Debian for "a few" years, it was a natural fit. The only distribution I have with systemd is an Ubuntu 20 running in a VM which holds our Zimbra server. I spent a bit of time de-crapifying it at first install to strip it down as far as possible. Thankfully I don't have to interact with it much.

[Karel]

GTK, for example, will reject such until there is a Windows port also;

  !!

 

[shapirus]

I spent a bit of time de-crapifying it at first install.

Lol what a right term this is. In my recent experience, I had to deal with a basic Ubuntu AMI to run on an AWS EC2 VM, and I was shocked at how much crap it came with. It was supposed to be a basic image! Luckily enough, apart from that I mostly deal with containerized stuff, and to build the images I need, there are debian-slim images which are truly basic (and don't yet have systemd, at the time of writing this), not to mention alpine linux images, if I need to go even slimmer.

[Nominal Animal]

GTK, for example, will reject such until there is a Windows port also;

  !!

 

Note that I'm talking about a base-level widget, similar to GtkFileChooserDialog.  A Linux-specific widget without Windows implementation will not be accepted into the core set.

(GTK and Gnome moved from mailing lists to Discourse.  I wonder how large factor it was in the decision, that mail archives cannot be purged of embarrassing information, whereas it is easy in Discourse.  Good luck finding any discussion about new core widgets there.  They even moved from Bugzilla to Gitlab.)

Now, of course I can make my own widget derivative that uses Linux-specific interfaces (/sys/bus/usb and /dev/usb/, latter being constructed by udev), and provides an open file descriptor for the USB device or -1 if none is selected, letting the user choose the USB device in a graphical symbolic view representing the actual connections, with global and user-specific configuration files mapping device types to themeable icons and so on.  I can even provide it as an includeable source file (to be compiled and linked to the final binaries), or as a dynamic library and header files, for others to use.  But as is, it will never become a core part of GTK, unless it is augmented to use a gio-compatible interface that works the same way in Windows as it does in Linux.

By no means, don't take my word for it.  Go read the Core GTK platform topics at their Discourse, and look at the open GTK issues, and decide for yourself whether my assessment is correct, or overly pessimistic.  I do tend to be overly pessimistic in these matters, when I've had difficulties upstreaming bug fixes etc. upstream.

Also, I'm not saying they are doing the wrong thing.  I am saying what their goals are, and how they are going about it, is somewhat incompatible with mine, which makes me not like the way they are going about it.  That is an opinion, and by itself isn't useful or interesting information, so I am describing the reasons why: that way everyone can decide for themselves, in their own context.  (Analogously to how I like to adjust my OS and applications to suit my needs, others will need different adjustments because their needs will usually differ.)  So, do feel free to disagree.

[shapirus]

GTK and Gnome moved from mailing lists to Discourse.

This is a terminal diagnosis.