Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Fedora 15 Changes Network Device Naming Scheme

timothy posted more than 3 years ago | from the shock-horror-horror-shock dept.

Networking 132

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

cancel ×

132 comments

Sorry! There are no comments related to the filter you selected.

frist post (-1)

Anonymous Coward | more than 3 years ago | (#35006902)

lol

Does this mean.... (2)

xgadflyx (828530) | more than 3 years ago | (#35006914)

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.... (3, Informative)

LordFolken (731855) | more than 3 years ago | (#35007104)

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

Random BedHead Ed (602081) | more than 3 years ago | (#35008410)

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.... (3, Interesting)

Entrope (68843) | more than 3 years ago | (#35008662)

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

drsmithy (35869) | more than 3 years ago | (#35008792)

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 ?

We did this years ago (1)

jnelson4765 (845296) | more than 3 years ago | (#35006930)

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 (1)

i.r.id10t (595143) | more than 3 years ago | (#35007278)

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 (1)

isama (1537121) | more than 3 years ago | (#35008948)

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 (1)

petermgreen (876956) | more than 3 years ago | (#35010578)

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.

still a crappy solution (2)

WatchMaster (613677) | more than 3 years ago | (#35006946)

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 (1)

lordholm (649770) | more than 3 years ago | (#35007054)

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 (1)

X0563511 (793323) | more than 3 years ago | (#35009294)

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

Re:still a crappy solution (1)

lordholm (649770) | more than 3 years ago | (#35010110)

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 (1)

TemporalBeing (803363) | more than 3 years ago | (#35011022)

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 (1)

Carewolf (581105) | more than 3 years ago | (#35007554)

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 (0)

Anonymous Coward | more than 3 years ago | (#35007626)

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 (1)

WatchMaster (613677) | more than 3 years ago | (#35007714)

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 (2)

A nonymous Coward (7548) | more than 3 years ago | (#35008482)

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 (1)

WatchMaster (613677) | more than 3 years ago | (#35009746)

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.

False (4, Interesting)

Issarlk (1429361) | more than 3 years ago | (#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.

Re:False (0)

Anonymous Coward | more than 3 years ago | (#35007016)

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 (2)

Issarlk (1429361) | more than 3 years ago | (#35007318)

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 (1)

mathew7 (863867) | more than 3 years ago | (#35007508)

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 (1)

lordholm (649770) | more than 3 years ago | (#35007036)

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 (4, Informative)

jnelson4765 (845296) | more than 3 years ago | (#35007046)

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 (0)

Anonymous Coward | more than 3 years ago | (#35007150)

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 (1)

Rudeboy777 (214749) | more than 3 years ago | (#35007240)

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 (2, Insightful)

Anonymous Coward | more than 3 years ago | (#35007238)

<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/ (2, Interesting)

bill_mcgonigle (4333) | more than 3 years ago | (#35007388)

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/ (2)

isopropanol (1936936) | more than 3 years ago | (#35009352)

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/ (1)

bill_mcgonigle (4333) | more than 3 years ago | (#35010206)

/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/ (1)

Richard W.M. Jones (591125) | more than 3 years ago | (#35009952)

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/ (1)

bill_mcgonigle (4333) | more than 3 years ago | (#35010140)

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/ (1)

Richard W.M. Jones (591125) | more than 3 years ago | (#35010226)

You can change the underlying disks - we do this for virt-v2v [fedorahosted.org] .

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

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:False (2)

discord5 (798235) | more than 3 years ago | (#35007794)

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 (5, Interesting)

msauve (701917) | more than 3 years ago | (#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).

Re:False (1)

spaceman375 (780812) | more than 3 years ago | (#35009222)

/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 (1)

n7ytd (230708) | more than 3 years ago | (#35010480)

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 (1)

Kymermosst (33885) | more than 3 years ago | (#35011076)

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 (1)

sgbett (739519) | more than 3 years ago | (#35007058)

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 (2)

mvar (1386987) | more than 3 years ago | (#35007082)

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

Re:False (0)

Anonymous Coward | more than 3 years ago | (#35009776)

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 (1)

jvillain (546827) | more than 3 years ago | (#35011618)

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.

Sometimes... (2)

Kludge (13653) | more than 3 years ago | (#35007562)

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

smooth wombat (796938) | more than 3 years ago | (#35008260)

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

NIC cards? Really?

Re:Sometimes... (1)

HarrySquatter (1698416) | more than 3 years ago | (#35008450)

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

Re:False (1)

GameboyRMH (1153867) | more than 3 years ago | (#35008580)

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 (0)

Anonymous Coward | more than 3 years ago | (#35009870)

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.

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

whovian (107062) | more than 3 years ago | (#35010118)

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.
 

Because udev just happens to other people? (1)

Xargle (165143) | more than 3 years ago | (#35006978)

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

Uniqueness of IDs not enough (bad info is bad) (1)

IBitOBear (410965) | more than 3 years ago | (#35009272)

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.

Silly (1)

Rysc (136391) | more than 3 years ago | (#35007002)

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 (1)

rjstanford (69735) | more than 3 years ago | (#35007108)

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 (1)

Rysc (136391) | more than 3 years ago | (#35007168)

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 (0)

Anonymous Coward | more than 3 years ago | (#35009658)

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.

What the h**k! (1)

VincenzoRomano (881055) | more than 3 years ago | (#35007080)

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

FINALLY this will be fixed. (1)

brunes69 (86786) | more than 3 years ago | (#35007366)

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

ookaze (227977) | more than 3 years ago | (#35008016)

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

mvdwege (243851) | more than 3 years ago | (#35008556)

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

lingon (559576) | more than 3 years ago | (#35009526)

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?

Re:FINALLY this will be fixed. (0)

Anonymous Coward | more than 3 years ago | (#35008282)

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/

Application compatibility? (2)

h00manist (800926) | more than 3 years ago | (#35007138)

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? (1)

xororand (860319) | more than 3 years ago | (#35007364)

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? (1)

greed (112493) | more than 3 years ago | (#35009328)

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? (1)

afidel (530433) | more than 3 years ago | (#35011264)

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

Not a good idea.... (1)

Anonymous Coward | more than 3 years ago | (#35007142)

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

Anonymous Coward | more than 3 years ago | (#35007642)

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

Re:Not a good idea.... (2)

ookaze (227977) | more than 3 years ago | (#35008128)

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

Bob Loblaw (545027) | more than 3 years ago | (#35009656)

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 [fedoraproject.org]

Re:Not a good idea.... (1)

afidel (530433) | more than 3 years ago | (#35011458)

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? (2)

/.Rooster (54989) | more than 3 years ago | (#35007188)

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? (1)

sqldr (838964) | more than 3 years ago | (#35010882)

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

bassimat (1983576) | more than 3 years ago | (#35007232)

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

Article is a joke and false (3, Insightful)

adosch (1397357) | more than 3 years ago | (#35007264)

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 (4, Informative)

characterZer0 (138196) | more than 3 years ago | (#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.

Re:Article is a joke and false (1)

NitroWolf (72977) | more than 3 years ago | (#35010100)

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 (2)

Deleriux (709637) | more than 3 years ago | (#35007916)

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 (1)

lingon (559576) | more than 3 years ago | (#35009326)

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 (1)

0racle (667029) | more than 3 years ago | (#35009350)

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 (1)

adosch (1397357) | more than 3 years ago | (#35010886)

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.

re multiple eth (1)

freddieb (537771) | more than 3 years ago | (#35007690)

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! (0)

Anonymous Coward | more than 3 years ago | (#35007796)

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

good idea (1)

LoganDzwon (1170459) | more than 3 years ago | (#35008256)

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

Junta (36770) | more than 3 years ago | (#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:Please no... (2)

Junta (36770) | more than 3 years ago | (#35008460)

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 (1)

Wormholio (729552) | more than 3 years ago | (#35008352)

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 (1)

Junta (36770) | more than 3 years ago | (#35008406)

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! (0)

Anonymous Coward | more than 3 years ago | (#35008440)

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)

1_brown_mouse (160511) | more than 3 years ago | (#35008470)

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! (1)

lingon (559576) | more than 3 years ago | (#35009334)

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

Re:Noooo Change is hard! (1)

sclark46 (969374) | more than 3 years ago | (#35009610)

what is so consistent about em0 and pcixxx

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

Anonymous Coward | more than 3 years ago | (#35009188)

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

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

PPH (736903) | more than 3 years ago | (#35009450)

THERE IS NO NEED TO PANIC.

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

Fedora - the new face of EVIL (0)

Anonymous Coward | more than 3 years ago | (#35009316)

Let's break compatibility for a narrow market segment!

Re:Fedora - the new face of EVIL (1)

Kymermosst (33885) | more than 3 years ago | (#35011266)

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.

Is reading the manual too hard? (1)

Anonymous Coward | more than 3 years ago | (#35009898)

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?

It's about consistency across multiple systems (0)

Anonymous Coward | more than 3 years ago | (#35010600)

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 (1)

jwillis77845 (1983986) | more than 3 years ago | (#35011378)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>