Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Networking Red Hat Software Linux

Fedora 15 Changes Network Device Naming Scheme 132

Posted by timothy 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."
This discussion has been archived. No new comments can be posted.

Fedora 15 Changes Network Device Naming Scheme More

Fedora 15 Changes Network Device Naming Scheme

Comments Filter:
  • 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.

    • Re: (Score:3, Informative)

      by LordFolken ( 731855 )

      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.

    • Yes, it's all changing, but that's not such a bad thing given the rationale. Yet even though I read TFA I still have two questions:

      1. What about USB attached network devices?
      2. Has the Fedora team reached out to other distributors about this standard? It would be nice to see the Ubuntu people and others make similar changes.

      • Re:Does this mean.... (Score:4, Interesting)

        by Entrope ( 68843 ) on Wednesday January 26, 2011 @09:58AM (#35008662) Homepage

        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.

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

          And this

          • Re: (Score:2)

            by Entrope ( 68843 )

            If they are independent ports with the same MAC address, either the hardware vendor or the device writer screwed up, because there's no sensible way to put them on the same Ethernet segment. (I assume you do not mean a hub on a card, with one port going to the host, which I have seen advertised in some places. If you don't think a big vendor can screw up that badly, let me tell you about the major Unix workstation vendor who delivered ~30 computers to the university I attended where every single workstati

            • As I said, Sun quad-port Ethernet cards often come with all four ports defaulting to the same MAC address. I believe they are typically used to create a high-bandwidth bonded connection to a single switch, so having four ports with the same address isn't a problem.

              (In my case, I'm using the cards to *create* a switch, so having the same MAC address still isn't a network problem. It did take me a while to convince udev to give the ports stable interface names, though.)

    • Re: (Score:2)

      by drsmithy ( 35869 )

      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.

      What kind of blade enclosure are you using where the mapping between blade ethernet ports and external ethernet ports is not hardwired and/or trivially viewable through the management interface ?

  • At my last job we sold CentOS-based routers and fileservers. I'd rename the interfaces ethWAN and ethLAN in the /etc/sysconfig/network-scripts/ifcfg-eth* scripts. And then labeled the interfaces on the box for the installer. Worked pretty well, until we started messing with VLANs, and the init scripts choked on VLANs attached to renamed interfaces.

    Debian's udev rules also tried it, but it didn't work out so well for systems that had a lot of changes - we've got machines in the field that are on /dev/eth8.

    • Ubuntu does a similar thing but it remembers the MAC address for network devices, using a new ethX reference for each new MAC address.

      Not a big deal on a desktop or laptop, but if you use removable drives (like we do for the Linux class I teach) it can cause issues as students move from one workstation to another with their portable installs on usb drives.

      • Note that while the autogenerated persistent-net-rules identifies based on mac addresses you can customise the rules to match based on other stuff and afaict any custom rules will be left alone (only devices with no rule at all get an autogenerated rule).

        So if you know the machines will only have one nic you can probablly write a rule that will match anything and have it work fine.

  • 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?

    • I think this is already done in Linux. At least, if you clone your system to another machine with different MAC addresses, you will get new ethX identifiers. That is, if eth0 and eth1 was used on the original machine, when you clone the OS to another one, its device names will be eth2 and eth3.

      I really do not understand what the article is talking about.

      • That's udev's configuration (done by your distro maintainers) and has nothing to do with anything else.

        • Udev is part of the Linux project, so it is very much to the point. The problem has already been solved by replacing devfs with udev, so it is a non issue.

          • udev is no more part of the Linux Kernel than Fuse it. It's a driver interface. Honestly, I run systems with multiple NICs in them - both before udev and since - and have never had an issue. I also don't have udev configured to name devices based on MAC addresses or anything else. It just works! So really, what is the point again?

    • Why don't they use an alias for the network they are on. That way the network keeps the same name if you move the cable. For Wireless this is easy (using essid), for wired you either need something based on the dhcp server or statically configured.

      • Instead of the dumb "eth0", mine would be "00:1E:90:47:69:93". it's fairly unique. it doesn't change on reboot. all of the ethernet cards on your network will have a unique address. problem solved. they should have asked me first.

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

          • I still use fedora, but I hate all of the new "smart" daemons that figdet the network whenever a device gets plugged in. I mostly find they screw up they networking and just set it and forget it manually.

      • Because you often need specific configuration for hardware, not *just* the network. For instance, a wifi device may connect to the same network but requires an essid and encryption key. Further, two devices sometimes connect to the same network for performance reasons.

        Mac address is the preferable identifier, in my opinion. "Slot" is a terrible identifier for desktops due to USB network devices, but is probably okay for servers (who uses USB networking on a server?). But Fedora is intended for use in bo

    • Re: (Score:2)

      by skids ( 119237 )

      Well, considering Apple still had that eyesore of an OpenFirmware device tree in relatively recent machines, maybe they weren't in a cave, just a basement on the Apple campus.

      On the bright side, this new proposal is so completely and utterly ugly, admins will finally start paying attention and name their ethernet devices approriately, instead of just running with the default.

  • False (Score:5, Interesting)

    by Issarlk ( 1429361 ) on Wednesday January 26, 2011 @07:04AM (#35006966)
    "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.

    • Indeed, my observations seem to indicate that the device name is assigned once when detected and it gets an increasing number. If you clone your system to another machine with other MAC addresses, there will be new device identifiers for the new cards since the old ones are bound to other MAC addresses.

      Is the initial assignment random? I don't know, but I would assume that the built-in are assigned first and then any PCI cards. At least, this is what I have observed, also, I have never seen a built in wirel

    • Re:False (Score:5, Informative)

      by jnelson4765 ( 845296 ) on Wednesday January 26, 2011 @07:16AM (#35007046) Journal

      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.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

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

      • /dev/disk/by-id/ (Score:3, Interesting)

        by bill_mcgonigle ( 4333 ) *

        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.

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

          • /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

            Doesn't that break if you change motherboards or re-cable disk controllers?

        • Please don't use /dev/disk/by-id. SUSE uses this and it breaks virtualization.

          You cannot change the underlying disks (eg. to do migration or V2V) without the guest becoming unbootable.

          Use filesystem UUIDs instead. These survive all sorts of migrations and conversions intact, and are even useful in the non-virtual case -- eg. if you swap SATA disks around.

          Rich.

          • You cannot change the underlying disks (eg. to do migration or V2V) without the guest becoming unbootable.

            Why is the guest even aware of the parent's ID?

            Use filesystem UUIDs instead. These survive all sorts of migrations and conversions intact, and are even useful in the non-virtual case -- eg. if you swap SATA disks around.

            Hrm, I had trouble when I previously switched to all-UUID's as I found it's not possible to change the UUID of an md device, which breaks several schemes (or at least makes for a bit of

      • 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

      • Re:False (Score:5, Interesting)

        by msauve ( 701917 ) on Wednesday January 26, 2011 @09:03AM (#35007942)
        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).
        • Persistency doesn't exist on initial install.. you need to know information before you configure or "name" the interface.. problem is how do you get that information.

          Usually by probing and or trail and error exploration, or you can order by PCI discovery, MAC address, or ARPing an interface to discover other servers or gateways MAC address so you can preferrentially order them.. but each situation is unique. After you have the information used to order, you "can" embed that in the UDEV rules so that the na

        • If you want predictable names from hardware, and you want to be able to add and remove devices the only solution would be to allocate enormous holes if you want to keep the current ethx naming scheme. i.e.

          eth0 - eth999 on board
          eth1000 + slot * 1000 + port for cards
          etc

        • Re: (Score:2)

          by joib ( 70841 )

          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.

          To some extent. The persistency is taken care of by adding state to the system, that is, by storing the MAC's somewhere. That fails e.g. if you switch out a broken NIC, or if due to some hw failure you move the HD to another identical server.

          Naming: The article says they're changing the naming. This is what makes no sense. It

        • but you say it's random (what is "semi-random?")
          Afaict it's determined by the order in which the interfaces are first seen, that in turn depends on the order the drivers were loaded in which in turn depends on details like the kernel/udev versions. So two identical servers installed with identical installation media used in exactly the same way will most likely (but still not gauranteed) come up with the ports in the same order but use different versions or types installation media and/or slightly different

      • /var/log/messages and dmesg are my usual go-to places for such info. In most daily usage, if you can do some thing with a computer, there's at least 5 ways to do it. Which one you use is usually more a matter of style and habit than one being all that much better than another.

      • Re: (Score:2)

        by n7ytd ( 230708 )

        The issue of semi-random device names at deployment time is a good point. Maybe an extension to udev that allows you to pick the bus type/port to assign each name to?

      • 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

        To add to your rant... throw Fiber Channel into the mix, say 100 LUNs from two or three arrays with multipathing and a cluster of 2 or 3 systems.

        Ugly. Very ugly.

    • Re: (Score:2)

      by sgbett ( 739519 )

      Thankyou for pre-empting my question.

      I know as much about linux device management as Ted Stevens knows about TCP/IP, and yet my first thought was 'doesn't udev already deal with this?'

    • Re: (Score:2)

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

    • 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

    • I was thinking the same thing, I haven't seen any distro that assigns adapters arbitrarily. The only problem I've ever had with device naming is that Ubuntu totally loses any adapter configuration done with the GUI network managers if you add or remove an adapter.

    • I run a cluster with eth0 and eth1 defined. If I swap out a network card on a machine, a new eth2 gets created, rendering that machine unreachable over the network. To fix this, I edit /etc/udev/rules.d/70-persistent-net.rules manually.

      Udev doesn't seem intelligent enough to figure out how to do the substitution automatically.
       

  • I mean it's not like network cards have unique identifiers or anything... sigh.

    • You cannot meaningfully use the MAC addresses in a JumpStart kind of situation as you don't know at jump-start creation which adapter will be which in the MAC address sort order, particularly when you are using insert cards.

      I use udev, but then I edit the persistent rules it generates to rename my interfaces "intX" and "extX" (internal and external interfaces) for making firewall rules and so on.

      The problem is that there is no real "right answer" for naming devices berfore you identify them explicitly.

      Oddly

  • Silly (Score:2)

    by Rysc ( 136391 ) *

    There are a lot of device file naming conventions which could be adopted and would serve some useful purposes, but this isn't one. Hasn't the trend been *away* from trying to identify things by how they're plugged in toward identifying them for what they are?

    • The big difference here is that its very common to have multiple "identical" ethernet ports (all of our servers have had at least two GigEs on the motherboard for many years now), and real stuff is plugged into the otherwise identical ports based on physical location. More to the point, what's plugged in is generally unusable without further configuration (esp. in the server world) and one configuration will not work when swapped with the other. That's actually fairly uncommon with other devices - typical

      • Re: (Score:2)

        by Rysc ( 136391 ) *

        Consistent naming is, indeed, beneficial, but there's no benefit from this change.

        What you're after is making sure that logical configuration always maps back to the correct physical link. Since there's no way to assure this the next best bet is to make sure that it always maps back to the *same* physical link. It would also be good, I suggest, to name devices in a manner which aids human identification. Naming devices after what bus they're plugged in to solves neither of these well and the former not at a

  • 1. ethX works fine as long as X fits into 1, 2 or 4 bytes counter.
    2. the MAC address for each ethernet is the thing that allows you to discern among all of them, 1, 2 or 65536!
    3. Good move, Fedora. Then you can change also the /proc filesystem conventions, the sdXY SCSI disk names convention and so on

    • 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

      • Re: (Score:3)

        by ookaze ( 227977 )

        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

        • Re: (Score:2)

          by mvdwege ( 243851 )

          udev is nice once you have your devices up and running. Note however, that your parent is talking about install time, when udev still has to run its discovery.

          I partly agree with GP, it would be nice to have a consistent way to select network interfaces in advance; I don't think giving up the eth<X> naming scheme is necessary for that.

          Mart

          • Re: (Score:1)

            by lingon ( 559576 )

            What install time? If the distro supplies udev rules to map eth0 to the NIC in the lowest PCI slot, they will be available to udevd running during the installation. If your installation image lacks udevd, then throw it in there. All the other distributions does that..

            If by "install time" you mean the milliseconds it takes for udev to notice the device and then rename it then, sure, you have a point, but what problems do you have that requires solving that?

  • http://webcache.googleusercontent.com/search?q=cache:mIvkJYLNHM0J:domsch.com/blog/%3Fp%3D455+matt+domsch+ethernet&cd=1&hl=en&ct=clnk&gl=uk [googleusercontent.com]

    His blog seems be down with all the floods of people telling him to lay off the crack pipe.

  • Application compatibility? (Score:3)

    by h00manist ( 800926 ) on Wednesday January 26, 2011 @07:30AM (#35007138) Journal
    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?

    • 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?

      I've used arbitrary interface names for years and have yet to encounter an ethernet-related application that doesn't work with it.

    • Re: (Score:1)

      by greed ( 112493 )

      Network devices aren't reliably named ethX already. If you assume that, you've got issues. We've got machines with strange network interfaces, and they come up with different names.

      So, if you're going to try to figure out what interfaces to play with, you should ask the system what the network interfaces are. Don't try and glob /dev/.

      So, ifconfig -a tells me I've got eth0, sit0, lo, vmnet1 and vmnet8 on my RHEL workstation. sit0 is down, the rest are all operating and valid. On an RHEL server, we've go

  • Not a good idea.... (Score:1)

    by Anonymous Coward

    Fedora Core already makes use of "udev" and it does a decent job. Then there are the "interface-specific" scripts in "network-scripts" that do a decent job of naming or renaming interfaces along with other stuff. The combined method of "udev" and "network-scripts" confused me when "udev" became "useful" since I was used to using those "network-scripts", but I learned how stuff works. Why can't this Redhat engineer just leave things alone?

    As for this Redhat developer's claims that problems start when multipl

    • Re: (Score:3)

      by ookaze ( 227977 )

      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 t

    • Actually, Matt Domsch is from Dell ... not Redhat. So you can take the tinfoil-hat-of-conspiracy off (or put on another layer depending on your feelings towards Dell). This change is coming from an actual *need* from a certain segment of Linux users/admins. I suspect anyone who has had to deal with NIC failure/reconfiguration on a system with more than 2 cards will welcome this as it is trying to take advantage of newer BIOS technology to deterministically assign names to cards based on the actual physical

      • Re: (Score:2)

        by afidel ( 530433 )
        One big advantage is not having to fix everything when you swap a motherboard, with 4 ports being common on 2U server's it can be a bit annoying to reconfigure everything just because some motherboard component failed. Not to mention the fact that it leads to longer outages and is more prone to human error (the single biggest causes of downtime and data loss).

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

    • Re: (Score:2)

      by sqldr ( 838964 )

      In Debian they use a 70-persistent-net.rules file to tag interfaces with the same name

      Once it's booted, yes. Getting this stuff running in an auto-build via kickstart and suchlike isn't quite as easy. You just want to cable up servers and make $interface "the one in the top left" and not have to wait for the kernel to randomly assign it on the first boot and use trial and error to find it.

  • This is a complex solution to a non-problem I think

  • Comment removed (Score:4, Insightful)

    by account_deleted ( 4530225 ) on Wednesday January 26, 2011 @07:48AM (#35007264)
    Comment removed based on user account deletion

    • Re:Article is a joke and false (Score:5, Informative)

      by characterZer0 ( 138196 ) on Wednesday January 26, 2011 @08:44AM (#35007718)

      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.

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

        No, they won't necessarily be the same. However, the problem I see with this is what happens when you move the PCI cards around on the bus to accommodate new hardware? What if you have a quad port card... now you have 4 ports that suddenly get renamed because you moved the ethernet card from slot 2 to slot 3 to make room for an additional RAID card. Ugh...

        Assigning them via udev and MAC seems to be a much better solution than this one that solves one problem and creates another.

    • 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 wi

      • Re: (Score:1)

        by lingon ( 559576 )
        But then they can do just that -- fix the issue with that a device name is in no way associated with the physical device location, i.e. the motherboard connector with the lowest something (IRQ, whatever) will always be called eth0. All the required information is available via proc, they can fix this by using udev distribution-wide. Why on Earth would they want to change the naming scheme? That just doesn't make sense!

    • Re: (Score:2)

      by 0racle ( 667029 )
      Ya it always works great, except when it doesn't. I have one CentOS install that has 3 ethernet ports. I can guarantee every time it needs to be rebooted that they will be numbered differently and I'll have to go and update VMware to bridge the right ports.

      It's the only one that does this, even the identical machine sitting beside it doesn't do this.

      Nothing in Linux guarantees port numbers. Some things try, but none guarantee.
  • I have never had much of a problem with multiple eth devices. Sometimes udev gets mixed up and changes the order. You can manually correct this in the udev.d rules. I suppose if you were trying to deploy large numbers of machines this could become problematic. If you knew it was all the same hardware seems you could just code the udev network rules so they would not be modified.
  • I've never had ports swap names on a reboot, but I have seen it after a kernel upgrade. I've seem Mac servers with small tree cards also do it after an OS upgrade.

  • Please no... (Score:3)

    by Junta ( 36770 ) on Wednesday January 26, 2011 @09:27AM (#35008266)

    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.

    • Re: (Score:3)

      by Junta ( 36770 )

      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 th

  • How about a compromise? Keep the ethX names, but use the proposed scheme to have an unambiguous order in which the names are assigned.

    • Re: (Score:2)

      by Junta ( 36770 )

      Or something like the /dev/disks/ hierarchy.

      eth0, etc etc still as is, but a way to trivially enumerate the names they want to the 'eth' names.

  • I prefer having greater clarity and visibility into which dev is which specific piece of hardware.

    The new convention is pretty straight forward and consistent. I like consistent.

  • The feature[1] is only for some servers (HP, DELL), so that the device name would match the label on the port. THERE IS NO NEED TO PANIC.
    also, it won't change your settings, it will only change on new installations.

    [1] https://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming
    [2] https://fedoraproject.org/wiki/FeatureList - " On Dell and HP servers with multiple network ports on the motherboard, name them lomX rather than ethX. "

  • Is reading the manual too hard? (Score:1)

    by Anonymous Coward

    I am a noob at this stuff, but even I can find on Wikipedia the following:

    udev supports persistent device naming, which does not depend on, for example, the order in which the devices are plugged into the system. The default udev setup provides persistent names for storage devices. Any hard disk is recognized by its unique filesystem id, the name of the disk and the physical location on the hardware it is connected to.

    udev rules can match on properties like the kernel subsystem, the kernel device name, the

    • Problem is you need to know the MAC address association with the port number. And/or which LAN which port is connected to apriori.
  • Matt has been working on this problem a long time. I believe he used to be with DELL and tried to get a group of hardware vendors to solve the problem by (1) default ordering the eth0 interfaces by MAC address (required some code support in the OS) and then (2) getting the hardware vendors to agree on a universal rule that MAC addresses were assigned to devices in preferrential order, hopefully coordinated with the packaging on the motherboard or the server itself. The problem has long roots, at one time I
  • I have been following this issue for awhile now which also affects CentOS 4 and CentOS 5. For setting up Linux firewall systems it can be a big security risk for interfaces to come up differently on a reboot. There are workarounds but an out of the box solution would surely make setting up firewalls easier on Linux.

    The details are in the redhat bug here:
    https://bugzilla.redhat.com/show_bug.cgi?id=491432 [redhat.com]

    I use the fix where you tell udev to ignore ethernet cards and let the normal modprobe.conf load t
  • Why don't NICs have device nodes in /dev anyway? That would be the UNIX way of doing things, right? And you could place symlinks in there all you like, e.g. to name the NICs by MAC address (/dev/nics/by-macaddr/*), or by bus technology/number, or whatnot, and then refer to devices from userspace using whatever scheme you prefer.

Slashdot Top Deals

No spitting on the Bus! Thank you, The Mgt.

Close