currently attempting to use an ethernet interface called "enp8s0f0npf0vf1" and cannot help but think

STATEMENTS DREAMED UP BY THE UTTERLY DERANGED

THEY HAVE PLAYED US FOR ABSOLUTE FOOLS

I forgot to mention the worst part here, which is that if your interface name is long enough, and your vlan number is high enough... you can't create a vlan interface named enp8s0f0npf0vf1.1024 because it exceeds IFNAMSZ, glibc's maximum buffer size for an interface name.
@dan So much for "predictable" interface names.
@wollman @dan predictably shit is a kind of predictable
@wollman @dan
You can always predict how stupid it will be, thats a prediction enough
@dan I hate that I actually understand that entire monster of an interface name...
@dan that's a kernel limit, not glibc, and dates back to ancient BSD times

@dan depending on your distribution you can give it a short name....!

E.g.:
https://wiki.debian.org/NetworkInterfaceNames#CUSTOM_SCHEMES_USING_.LINK_FILES

NetworkInterfaceNames - Debian Wiki

@dan But at least that is predictable!
@dan

that's because you're not using systemd-vlanctl
@dan Did your cat name your NIC by walking all over your keyboard?
@Kensan one of my cats loves to curl up next to the Mellanox NIC! (it's warm)
@dan Do you run traffic generators just to please said cat?
@Kensan cats can have a little iperf, as a treat
@Kensan the NICs are also connected to the forbidden yellow single-mode string
@dan I have to ask: can you identify packet drops by the purring sounds of your cats?
@dan Well you could have enx55aadeadbeef instead.
@dan (Someone on my team actually prefers this flavor of "predictable" interface naming to the other one.)
@wollman you should revoke their SSH certificates before they do any real damage.
@womble No such luck, they maintain our installer.
@dan makes perfect sense
@dev @dan just stick the frigging MAC address in the interface name, sheesh
@ricci @dev @dan You can – those interface names start with enx.
@dan Beats the hell out of “I hope card 1 gets picked up in the remote reboot order before card 2 so it becomes eth0 and my firewall inside doesn’t become my firewall outside.”

@vees @dan bus enumeration order isn’t stable either

TOFU-like 70-persistent-net.rules were best.

@vees @dan
if only there had been ways to identify a network card and store its ethX name from first boot and keep on using that unless the user explicitly changes the name(s) - must've been impossible.
clearly easier to generate a name that's "predictable" (by some definition of predictable) and, depending on the naming scheme used, hard to impossible to remember -_-

@vees @dan
however, it seems like "ip link" from iproute2 has a new-ish feature that allows setting an additional alternative name, like
$ sudo ip link property add dev enp8s0f0npf0vf1 altname eth0

and afterwards you can address the device as both enp7s0 and eth0. not sure if this works at every place you can set a name, though (like server configs for binding to an interface or whatever)

@Doomed_Daniel @vees @dan The extra challenge round is that people want to be able to pull a network card, replace it with an identical spare one, and get the same interface names rather than new ones (or swap system disks into a new set of identical hardware, for motherboard ports). This makes MACs and other serial numbers bad. Unfortunately PCIe enumeration isn't stable if there are any hardware changes (not just the network card), for reasons.

And now you're mostly stuck.

@cks @vees @dan
so the problem isn't solved (because PCIe enumeration isn't stable), but everything is changed anyway - hooray.

Also, would it be that hard to write the new mac address into some config before or after replacing the NIC?
And if you have a more complex network, don't you have to register the new mac address somewhere anyway, like at a DHCP server, possibly managed switches, routers, firewalls, whatever?

@Doomed_Daniel @vees @dan Server environments don't necessarily do MAC registration, and not all DHCP environments do authentication by MAC (but a machine may still want to keep a stable NIC name for eg its own firewall config).

Broadly: writing the new MAC somewhere is doable but it makes a stressful situation (hardware failure and replacement) worse. I once ran systems that needed this and it was a pain in the rear.

