Dan Portscurrently 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.
Garrett Wollman@dan So much for "predictable" interface names.
Rob Ricci
void
Emelia/Emi@dan I hate that I actually understand that entire monster of an interface name...
Jima 
@becomethewaifu @dan I hate that you do, too. 😀
As much as I love the syntax of VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD (largely because I am the weirdo who might have the same VLAN ID on two interfaces, connected to disparate switch fabrics), it seems that NetworkManager can name VLAN interfaces any arbitrary thing, so one could probably just make the ifname eth0.1024 to compensate. 😇
equi
Udo B.@dan depending on your distribution you can give it a short name....!
E.g.:
https://wiki.debian.org/NetworkInterfaceNames#CUSTOM_SCHEMES_USING_.LINK_FILES
Norman Wilson@dan But at least that is predictable!
rakoo
Kensan@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 Well you could have enx55aadeadbeef instead.
Matt Palmer
Dev@dan makes perfect sense
Jernej Simončič �
Rob Carlson 
@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.”
mirabilos
Daniel Gibson@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 -_-
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)
Chris Siebenmann@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.)
@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.)
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
leo vriska 
@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
(and also apparently there's a surprising amount of systems where the MAC address is randomized on each boot?)
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?)
@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
i have some questionable code that does this via an EFI driver: https://gitlab.com/vriska/smbios_patch/-/blob/main/src/main.rs
eno0i have some questionable code that does this via an EFI driver: https://gitlab.com/vriska/smbios_patch/-/blob/main/src/main.rs
@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.
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.
@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"
Rick Altherr@dan soon we'll have IP over Linux interface name
Vlad Vukicevic
Tim B@dan
My dude, component part numbers went the same way.
My dude, component part numbers went the same way.
kirjoittaessani@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...
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 Predictable.
gonzalo
Stephen Hoffman@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?
arch-packetmancer@dan As a professional network engineer this hurts my soul.
Buttered Jorts
The Psychotic Network Ferret
JdeBPI 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