== The problem with Linux's 'predictable network interface names' [[I tweeted https://twitter.com/thatcks/status/978332890277834754]]: > I find modern Linux auto-generated Ethernet device names to be a big > pain, because they're such long jumbles. enp0s31f6? enp1s0f0? Please > give me a break (and something short). The fundamental problem with these [['predictable network interface names' https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/]] is that they aren't. By that I mean that if you tell me that a system has, say, a motherboard 1G Ethernet port and a 10G-T Ethernet port on a PCIE card, I can't predict what those interfaces will be called unless I happen to have an exactly identical second machine that I can check. If I want to configure the machine's networking or ssh in to run a status check command on the 10G-T interface, I'm pretty much out of luck; I'm going to have to run _ifconfig_ or some similar command to see what this machine has decided to call the interfaces. (Yes, even for the motherboard network port, which may or may not show up as _eno1_ depending on [[the vagaries of life and your specific configuration FindingOnboardEthernets]]. The _enp0s31f6_ from my tweet is such a port, and we have other machines where the motherboard port is, eg, _enp7s0_.) The other problem with these names is that they're relatively long jumbles that are different from each other at various random positions (not just at the end). Names like this are hard to tell apart, hard to tell to people, and invite errors when you're working with them (because such errors won't stand out in the jumble). This might be tolerable if we were getting predictability in exchange for that jumble, but we aren't. If all we're going to get is stability, it would be nice to have names that are easier to deal with. (We aren't even entirely getting stability, since [[PCI slot numbering isn't stable PCINamesNotStable]] and that's what these names are based on.) PS: There is a benefit to this naming scheme, which is that identical hardware will have identical names and you can freely transplant system disks (or system images) around between such hardware. If I have a fleet of truly identical machines (down to the PCIE cards being in the same physical slots), I know that _enp1s0f0_ on one machine is _enp1s0f0_ on every machine. (Over the years, these device names have been implemented with somewhat different names by a number of different Linux components ([[eg Fedora15EthernetNames]]). These days they come from udev, which is now developed as part of systemd in case you wish to throw the usual stones. I'm not sure if udev considers the specific naming scheme to be stable, considering [[the official documentation https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/]] points you to [[the source code https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id.c#L20]].) === Sidebar: What this scheme does give us Given identical and unchanging hardware (and BIOS), we get names that are consistent from boot to boot, from machine to machine, and are 'stateless' in that they don't depend on the past history of the Linux install running on the machine (your five year old install that's been been moved between three machines sees the same names as a from-scratch install made yesterday).