Submission type

• Bug report
• Request for enhancement (RFE)

Used distribution

Debian/Ubuntu

Predictable interface naming is flawed

This bug describes a design flaw. It can be summarized as "network interface names should be names, not addresses."

Naming interfaces with physical addresses causes trouble.

It makes the simple case complicated. A majority of machines previously had eth0, maybe also wlan0, and no other physical interface. Now they have enp3s5 or enp4s0 or enxbadbadbadbad, all different names. But the admin needs the interface name when configuring services and firewall rules. It was a lot easier to remember and type eth0 than, and I swear this is the actual name it gave, enP2p32s15f0.

Existing scripts and documentation reference the default names. They have to be adjusted if your specific machine has any other interface name, only now a different name is the rule rather than the exception.

People often suggest manually renaming the interfaces back to something sensible. This has always been a common practice for firewalls and routers, where historically you had an entry in /etc/udev/rules.d/70-persistent-net.rules and could just change the 'NAME=' entry from "eth1" to "outside0" to have meaningful names. But that file is not generated by default anymore, so the user has to create an equivalent file from scratch, read more documentation, find the interface hardware address, debug more typos and formatting errors and so on. Setting interface names manually is effectively turning off the "feature" though, and that is now harder than before.

It also gets the less simple cases wrong.

Suppose I have used the builtin network interface for a while and now upgrade by adding a faster one. If the old name was eth0 then I give the new interface the old name and I'm done. But if the old name was enp2s0 then I have an ugly choice. Either I update firewall rules and daemon configs and every other reference on the system from enp2s0 to enp4s0 and hope I don't miss anything, or now I disable "predictable naming" and confuse everything by renaming enp4s0 to enp2s0 even though that name would both indicate the wrong device and imply the device is using "predictable naming" when it isn't.

Using topology as part of an interface name also makes the names less consistent. Put a laptop in a dock, plug in a thunderbolt PCIe cage, remove a GPU #2811, change a BIOS setting #563 and you can change the PCI topology and thus the name of all or none or some of your interfaces. When udev was using hardware MAC, non-network interface changes would rarely change network interface names and could rarely if ever silently cause an interface to use the name previously held by a different interface.

Anything that could unexpectedly change the name of a firewall outside interface to that of a firewall inside interface is problematic.

So here is a suggested alternative (not altogether unlike the old way).

After all network interfaces present at boot are discovered, consult the filesystem for the names of known interfaces and assign them. If a known interface is not found but an interface with the same MAC and a different slot exists, keep the name and update the slot. If there is no interface with that MAC but there is a new interface in the same slot, keep the name and update the MAC. Then deterministically order all the unmatched physical interfaces using the firmware index or PCI bus location, name them in order ethN, ethN+1, ..., wlanN, wlanN+1 and so on and write the new interfaces to the filesystem. An interface added after boot becomes ethN+2 etc.

With deterministic reordering after detection, machines that cannot write rules to the filesystem still use deterministic names for everything present at boot. But writing the interfaces to file when possible ensures that previously seen devices always get the same names even if PCI topology changes. And makes it easier for the user to set names by updating the name in a file that already exists and describes every existing interface. Matching known interfaces first by MAC then by slot means that an interface will keep its name when moved to a different slot or when PCI is renumbered, but if a NIC is altogether removed and another is put in the same slot (i.e. replacing a bad NIC or in a VM that randomly generates the MAC) then that works too. Then the user setting a custom interface name doesn't break the system's ability to update it in those cases.

And every device with only one ethernet/wifi interface will still default to eth0/wlan0.

This doesn't guarantee consistent names on a device without a writable filesystem after interfaces are added or removed, but neither does the current method. Firmware will commonly change PCI enumeration order based on which devices are present at POST. At least this way interface names are only based on the order of network interfaces relative to each other and not the entire universe of things that could cause any PCI renumbering.

A possible variant on this is to use different names than the kernel uses to avoid the rename race. So the kernel will set interface names eth0, eth1 and we rename them to enet0, enet1. In which case the default interface becomes enet0. Or do it the other way around and have the kernel assign enetN and then rename to the traditional ethN.