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

Comments

Does this mean....

[xgadflyx]

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:Does this mean....

[LordFolken]

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.

Re:Does this mean....

[Random BedHead Ed]

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

[Entrope]

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.

Re:Does this mean....

[drsmithy]

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 ?

Re:Does this mean....

[GioMac]

Come on, why are you Debian guys always terrorizing everything?

Actually fedora uses udev for a loooong looong time, it uses mapping then for network-scripts:

[root@Fedora ~]# cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x8086:0x108c (e1000e) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:30:48:01:ab:cd", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x109a (e1000e) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:30:48:02:ab:cd", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

Re:Does this mean....

[Carnildo]

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 works just fine, right up until someone installs a Sun multiport Ethernet card in the machine. How do you handle four ports, all with the same MAC address?

Re:Does this mean....

[Entrope]

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 workstation's Ethernet interface was programmed with the same MAC address.)

One configuration I use at work uses an Intel multiport Ethernet adapter, and each of its ports has a unique MAC address. As a result, it Just Worked with udev.

Re:Does this mean....

[Carnildo]

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

We did this years ago

[jnelson4765]

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

Re:We did this years ago

[i.r.id10t]

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.

Re:We did this years ago

[isama]

i used this on my usb install hidden away in a initscript: rm /etc/udev/rules.d/90-persistent-net-rules; touch /etc/udev/rules.d/90-persistent-net-rules; most classroom pc's only have 1 nic so it doesn't matter. i've been up to eth42 before i did this.

Re:We did this years ago

[petermgreen]

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.

Re:We did this years ago

[Anonymous Coward]

This is actually a really easy problem to fix, in Debian's Udev the device/mac address combination is saved in a startup file, you can change the order of the devices or delete them entirely and start fresh with a new file and it will assign the interfaces again.

still a crappy solution

[WatchMaster]

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?

Re:still a crappy solution

[lordholm]

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.

Re:still a crappy solution

[Carewolf]

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.

Re:still a crappy solution

[Anonymous Coward]

Because you're not naming networks, your naming interfaces. The goal is the same physical port on the machine is always referenced by the same name in software. Which is very useful in data center environments where the guy looking at the machine and the guy making changes aren't always the same person. If you bind the name to a network then any time the machine moves or is re-cabled or whatever then the interface name changes as well.

Re:still a crappy solution

[WatchMaster]

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.

Re:still a crappy solution

[A nonymous Coward]

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.

Re:still a crappy solution

[X0563511]

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

Re:still a crappy solution

[WatchMaster]

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.

Re:still a crappy solution

[lordholm]

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.

Re:still a crappy solution

[TemporalBeing]

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?

Re:still a crappy solution

[skids]

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.

Re:still a crappy solution

[Excelsior]

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 both, so this just doesn't make much sense to me.

Re:still a crappy solution

[Carewolf]

You could do both? Try comparing it with partition and harddisk labelling in linux. It can be done by silly inpredicable id's like network currently do, they can be set by hardware unique id's, reliable except when you replace broken hardware or by partition labels. I prefer labels, but it does depend on user interaction, fortunately one thing doesn't exclude the other. /dev/network/by-id/*

False

[Issarlk]

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

Re:False

[Anonymous Coward]

Indeed it can, but it doesn't necessarily do that OOTB.

On most distro's (even on ubuntu and debian iirc), udev doesn't do this by default.

Re:False

[lordholm]

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 wireless take up eth0 when there is also an ethernet port built in.

Can someone explain why they change this and actually give a valid reason?.

Re:False

[jnelson4765]

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:False

[sgbett]

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:False

[mvar]

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

Re:False

[Anonymous Coward]

Why can't they just give the motherboard NIC's first priority (eth0-eth4) in order of their label, then PCI in order of their slot followed by any USB or anything else

Re:False

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

Re:False

[Rudeboy777]

Why can't they just give the motherboard NIC's first priority (eth0-eth4) in order of their label, then PCI in order of their slot followed by any USB or anything else

For the same reasons the guy you replied to said - bad BIOSes as well as the fact the OS won't know which are "on-board" and which aren't since they're all hanging off the PCI or PCI-E bus.