@Doomed_Daniel @vees @dan If you burn the MAC into the network device name, every system has a different name for its network interface, even on the same hardware, which is a sysadmin pain in the rear. If you freeze a simple network name based on the MAC and add a new network name if you see a new MAC, systems can wind up with network names depending on their history; reinstalling the system will give it different network names (because old MACs won't be claiming the good ones any more).

@cks @vees @dan
> If you burn the MAC into the network device name, every system has a different name for its network interface, even on the same hardware

incidentally, systemd also does that - I've seen it for USB NICs, but with a quick search I couldn't find out when exactly that enxMACADDRESS scheme is used..
(at least they seem to be less naive about the path stability of USB than PCIe…)

> reinstalling the system …

yeah, you'd have to keep the mapping file for reinstall

@Doomed_Daniel @vees @dan In many situations you don't want to keep the mapping file, because it creates differences between identical hardware based on the history of a particular server. One out of your eight hardware-identical fileservers having a different network name because you had to move it to the spare chassis (or swap its add-on network card) at one point is a special sort of hell.

(Also, not all reinstalls are planned in advance. Sometimes the disk blows up.)

@cks @vees @dan
Yeah, but what does systemd solve here?
If the NIC names aren't stable because adding a PCIe device (like a NVME SSD, I guess?), or maybe a BIOS setting or update, can change the PCIe topology, it's as shit as before

@Doomed_Daniel @vees @dan I believe systemd creates aliases, or at least lets you set naming policies for devices, so if you want to use MAC-based names you can fairly easily. And the default PCIe based names are mostly stable, and sometimes systemd can actually detect that a network port is a motherboard port and give it a truly stable name.

(This depends on vendors getting various BIOS data right, which is rather variable.)

@cks @vees @dan

AFAIK their approach for custom names is "write an UDEV rule to name the device, you can match the MAC or whatever there", which IIRC was already possible before systemd
(which means that you also could've written UDEV rules to get stable names based on PCIe paths for identical hardware)

UPD: apparently there's not only udev, but also systemd.link which is supposed to support custom names somehow: https://www.freedesktop.org/software/systemd/man/latest/systemd.link.html

systemd.link

@Doomed_Daniel @vees @dan according to systemd docs they briefly did this but stopped because it turned out that in some cases the kernel and udev could race to assign the same ethN to different devices and it would massively break things
(and also apparently there's a surprising amount of systems where the MAC address is randomized on each boot?)
@leo @vees @dan
and that was impossible to fix and required a completely new naming scheme? o_O
@Doomed_Daniel @vees @dan i think they also just wanted something stateless. fwiw if your firmware lists the onboard network adapters in SMBIOS (and almost nothing does bc windows doesn't care lol) they'll have names like eno0
i have some questionable code that does this via an EFI driver: https://gitlab.com/vriska/smbios_patch/-/blob/main/src/main.rs
src/main.rs · main · leo60228 / smbios_patch · GitLab

GitLab.com

GitLab

@leo @vees @dan
yeah, I've never seen a network device like eno0, always enpXsY (or the wl-equivalent) or, apparently for USB NICs, enxMACADDRESS which definitely is impossible to remember, unless you have a *very* special brain..

questionable code is best code :D

@leo @Doomed_Daniel @vees @dan so, to recap:
1. Everything was fine.
2. Systemd arrived.
3. Everything was broken.
4. Rather than just throw systemd back where it belonged, everything had to be made terrible in the name of progress.

@womble @leo @vees @dan

to be fair, it was more like: things were kinda shit (NIC names not stable across reinstalls or even reboots?), systemd arrived, now everything is shit in new ways

@Doomed_Daniel @leo @vees @dan 70-persistent-net.rules solved the problem nicely. In two decades of managing a great many systems that had a great many NICs in a wild variety of configurations (yay 802.1q over bonding!) not once did "my eth0 is now my eth1" ever cause any problem.

But now, I can't assume that my sole NIC will be called eth0, and instead have to cut and paste from the output of 'ip li sh' every time, because a bunch of nitwits had to incompletely solve a non-existent problem.

@dan +1

$ fgrep net /etc/default/grub GRUB_CMDLINE_LINUX="net.ifnames=0"
@dan soon we'll have IP over Linux interface name
@mxshift @dan this reminded me... I still have fond memories of IP over DNS and using it to get free overpriced airplane internet

@vvuk @mxshift I remember setting that up for the first time at SOSP 2005 when I was offended by the thought of paying £25/day or whatever it was for the crappy hotel internet in Brighton

Tunneling it over DNS did not make it less crappy.

@dan
My dude, component part numbers went the same way.
@dan
There's a hard-coded limit of 15 characters for network device names in the kernel, so you can have endless fun with VLANs if there naming restrictions imposed by middleware...
@dan Yeah. But did you also check the mezzanine and midplane configurations to see which virtual switch was mapped into which physical ports behind that enp8s0f0npfvf1, though?
@dan As a professional network engineer this hurts my soul.
@dan @nuintari so much more predictable than eth0
@ajn142 @dan Also, explaining how BSDs and various UNIX systems enumerate interfaces to people who only know Systemd/Linux tends to be tedious.
@nuintari @dan what’s BSD, is that like AIX?

@ajn142 @nuintari @dan

I think that we need to start the Internet rumour that BSD was invented by Arthur C. Clarke and xe explicitly denied that you take "A", "I", "X" and add 1 to each letter.

And for those that believe it, there's then "z/OS" turning into "apt".

(-:

#IBM #HAL #2001ASpaceOdyssey #ArthurCClarke #FreeBSD #NetBSD #OpenBSD #dadjokes #Debian #SciFi

@JdeBP @nuintari @dan I love Clarke’s Foundation series.