Fedora 15 Changes Network Device Naming Scheme
dkd903 writes "Fedora developer Matt Domsch has announced that Fedora 15 is breaking the conventional ethX naming scheme used for Ethernet devices by adopting a new scheme called Consistent Network Device Naming. The ethX naming scheme works fine as long as the system has only one Ethernet port. However if there are more than one Ethernet ports, the actual problem starts."
"However if there are more than one Ethernet ports, a sort of race condition develops at every system boot and the ports may get their names in an arbitrary order"
Wrong, udev handles this very fine. This is a complicated solution to a non-problem.
You should use LLDP a protocol for discovering what iface is connected to what port on the switch. There is an lldpd available for pretty much all distros.
So tell me, when, on a reboot, we cannot make sure that 'eth0' will remain 'eth0' if we have more than one ethernet device? Bullfish to the n-th factor. The boot strapping in /etc/init.d/network has MORE than compensated for this for years in any RedHat-related or spin-off distro I've been working with. For any sort of persistent device naming you can use udev rules (can be a bit over learning overhead so you don't trump rules or get your rules to work the way you want them to) or hack out one of the ifcfg-eth* network device scripts and edit the HWADDR parameter with the MAC address of the ethernet device you want to hard-line to that device name.
To the articles defense, the new naming scheme does make sense, but regardless, it's just that: over engineered and way more complicated than it needs to be. If it isn't broke, don't fix it. And furthermore, don't call something broke when it's not.
Debian (and its derivatives, including Ubuntu) have been taking a less disruptive approach to this for years now by assigning persistent ethN device names based on MAC addresses. For example, if the system has no device names assigned and sees 01:23:45:67:89:ab as the first Ethernet device's address, that becomes eth0 from that point forward. The next Ethernet device that gets enumerated is going to be eth1, and so forth. This means it handles the USB device case in the way most users would expect.
I suppose there is some advantage to using geographic addresses for people with lots of multi-NIC machines to build, and for people who need to hot-swap cards for reliability reasons. I suspect that Debian's udev-based approach could handle the latter either now or with minor tweaks, though.