Re:False

[Issarlk]

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

Re:False

[mathew7]

My ubuntu server did this by default (I don't remember which 8.x was used for installing). I remember when I replaced my mini-itx with a laptop (HDD went inside laptop) to continue as my router and had to shuffle MACs (2nd ethernet was a USB bridge which was unchanged since it was present on both HWs).

Re:False

[discord5]

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

Re:False

[msauve]

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

Re:False

[GameboyRMH]

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.

Re:False

[spaceman375]

/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:False

[Anonymous Coward]

I've got 4 on this laptop (built-in NIC and wifi plus 2 USB Ethernet), and udev doesn't seem to have any problems whatsoever keeping them all straight.

Re:False

[Anonymous Coward]

Wrong, udev handles this very fine. This is a complicated solution to a non-problem.

I am afraid that it is YOU, Mr. Bond, who is very much mistaken. Just this weekend I added a SATA card to my old firewall machine. On reboot, eth0 and eth1 were swapped. This happened on Fedora 9, then happened again on Fedora 14.

Re:False

[n7ytd]

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?

Re:False

[Kymermosst]

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:False

[jvillain]

I specialize in Linux administration and have never had issues even in monster deployments. But guys switching over from Solaris on Sparc seem to go into a melt down over the ethx scheme.

Re:False

[Anonymous Coward]

Never identify ports by MAC address. What happens when an Ethernet card or your motherboard dies?

Re:False

[jwillis77845]

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 naming always comes up the same way.. but you can't do that initially. The randomness is generally a matter of revision to the motherboard hardware, assignment of MACs burned into the Ethernet controllers, or re-arrangement of the physical wiring of the network plugged into each port.. in this age when VLANs are popular on home networks.. its really a huge problem if your trying to automate things.. look at Microsoft APIPA or whatever its called this hour..

One manufacturer actually built in a delay so that the non-preferential ports came up (initialized) after the preferred one to give it a head start. UDEV is the right idea.. but its half and idea and not the complete solution.. its needs a partner in crime to complete its mission.. there needs to be a pre-boot kernel phase that can run specialized routines custom to the environment and user.. EFI is a thought.. but its not widely available or deployed yet.. EFI-X not withstanding.

So you need a smart enough bootloader to "help out".. writing custom bootloaders is no small task.. so an api for writing short routines is much preferred. Debian, SuSE, Red Hat all use bootloaders with enough smarts to help sort things out.

This is also important when using virtual machine motion to migrate from one node in a vm cluster to another, or performing P2V the rules change and UDEV becomes dislodged with its certitude that its the correct authority for naming information. Effectively it becomes "outdated" and your back to doing your own plubing with your own flashlight essentially you become the sophisticated automated script for reconfiguring your server.. try that for 150 or 300 blades or virtual servers.. it gets old fast.

Re:False

[jwillis77845]

Just one other common everyday thought.

Suppose you get all this perfecto.. and someone installs a PCI ethernet card.. kinda invalidates a lot of server assumptions.. but also workstation assumptions about ordering if you don't initialize the hardware and perform some probing.

Another thought I wasn't clear on.. was you can run a postinstall script to cleanup udev and figure out your network situation.. but if your depending on that ethernet for install media.. it will never finish.

Ultimately you probably "lock" the UDEV rule to name based on an invariant like MAC address.. but even that's not invariant.. it has the same vulnerability as IPv4 to number exhaustion or accidental hi-jacking. It works ok so far, but in theory when motherboards are a few atoms across and ubiqious as H2O molecules.. it will become a problem.

Re:False

[jwillis77845]

Because one vendor will champion one linux distro over another and the installer for this or that linux distro will prioritize based on a different mechanism or none at all, from RHEL3 to RHEL5 (WS,AS,ES) it varied even between update releases.. and sometimes it was based on PCI order sometimes on MAC order, other times based on the dhcp server that responded quickest on an interface. All over the map. The problem was there were "no standards" for enumeration because the hardware manufacturers had no "standards" or directives to ensure a single detection mechanism would be supported. This had a lot to do with the installer, Anaconda versus the Debian installer versus lots of homebrew or custom installers (they all seemed to have their own way or no way to preconfig names uniquely) In the olden days like 4 years ago a multi-homed server was almost unheard of.. and linux was thought of more as a desktop or embedded OS which again pointed towards a singular or small number of NICs.

It was actually recommended in those days to disable or add additional NICs after initial install.. or to not use network interfaces for provisional media.

Another recommendation was.. put all the NICs on the same subnet for install and sort them out later after you had a running network.. and or manually write udev rules to "lock" them after install.

Re:False

[msauve]

If you don't track interfaces by MAC, what happens when you simply move the NIC to a different slot to make room for a different board (say, adding a double-wide graphics card)? Never say "never." What works best can vary by system/application/person.

I would say it's more reasonable to expect to have to make config changes when replacing hardware (new NIC or MB, as you said), than to have to make changes when simply moving the same hardware within a system.

Re:False

[lederhosen]

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:False

[joib]

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

IIRC the justification for this is that using ethX would race with the original kernel names. This thingy is based on udev, when the kernel boots devices are given ethX names and then udev rules rename them according to bios names, or PCI bus order etc.

Re:False

[mdomsch]

@lordholm: the initial assignment is non-deterministic; not quite random, but not necessarily the order you assume. On many systems, the on-board NICs are discovered after some PCI slots are scanned, on others, the on-boards are scanned first.

Re:False

[mdomsch]

ethX is the kernel-assigned namespace. All the initial device naming happens in parallel by the kernel, with a lock on the bits that hand out the next available integer value. Renaming then also happens in parallel, and they all race. The simple swizzle of eth0eth1 through rename scripts can leave a system with both eth0 and eth0_rename -named devices, not what you had in mind. The only way to avoid the races is to move out of the ethX namespace and into another. I wish that weren't so - this bit is what has kept this feature from happening for 4 years - I didn't want to change namespaces. In the end, I had no choice.

Re:False

[breagerey]

this is a non issue
I've built good number of clusters over the years using various hardware (very often 1u dual port machines) and completely automated installs for hundreds of compute nodes.
I can't even recall the last time I saw this issue.

Re:False

[petermgreen]

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 hardware and things are far from certain.

Because udev just happens to other people?

[Xargle]

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

Silly

[Rysc]

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?

Re:Silly

[rjstanford]

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 - typically you don't have two identical items plugged into USB ports in such a way that the server would break if they were reversed.

Now, many server boxes just use these ports to create wider, redundant pathways to the same destination - but many do not. On those that don't, this type of consistent naming would be very helpful indeed.

The average user shouldn't notice any difference, but then the average user's machine shouldn't be using static configuration anyway :)

Re:Silly

[Rysc]

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

Re:Silly

[Anonymous Coward]

The BSDs have always named ethernet interfaces based on make and model. The names look arbitrary at first but once you know fxp means an Intel NIC and msk means a Marvell NIC, etc. it becomes easier to manage your interfaces.

I always wondered why Linux did not adopt a similar naming convention.

Re:Silly

[Anonymous Coward]

Say you have 4 Intel NICs on the motherboard and an additional PCIe card which provides another two. Which physical port is fxp3? Is it the last onboard (0/1/2/3, 4/5) or the second onboard (0/1, 2/3/4/5)?

What the h**k!

[VincenzoRomano]

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

The original article is here

[Xargle]

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

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

Application compatibility?

[h00manist]

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?

Re:Application compatibility?

[xororand]

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:Application compatibility?

[greed]

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 got bond0, eth0, eth1, and lo--and you absolutely SHOULD NOT attempt to play with eth0 or eth1 directly on that host.

Re:Application compatibility?

[afidel]

Unless you're trying to use wireshark to diagnose a bonding problem =)

Not a good idea....

[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 multiple Ethernet interfaces exist in a computer, I think he is DEAD WRONG. My own experiences with multiple Ethernet interfaces in the same Redhat/Fedora Core Linux computer have always been predictable...and I have used Fedora Core since it was called Redhat 4.0 (still have the original box to prove it and once had "paid support" with Redhat). I have used Ethernet interfaces from the same vendor, even the same model from the same vendor (in some cases a few MAC addresses apart), as well as mixed-vendor setups. Never an issue. NEVER. IMHO multiple network card detection and support in Linux has gotten better over the years.

I think this Redhat engineer is just looking for work to do...or trouble to cause...depending on your point of view, of course.

Re:Not a good idea....

[Anonymous Coward]

Fedora "Core"? 2006 called, they want their distro name back.

Re:Not a good idea....

[ookaze]

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.

Re:Not a good idea....

[Bob Loblaw]

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 location. Those with 2 or less will have to do little to no work in order to adapt to a change in nomenclature.

This change won't affect desktop people at all. The vast majority only have one NIC and they don't even know/care what it is called since Network Manager takes care of everything. Also, there are bug days being scheduled tomorrow to make sure that all the wrongly hard-coded scripts and programs are flushed out and fixed so hopefully we have a more manageable system going forward. If you care, participate in the bug days so that this change can be seamless:

https://fedoraproject.org/wiki/Test_Day:2011-01-27_Network_Device_Naming_With_Biosdevname

Re:Not a good idea....

[afidel]

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

Hmm isn't that what udev is for?

[/.Rooster]

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:Hmm isn't that what udev is for?

[sqldr]

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.

bah....

[bassimat]

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

Article is a joke and false

[adosch]

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.

Re:Article is a joke and false

[characterZer0]

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.

Re:Article is a joke and false

[Deleriux]

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.

Re:Article is a joke and false

[lingon]

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:Article is a joke and false

[0racle]

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.

Re:Article is a joke and false

[NitroWolf]

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.

Re:Article is a joke and false

[adosch]

Agreed. I just dealt with that very problem last night with a virtual machine under VMware Server. However, the OS, IMHO, should handle device naming transparently and statically enough that you aren't guessing every time your system comes up. But, you can't blame a distro's boot strapping and persistent device naming for that issue either because you introduced it with a virtual hardware abstracted layer that does wonky VM NIC mapping that isn't consistent.

FINALLY this will be fixed.

[brunes69]

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.

Re:FINALLY this will be fixed.

[ookaze]

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.

Re:FINALLY this will be fixed.

[Anonymous Coward]

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

Under Linux?

Try collecting data from /sys/devices/

Re:FINALLY this will be fixed.

[mvdwege]

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:FINALLY this will be fixed.

[lingon]

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?

/dev/disk/by-id/

[bill_mcgonigle]

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.

Re:/dev/disk/by-id/

[isopropanol]

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.

Re:/dev/disk/by-id/

[Richard W.M. Jones]

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.

Re:/dev/disk/by-id/

[bill_mcgonigle]

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 initramfs hell).

Re:/dev/disk/by-id/

[bill_mcgonigle]

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

Re:/dev/disk/by-id/

[Richard W.M. Jones]

You can change the underlying disks - we do this for virt-v2v.

Fixing /dev/disk stuff is just one of the things that makes conversions harder than they should be.

RAID/md is not used much by virtual machines (it's done on the host instead) so I can't comment on what problem you had.

Rich.

Re:/dev/disk/by-id/

[isopropanol]

It will break if changing motherboard models, not just swaping a failing motherboard for an identical replacement. Replacing HDDs is part of normal system maintenance; replacing the motherboard (thus probably chipset, ethernet, CPU, RAM, etc) with a different model is a system change project anyways, and will likely require substantial tweaks throughout.

Sometimes...

[Kludge]

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.

Re:Sometimes...

[smooth wombat]

Recently I was swapping NIC cards in and out of my server

NIC cards? Really?

Re:Sometimes...

[HarrySquatter]

Yes. NIC = Network Interface Controller. So what's the deal with calling them network interface controller cards?

re multiple eth

[freddieb]

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.

Epic FAIL!

[Anonymous Coward]

Making the naming consistent does *not* require using new names.

good idea

[LoganDzwon]

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

[Junta]

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:Please no...

[Junta]

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.

Keep ethX, make it unambiguous

[Wormholio]

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:Keep ethX, make it unambiguous

[Junta]

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.

Is wired/Eth confusing? Nah, But Wireless is!

[Anonymous Coward]

There are plenty of posts here about hardwired interfaces. Survey seems to say that udev and /dev/disk/by-id/ current provide enough flexibility.

Is it possible to say the same of wireless networks, given the rapidly evolving environment we're part of? I say we should focus on the dynamic nature of wireless, and handle device naming, prioritization. security and routing.

Can we take a look at how these things work and fix these entwanglements? (TM)

Like the healthcare debate, lets fix whats broken, not re-invent the whole magilla.

Noooo Change is hard!

[1_brown_mouse]

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.

Re:Noooo Change is hard!

[lingon]

Straight forward? I would say assuming that pci0 is a network device is pretty non-straight-forward ...

Re:Noooo Change is hard!

[sclark46]

what is so consistent about em0 and pcixxx

Re:Noooo Change is hard!

[deckert_za]

It might not be that consistent. It means that the device name will change with every new technology that comes out. pci2#1, then pcie3#4, then usb3#9, then superbus7#2.

--deckert

Fedora isn't going to change it for everyone. [2]

[Anonymous Coward]

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

Uniqueness of IDs not enough (bad info is bad)

[IBitOBear]

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 enough, once you are part of "a system" (q.v. a network or server farm) the problem can be magically moot. IPV6 will solve most of your internal/external network topology questions once you have established your anchor machines (routers). Explicit naming of media (Volume Labels, LVM names, metadevice names) will solve the media topology issues. etc.

The only "impossible" topology is dynamic USB as the standard doesn't provide any means for tagging, say, which of which serial adapters are connected to what devices. They get ttyUSB(X) names in probed-then-plugged order and there are several semi-universal chips used to connect a large number of devices (touch screens, GPS, raw serial adapters, etc) that all report just the serial chip's vendor and part id's.

All of the solutions that involve implicit tagging by arbitrary value (MAC) or bus topology (PCI bus ID, USB bus ID, SCSI bus LUN, etc) will have just as many drawbacks as arbitrary naming, but they won't seem to have those drawbacks until after they get instituted as policy and _then_ they bite you.

Bad information, especially when it is only occasionally bad, is always worse than no information.

Fedora - the new face of EVIL

[Anonymous Coward]

Let's break compatibility for a narrow market segment!

Re:Fedora - the new face of EVIL

[Kymermosst]

Exactly what compatibility is broken?

If you are relying on all of your Ethernet devices to be named ethX instead of using the output of ifconfig or looking in sys/class/net, you are doing something wrong.

In fact, the system I am looking at now has four interfaces that are not named ethX. bond0, dummy0, sit0, and lo. Every piece of software I use that works with Ethernet devices seems to have no problem with this.

Re:Fedora isn't going to change it for everyone. [

[PPH]

THERE IS NO NEED TO PANIC.

You're new to Slashdot, aren't you?

Is reading the manual too hard?

[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 physical location of the device, or properties like the device's serial number. Rules can also request information from external programs to name a device or specify a custom name that will always be the same, regardless of the order devices are discovered by the system.

Is this a solution to a problem that doesn't exist? I can however see how the new naming scheme looks tidy.. but then again - we do not want to know about the underlying hardware when in userland, do we?

Re:Is reading the manual too hard?

[jwillis77845]

Problem is you need to know the MAC address association with the port number. And/or which LAN which port is connected to apriori.

Agree, but IME they should fix udev's net rules.

[whovian]

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.
 

It's about consistency across multiple systems

[Anonymous Coward]

jnelson4765 is right. It is about consistency when provisioning large numbers of machines, such as virtual servers. You want to be able to predict the interface assignments, so that physical and ethernet (VLAN) connectivity can be done consistently. For example, if I am provisioning 100 servers of the same model into my farm of virtual servers, I want to be able to reliably predict which interface will be connected to a VLAN. I don't want to have to do a scripted hack to determine that on machine1 eth0 is on the production VLAN, but on machine2 eth0 is on the management VLAN. This solves that problem. With this, I can take a server WITH NO OPERATING SYSTEM ON IT and physically connect the embedded NIC to the management VLAN and the PCI NIC to the production VLAN and know ahead of time which interface names will be connected to each VLAN. Without this method, I will still get persistency across reboots, but may not get consistency across multiple systems.

There is a way.. it has been solved before.. 2005

[jwillis77845]

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 believe the "convention" was to order eth0-ethX by the PCI discovery order on the PCI buss.. but while stable for one machine.. as soon as a new rev of that motherboard came out or a new chipset emerged.. blewy.. right in the middle of a build on thousands of servers. Eventually Peter Anvin with Syslinux bootloader and PXE fame began making available some plugin modules to pre-probe or assess the situation before loading the kernel and passing a custom kernel argument to the booting OS.. be that linux, windows.. whatever.. which looked very very promising. Even worked with WinPE.. awesome. But the problem is still very generic and germane to lots of hardware.. even hard drives or storage LUNs.. to avoid violating the rule "do no harm" a system booting with unknown hardware is left untouched.. just in case it formated with a pattern of file system that is not recognizable.. like GPT or HPFS+ It gets even more mind blowing when you consider java virtual machines and virtual cloud vm support systems.. how do you know what you don't know.. if you didn't build the entire system? Fair warning.. I used to work at HP.. but we tackled this problem.. and did win the day.. but you could only do it in a software+hardware company+opensource sort of way.. Long term.. i think the best way would be a plugin for Syslinux that supported snmp read-only probing for basic ethernet, pci bus and possibly storage device signatures. In thoery this would solve the entire problem and be supportable far into the future.. but I never got a chance to execute on it. GrubPXE also shows a lot of promise in the same area. Bootloaders and Partiton management are vastly underrated for all systems.

Fedora is first, but not alone

[Anonymous Coward]

If you all would actually read the article, you would have read that while Fedora is the first to implement this, other popular distributions such as Ubuntu. Quoting from the article:

> Although Fedora is shipping biosdevname first, other Linux distributions are also expected to adopt it.
> There is reportedly a blueprint for integrating this in Ubuntu 11.04 already and a feature request for inclusion in OpenSUSE as well.

About time something is done

[0x537461746943]

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

I use the fix where you tell udev to ignore ethernet cards and let the normal modprobe.conf load the modules.

/etc/udev/rules.d/10-local.rules add the following:

SUBSYSTEM=="pci", SYSFS{class}=="0x020000", OPTIONS="ignore_device"

What about udev-mapping?

[GioMac]

I thought it was already done partially, and actually is :))

http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming

What is the benefit? In using same configuration when moving OS from one server to another?

Yeah, actually that is ugly thing - I am tired of rewriting MAC addresses, but maybe I want it so! :)

