The needs of the many? Fedora Consistent Network Device Naming

I’m writing this because of a change to Fedora networking that has caused me annoyance and wasted time. If you’re reading this perhaps you’ve been affected too?

I’m talking about ethernet interface naming… many people who’ve upgraded their Fedora installs will have asked the question “what happened to eth0?” Why are my ports now named “p135p1″ (and other odd and confusing names)? The ethernet interfaces have been renamed because somebody decided that logical port names based on the type of device should be changed to names based on the location of the device(?!). If this seems like an illogical case of the cart driving the horse to you, then you are not alone! Worse still, the new default location based naming scheme doesn’t even work properly in many cases (like my atom machine).

If you are simply looking for a way to return to logical names like eth0 and eth1 then skip to the fix at the bottom of this article by clicking CNDN fix. If you want to know more, you can read this wee rant about the linux network device naming…

The Good

For years linux followed a convention of naming its ethernet devices eth0, eth1, eth2 etc… Volumes of literature refer to configuring network interfaces based on these names. People wrote scripts that configured eth0, and we all knew intuitively that the first ethernet device in the box was eth0 unless some idiot had misconfigured things. MAC address security schemes were used by software developers that relied on the network hardware at eth0 retaining a specific MAC address (all MAC addresses are unique). This wasn’t without its problems (it was vulnerable to MAC address spoofing and had other limitations), but that didn’t stop wide adoption of such techniques. In the vast majority of computers, there was only a single ethernet network interface card (NIC), and even if they had more than one, they were almost guaranteed to have one named eth0.

The Bad

On the whole this worked well, but the approach had some pitfalls for a specific class of users. In short, there was no industry standard for the order in which the device naming took place. For the majority of machines with only a single ethernet NIC this was not a problem. However, on systems with multiple NICs, replacing a single faulty card could cause some/none or all NICs to be renamed depending on whims of boot startup order etc. Managers of server systems had to come up with clever methods of working around these issues. One approach was to bind ethernet interface names to the unique MAC address that every card has. That way, naming remained consistent between restarts and if a NIC had to be replaced, the MAC addressing for only one NIC had to be fixed. However this solution wasn’t good enough for everyone…

Some people (notably Matt Domsch of Dell) decided that a better solution would be to come up with a completely new naming convention whereby names were mapped to where the cards were connected to the computer instead of the function of the cards. This approach solves the problems of the few (managers of servers with multiple NICs when they need to change hardware configurations) whilst making things worse for the vast majority of casual linux users and software developers. The new approach has been oxymoronically named Consistent Network Device Naming or CNDN. You can read some of Matt Domsch’s justifications for this new approach here.

As Mr Spock said in the Wrath of Khan, “logic clearly dictates that the needs of the many outweigh the needs of the few.” And who are we to argue with someone with eyebrows like that?

The Ugly

So, we come to a situation where many people have upgraded their fedora installs and found that their scripts no longer work, their software is complaining about security violations, they have to interrogate the system to find out what their ethernet ports are named, their motherboard ethernet ports are bizarrely named p34p1 and p35p1 even though there’s no PCI cards in sight, and eth0 is now em1. People want to have anaconda kickstarts that configure their networks after install, but these no longer work because their ethernet devices suddenly have arbitrary and Inconsistent names applied. Fedora now has its own unique network card naming scheme that further fragments the linux community… resulting in even more differences between distros. Arrgh.

Here are just some of problems with the new scheme:

• The device names no longer reflect their function but instead where they are placed.

• The device names are now bound to PCI bus technology, which has little to do with network configuration at a logical level

• The algorithm used to determine the device names is flawed and often results in motherboard based NICs named as pX instead of emX

• One cannot know intuitively what the name of the first ethernet port on any given machine is

• All the existing literature for the configuration of network interfaces is now broken for linux systems using CNDN (but still applies to all the other distros wise enough not to adopt such a daft scheme)

• Legacy software that used MAC address security scripts break for users

• Scripts used to configure multiple machines with different hardware sets are harder to devise

Digging on google yields a number of different workarounds. Even proponents of the new system seem to say “if you don’t like the new approach, you can put it back to the old way with some configuration”. I’d rather they tell me how the new system is supposed to work for the various use-cases that arise. If the only solution is to insert workarounds which put it back to the way it used to work then the new system is indefensible.

The Fix

After wanting to be an early adopter of the “way of the future” I am yet to be convinced that CNDN is a good idea, and have started reverting systems to using ethX again. Here’s a one line fix that appears to restore normality on Fedora 16:

as root, edit the file

/lib/udev/rules.d/71-biosdevname.rules

find the line which reads:

PROGRAM="/sbin/biosdevname --policy physical -i %k", NAME="%c", OPTIONS+="string_escape=replace"

replace it with

PROGRAM="/sbin/biosdevname --policy=all_ethN -i %k", ENV{INTERFACE_NAME}="%c"

then reboot.

That should fix the madness. If you have manually set up configurations for your interfaces you’ll probably also need to rename and edit the corresponding files in:

/etc/sysconfig/network-scripts/

for example, on my machine I needed to rename the file ifcfg-em1 to ifcfg-eth0 and modify the lines inside the file that read

DEVICE="em1"

to

DEVICE="eth0"

if you have more than one network device and want to ensure that a particular port corresponds to a specific eth interface number, then you can map all the devices’ MAC addresses to their interface numbers by editing the file

/etc/udev/rules.d/70-persistent-net.rules

and change the NAME=”ethX” entries for the corresponding lines.

# PCI device 0x14e4:0x170c (b44) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1d:09:cb:aa:23", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

a reboot is required for these changes to take effect, and you may have to take action if you remove or replace an ethernet card (IMO a minor annoyance compared with the sledge hammer solution of changing the entire network interface naming system).

If this fix doesn’t work for you, you can try out some other ideas such as those in this blog post here.

Further information on the approach I’ve used can be found on the Fedora forums here.

.