Networking naming anti-pattern
When ethernet device names went weird
Sometime in the early 2010s, you might have noticed that the Ethernet device names on Linux went weird. Before we had "eth0" (for wired Ethernet) and maybe "wlan0" (for wireless). Most desktops and laptops had at most one wired and one wireless Ethernet connection. This naming is clear and adequate for the majority of computers in existance.
Now we get names like "enp10s0" (or much worse). These names mean nothing to the end user, and there is no immediate offered explanation. Source of this new-odd behavior was inobvious.
This new behavior came from the systemd folk. Ran across this bit that perfectly captures the anti-pattern.
When programmers have to write user interfaces, a long-common error is to present software-internal concepts to the external user interface. This is almost always a mistake, as the internal structures in software tend to be rather different from the user's model, and entirely unhelpful. The new network device names are unhelpful.
To get to the above quote, your head has to be so far up ... into the kernel/systemd mindset, that you mistake this view as meaningful to anyone else. Even most programmers could only vaguely guess the meaning of the new Ethernet device names.
The user's model is not the programmer's model.
There was and is a real problem
For servers and virtual machines, the network topology can and should be more complex than for end-user devices. Seems the Linux kernel and systemd may walk the device tree in non-deterministic (and racey) order. Names assigned solely in order of discovery are unstable.
In the end, we care about which Ethernet device is connected to which subnet. That is the end-to-end concern.
Solved this problem (for a batch of military radars) by taking an inventory of all devices in the system(s). Used the MAC address to assign the subnet name to each Ethernet device. This meant a computer hooked to the "cp.inner", "cp.outer", and "dp.outer" subnets had Ethernet devices named cp.inner, cp.outer, and dp.outer. (Also labeled the physical ports on the back of the server with the same name, where possible.) Engineers did have to know the subnets in the radar, but did not have to guess at Ethernet device names.
The presented device names matched the user's model.
How to name an Ethernet port
In the end, we want to know which port is connected to a subnet. If a cable is unplugged from one port, and plugged into another port, the name of the port should be the name of the subnet.
Ideally, the router for the local subnet would supply the name of the subnet. Default names (what the home user would see) would be "local.lan" (for what is now eth0), and "local.wlan" (for wlan0). In more complex structured networks, each router would be given a subnet name.
At present, I do not know of any mechanism to achieve this end.
How I came to this problem
Was building a Raspberry Pi cluster. Used Ansible through netplan to apply cluster-local IP addresses to the wired-Ethernet port. Worked for the Pi5 and Pi4, but not for the Pi3 cards. Saw logged complaints from systemd:
Oct 06 18:11:59 pi3-a systemd-networkd[605]: eth0: Found matching .network file, based on potentially unpredictable interface name: /run/systemd/network/10-netplan-eth0.network
Oct 06 18:11:59 pi3-a systemd-networkd[605]: eth0: Configuring with /run/systemd/network/10-netplan-eth0.network.
Searching backwards from the log message lead to the systemd behavior.
Well .. OK. This is not going to stop me. Will figure out how to apply subnet-naming via MAC.
Just noting the existing mismatch with the end-to-end model.