[root@Fedora ~]# cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x8086:0x108c (e1000e) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:30:48:01:ab:cd", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x109a (e1000e) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:30:48:02:ab:cd", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

Link to Matt's Linux Naming Article PDF

[jwillis77845]

Matt also wrote some good articles over the years on the problems, seems like another one every few years http://www.dell.com/downloads/global/power/ps1q07-20060392-Domsch.pdf

It's a very thought provoking topic.

DKMS and EDD - more unique naming tools

[jwillis77845]

More on the topic of uniquely naming indexed or discovered hardware on a system under Linux so it always gets the same name http://www.delltechcenter.com/page/Linux+Projects [delltechcenter.com] Terrific brain teasers - they're like fermat's last theorem except for servers and workstations

You can delete the persistent rules, you know?

[Markos]

If you want to clear the rules, go to /etc/udev/rules.d and delete the persistent net rules file. The new mac will then default to eth0 again. Or edit the rules file to your hearts content.

/dev files

[multi io]

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.

uhhhhh yeah.

[chmod a x mojo]

What happened to scripting the installer to write up a simple HAL / UDEV rule for persistent interface names? Even two cards that are the same model and manufacturer have enough unique IDs at kernel level to have them named persistently.

Most times the devices won't even be the same manufacturer much less model making it even easier. I have named mine that way for quite a while already....

Why not use debian rules ?

[Anonymous Coward]

# cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x14e4:0x164c (bnx2)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:13:72:62:58:a2", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x14e4:0x164c (bnx2)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:13:72:62:58:a4", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"