Using "eth*" names was discouraged for many years, we've been finding problems here and there and working around them with the help of udev-rules (/etc/udev/rules.d/70-persistent-net.rules) to map address interfaces according to PCIIDs, using "net.ifnames=0" as Linux kernel boot parameter when booting in GRUB, etc. Finally we found unsurmountable problems when moving to Debian bullseye (mr9.5), because as we attempt to rename interfaces in some hardware systems that we use, we got race conditions and clashes with renaming that we could not solve in other ways. We had different alternatives: - Use names purely deterministic, based on PCI paths (for example "enp4s0f1"), MAC address or other of the alternatives, which would be "definitive", but given that we have a diversity of hardware and VM installations in customers the devices in different systems would be different, and the fact that it would be easier to mistype or confuse them makes this not ideal. - Use names purely based on functionality, like for example "ha0", "ext0" or "int0". The problem in this case is that we would have to find names that would satisfy everyone (and there's no time for doing this at this point), that different of our system types are quite different (e.g. Pro without bonds, Carrier with bonds and many vlans by default; using the same hardware), and some customers with different installations or needs (e.g. using VMs) have also totally different network configuration -- so any attempt to unify this to make good use of the functionality-based names would be very challenging. - Finally, there's the option to use some symbolic names similar to traditional names like "eth0", but without being exactly this. Popular names in general, although there's no wide consensus, are names like "net0" and "lan0". Talking with groups involved in deploying and maintaining the system, the decision was taken to move to names not purely deterministic, and there's no time for purely symbolic (they also didn't express much interest on them), and prefer something more traditional that they are already used too. Instead of names like "net0" or "lan0", they prefer the more direct mapping to existing interfaces like "neth0". This is ugly or slighly discomforting to use for some, but since the main users (among us) of these names prefer them, so be it. It has the advantage of having a very simple and mechanichal translation based on the current names, which is an advantage especially at the critical time of upgrading existing systems to the new name. Change-Id: I4a168c7d81e40f609749f77a509d2acb72d3a9d3mr10.0
parent
a50903a30c
commit
44750996be
Loading…
Reference in new issue