Slashdot Mirror

← Back to Stories (view on slashdot.org)

Fedora 15 Changes Network Device Naming Scheme

Posted by timothy on from the shock-horror-horror-shock dept.

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."

24 of 132 comments (clear)

  1. Does this mean.... by xgadflyx · · Score: 2

    The excitement of the "ifup/ifdown ethX" game with co-workers watching for the green light while mapping blade enclosures is no more? What a shame.

    --
    Civilization, the death of dreams.
    1. Re:Does this mean.... by LordFolken · · Score: 3, Informative

      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.

    2. Re:Does this mean.... by Entrope · · Score: 3, Interesting

      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.

  2. still a crappy solution by WatchMaster · · Score: 2

    the proposed solution depends on the slot the board is in? These must have been Apple II guys who haven't come out of cave in the last 20 years.

      Why don't they just use an alias for the MAC address on the cards, so that it is totally general?

    1. Re:still a crappy solution by A+nonymous+Coward · · Score: 2

      Until your NIC dies and you replace it. But life is full of annoyances.

      However, I don't see the need for this scheme. Calling them ethN where N is an index into a MAC cache is perfectly fine. if the NIC dies and you replace it, just edit the cache. No biggie. This Fedora15 scheme just adds complexity for little reason.

      --
      Infuriate left and right
  3. False by Issarlk · · Score: 4, Interesting

    "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.

    1. Re:False by jnelson4765 · · Score: 4, Informative

      Actually, it doesn't. The interfaces can be named the same on reboot, but the initial numbering is semi-random.

      The problem arises when you're trying to deploy a large number of machines, and you know which devices are where on the PCI buses (modern servers are coming with 4 Ethernet ports on the motherboard now). That way, you can assign VLANs and IPs to specific ports in a kickstart file and the installer doesn't have to play the "which interface is eth1" game. Which is not fun. We should not be relying on automagic configuration for something as basic as ethernet...

      <rant>this is why I don't like the /dev/sd* interfaces in Linux - you have to dig deep into /proc to find out which port SATA and SAS devices are on</rant>

      This doesn't get into crappy BIOSes that enumerate devices badly, or NICs that have a bad habit of initializing late.

      --
      Why can't I mod "-1 Idiot"?
    2. Re:False by mvar · · Score: 2

      I never had such issues and i've administered quite a few boxes with more than 2 or even 3 ethernet ports

    3. Re:False by Anonymous Coward · · Score: 2, Insightful

      <rant>this is why I don't like the /dev/sd* interfaces in Linux - you have to dig deep into /proc to find out which port SATA and SAS devices are on</rant>

      Take a look at /dev/disk. You should find what you're looking for there.

    4. Re:False by Issarlk · · Score: 2

      I use Debian a lot, and it generates a rule for udev to have the eths' names stable, it assigns a name to each card by looking at it's mac address. that's why if you clone the machine and it gets cards with other macs the old eth are still in the udev rule and you find yourself with your first interface named eth1 or 2

    5. Re:False by discord5 · · Score: 2

      The problem arises when you're trying to deploy a large number of machines, and you know which devices are where on the PCI buses (modern servers are coming with 4 Ethernet ports on the motherboard now).

      Strange, I've never encountered this problem when deploying images on a batch of identical servers. I know that Debian has an issue when the MAC address of a NIC changes, so you'll have to edit a file (that I've got documented somewhere in an install procedure but for the love of god can't remember by heart), but I've never had the problem under RHEL so far. I've only run into the problem on debian after replacing NICs on a server, and when using virtual machines under Xen (which by now is ages ago).

      Finally, I'd rather have a consistent solution that follows the eth[x] naming scheme. I have this thing where I like the fact that eth[x] means it's an ethernet device, tun[x] and tap[x] are tun and tap devices, fddi[x], ppp[x], wlan[x]... It says a lot more about the nature of the device than em[x] (for embedded), pci[x]#[y] (for PCI devices). Really, what is on pci[x]#[y]? Is it an ethernet card or something else? If the whole thing doesn't apply to something else, won't those interfaces suffer the same problem? Also: dont worry though, just add more numbers if you're dealing with aliases pci[x]#[y]:[z], or a vlan em[x]#[y].[z]. What about usb network interfaces (as much as I abhor them)? I guess the following command will become important for sysadmins who want to remain sane in the future:

      ip link set dev pci[x]#[y] name eth[x]

      The above is at least supported for the past 5 years by all major linux distributions, and could probably be scripted by reading from /proc. Maybe I'm afraid of change, or maybe I've never seen this issue as a real dramatic problem needed to be dealt with in such a dramatic naming scheme... It just reeks of a solution without a real problem.

      this is why I don't like the /dev/sd* interfaces in Linux - you have to dig deep into /proc to find out which port SATA and SAS devices are on

      This problem was solved years ago by placing labels on your filesystems, and there's the option of using UUIDs as well. Hell, if you want to go all the way, you can use LVM in exchange for a minor performance hit. Oh, and there's /dev/disk/by-path/ and /dev/disk/by-uuid/ as well. This problem has not been solved just once, but several times (and most people still use /dev/sd on simple server setups too).

    6. Re:False by msauve · · Score: 5, Interesting

      There are multiple issues, some of which have already been solved:

      Persistency: once eth0, always eth0 - this is what most commentators here seem to think this is all about, but it's already taken care of by udev with most modern distributions.

      Enumeration: Lacking previous knowledge, the order in which interfaces are enumerated. I would think this would be deterministic, but you say it's random (what is "semi-random?"). I'll take your word for it. It seems this is the problem they're trying to address. MAC addresses are indeed useless for this, in a general case, since we may be trying to enumerate ports on plug in boards (e.g. there's no guarantee the MAC in slot 1 will be lower than the MAC in slot 2).

      Naming: The article says they're changing the naming. This is what makes no sense. It's not "required." ethx is just fine, as long as the names are enumerated consistently (meaning that on two "identical" boxes, the order is identical based on physical port).

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
  4. Application compatibility? by h00manist · · Score: 2

    What's this going to cause as far as applications, is it going to require every single app that talks to ethernet to have special functions for Fedora?

    --
    Build your own energy sources from scratch. http://otherpower.com/
  5. Hmm isn't that what udev is for? by /.Rooster · · Score: 2

    Dunno it is really an issue. Seems to me Fedora are making work for themselves. In Debian they use a 70-persistent-net.rules file to tag interfaces with the same name each time they are detected. Works nicely especially when you have multiple interfaces and one that is removable.

    Just another FTSTP really.

    --
    Rooster - A friend. "Anyone's friend in particular or just generally well disposed to people?"
  6. Article is a joke and false by adosch · · Score: 3, Insightful

    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.

    1. Re:Article is a joke and false by characterZer0 · · Score: 4, Informative

      With the existing system, if you wipe the disk and reinstall, will the interface names always be the same? It sounds like that is what they are trying to ensure. It could be helpful for frequently re-imaged machines and for diagnostics.

      --
      Go green: turn off your refrigerator.
    2. Re:Article is a joke and false by Deleriux · · Score: 2

      Whilst this solution does not particularly offer any more device consistency with what is already in Fedora, the idea here I believe is to make the ethernet configuration stateless in addition to consistent.

      This is not the case at the moment, as the network scripts add udev rules binding ethX named devices against the MAC address of the underlying device itself (so Mac AA:BB:CC:DD:EE:FF is always ethX). This additionally offers no indication of which PCI device this is referring to, and on ethernet cards with multiple ports, which port the ethernet device is associated against.

      I think this is over-engineering a solution if your only after seeking for device naming consistency across reboots, but it makes more sense when you understand that what Fedora want to do is be able to make their logical naming schemes for network devices map to the physical devices, in addition to providing device naming consistency.

  7. /dev/disk/by-id/ by bill_mcgonigle · · Score: 2, Interesting

    this is why I don't like the /dev/sd* interfaces in Linux - you have to dig deep into /proc to find out which port SATA and SAS devices are on

    You might appreciate /dev/disk/by-id/:

    $ ls -l /dev/disk/by-id/
    total 0
    lrwxrwxrwx 1 root root 9 Dec 24 10:58 ata-ST3500630AS_9QG32BJ5 -> ../../sdb
    CLIPPED FOR LAMENESS FILTER
    lrwxrwxrwx 1 root root 9 Dec 24 10:58 ata-ST3500641AS_3PM1BA52 -> ../../sda
    CLIPPED FOR LAMENESS FILTER

    The /dev/disk tree can be super useful for, e.g. iSCSI device names in scripts.

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    1. Re:/dev/disk/by-id/ by isopropanol · · Score: 2

      I prefer /dev/disk/by-path

      /dev/disk/by-path/pci-0000:00:11.0-scsi-7:0:0:0-part1 /media/backup auto noauto,noatime,user 0 0
      /dev/disk/by-path/pci-0000:02:00.0-usb-0:4:1.0-scsi-0:0:0:0-part1 /var/log ext4 noatime 0 0

      This way whatever disk I put in the eSATA is on my backup mountpoint, and the USB key in a specific USB port is logs.

  8. Sometimes... by Kludge · · Score: 2

    Usually udev handles this correctly.
    Recently I was swapping NIC cards in and out of my server, and after putting a card back in, only one of my 3 network cards was functioning. Fortunately there was a system message saying that udev was renaming eth1 to eth2 (I don't know why it was), and neither eth1 or eth2 was functioning. I blew away /etc/udev/rules.d/70-persistent-net.rules and rebooted, and then everything was renumbered, I went from there, and it has been stable since. Took me a while to figure out what was going on.
    At setup a system that identifies the MOBO NIC and the other PCI NICs would have been helpful. That's what the new system proposes doing.

  9. Re:FINALLY this will be fixed. by ookaze · · Score: 2

    As has been mentioned above - you can tell from your comments you are just a home user.

    Try writing OS-level software (stuff that is imaged onto the device) that depends on the NIC in position 1 on the PCI bus always being the management interface (IE, the first port in the chassis). Remember this software has to know IN ADVANCE which port it is, you can't use the MAC for this at all.

    This has been a problem in Linux for years and one that developers have always had to hack and slash around. I am glad RedHat is finally fixing it. Hopefully other distributions will follow suit.

    I don't understand what you're saying. If you wanted to do that, you could do it a since years with udev IN ADVANCE of your software you want to launch.
    Since YEARS udev has put persistent device naming so that what is said in the article is wrong, because you will always get the same name for your devices.
    Since years, I actually have my Ethernet interfaces which are not named eth0-X but sth else, which is based on any arbitrary value you want that is provided by udev, including PCI slot and what not.
    So what exactly are you talking about?

    The sole difference I see there is that the distro will now do it upstream instead of you having to put your udev rules.
    Which seems to be a good thing since people like you who are not mere "home users" apparently don't know about these features and have missed these functionality for years. What's worse is that you're saying it's a problem with "Linux" whereas the sole problem comes from you being ignorant of the solution.

    It's strange too that you talk about this being a problem with Linux and devs having to hack and slash, when the solution couldn't be done anywhere before because the specs weren't out (SMBIOS 2.6, now exposed through linux kernel since 2.6.36 some weeks ago, or ACPI or via biosdevname) and the solution proposed here is still the exact same kind of hacks you're talking about.
    FWIW, the sole difference here is the naming convention, as the solution is still implemented via udev rules, with the exact same mechanisms as before, mechanisms used for YEARS with the same hacks.
    The main difference compared to before, is that now the naming scheme can be streamlined by a distribution, while before it couldn't, because it would have no consistency.

  10. Re:Not a good idea.... by ookaze · · Score: 2

    I agree partly with you.
    It's true that consistent interface naming has just worked for years with multiple interfaces.
    The author is talking about races but they are not explained in his paper and are marked as thinks since 2009.

    What this basically boils down to is that now distributions can streamline the naming of your interfaces without you having to go test them the first time you install your OS to know which is which. You'll now know immediately from your OS.
    This shouldn't upset anyone, except people that can't accept change. It will be a matter of accepting now to use lom0-X or em0-X instead of eth0-X.

    People like me who are already using udev rules to change their network interface names won't be affected anyway, and you still can name your interfaces like you want as udev is still what renames these interfaces.

  11. Please no... by Junta · · Score: 2

    This 'solves' one problem but creates another.

    Yes, sometimes in a multi-homed server, the ordering gets confusing. *however* if trying to write a script to operate on a range of heterogeneous systems, 'eth0', etc is more likely to work than 'em0','pci0',etc. Most places that do have confusing names compensate by one of the following:
    -Using ethtool to see what driver manages it and deal with it that way (basically mimicking this design), but this has the same issues, which lead many places to do the second option.
    -Detecting what subnet they are via DHCP and using that information to find the 'right' nic for something or other.

    In multi-homed systems, the bios-dictated topology is usually less important than the IP topology.

    --
    XML is like violence. If it doesn't solve the problem, use more.
    1. Re:Please no... by Junta · · Score: 2

      I will also say that I would not mind:
      -Something akin to /dev/disks. /dev/sd is still there, but /dev/disks/ provide convenient schemes to find the 'right' sd in a complicated environment. If there were a simple utility that given 'ifnamefor em0' spews out 'eth0', that would be fine. You could *not* enumerate an interface multiple times in ifconfig/ip output, would have to be a separate utility.
      -As others mentioned, using bios information to dictate eth order. Consume the onboard nics 'in order', then the pci ports 'in order', and so on.

      Do both of these and make everyone happy.

      --
      XML is like violence. If it doesn't solve the problem, use more.