Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Eth0 no more?

lists.us.dell.com

Post reply on HN
Print view View original

11–20 of 53 posts

Re: Eth0 no more?

#11

Post by andrewf »

zdw wrote: post #6

Mac OS X and Linux are the only OS's that I'm aware of that put all ethernet nics in the same device namespace. Everyone else has separate device namespaces for - you might have an fxp0 , rl0, hme0, etc. on any BSD or Solaris machine. Rather than looking in /dev, they really ought to be parsing the output of ifconfig -a .

My primary network interface has just become "en0" again, after being "en1" for about 8 years (the time between my first iBook with 802.11b, and getting a MacBook Air which doesn't have an ethernet port).

Re: Eth0 no more?

#12

Post by rdtsc »

CrLf wrote: post #7
beoba wrote: post #3

Looks like this could solve the problem of network interfaces renaming themselves after reboots. Hooray!

Network interfaces should not rename themselves after reboots. On Red Hat derived distributions, the device name is tied to the MAC address of the interface, so it never changes. On other distributions, "udev" accomplishes the same thing. The only point when interface naming is arbitrary is at installation time, then it stays the same forever. Not only this will add confusion by introducing a bunch of new names for n…

Good point, however, the problem is only half-solved.

If the machine is coldstarted then previous devices could be randomly reshufled. Imagine you have a datacenter with 100 machines and you have some kind of provisioning scheme where you coldstart them often. It would be a nightmare having to run ethtool -p and replug cables.

We have solved the problem by providing a consistent algorithm of sorting all the devices in a udev callback. We have a known set of hardware so we know which cards are add-ons (our machines have 4+ eth ports) and which ones are built-ins. So it works out, however, it would be nice to generalize it somehow.

Re: Eth0 no more?

#13

Post by 16s »

The BSDs have always done this... if I recall correctly, em is an Intel based NIC.

NAME em - Intel PRO/1000 10/100/Gigabit Ethernet device

http://www.openbsd.org/cgi-bin/man.cgi?query=em&apropos=...

Edit: Reading more of that thread I may be off-base here, but naming a network interface em that's not powered by certain Intel chipsets will be very confusing to BSD users. Just my 2 cents.

Re: Eth0 no more?

#15

Post by sciurus »

CrLf wrote: post #7
beoba wrote: post #3

Looks like this could solve the problem of network interfaces renaming themselves after reboots. Hooray!

Network interfaces should not rename themselves after reboots. On Red Hat derived distributions, the device name is tied to the MAC address of the interface, so it never changes. On other distributions, "udev" accomplishes the same thing. The only point when interface naming is arbitrary is at installation time, then it stays the same forever. Not only this will add confusion by introducing a bunch of new names for n…

No, you can still rename interfaces using udev just like you can now. This is largely about ensuring that devices get predictable name at install time. As is pointed out in the LWN comment thread, for anyone who has to provision large number of servers with multiple NICs that connect to different networks this is a godsend.

Ability to rename: http://lists.us.dell.com/pipermail/linux-poweredge/2010-Nove...

Why the eth prefix can't be used: http://lists.us.dell.com/pipermail/linux-desktops/2011-Febru...

More background: http://domsch.com/blog/?p=455

Re: Eth0 no more?

#16

Post by rdtsc »

adobriyan wrote: post #10
CrLf wrote: post #7

Earlier quoted context omitted.

Network interfaces should not rename themselves after reboots. On Red Hat derived distributions, the device name is tied to the MAC address of the interface, so it never changes. On other distributions, "udev" accomplishes the same thing. The only point when interface naming is arbitrary is at installation time, then it stays the same forever. Not only this will add confusion by introducing a bunch of new names for n…

> Network interfaces should not rename themselves after reboots. But that's because PCI bus walk order doesn't change across reboots.

Well it depends. There is a kernel parameter that forces a consistent walk order:

   pci=bfsort
It forces breadth-first device sorting.

But otherwise I understand that devices are detected in parallel and whichever ones return first are designated eth0, eth1 etc.

We had this problem on some machine that have 4+ eth0 devices. We use RHEL|CentOS 5.x (see in the post above how we solved the problem).

Re: Eth0 no more?

#17

Post by mansr »

adobriyan wrote: post #10
CrLf wrote: post #7

Earlier quoted context omitted.

Network interfaces should not rename themselves after reboots. On Red Hat derived distributions, the device name is tied to the MAC address of the interface, so it never changes. On other distributions, "udev" accomplishes the same thing. The only point when interface naming is arbitrary is at installation time, then it stays the same forever. Not only this will add confusion by introducing a bunch of new names for n…

> Network interfaces should not rename themselves after reboots. But that's because PCI bus walk order doesn't change across reboots.

Moving a PCI card to another slot should also not rename the device. With a typical current udev setup, device names are persistent based on MAC address. With this proposal, either the name will change if the bus topology changes, or bus location based names will be _wrong_. As usual the fedora/desktop trolls are breaking perfectly good things for no apparent reason at all.

Re: Eth0 no more?

#18

Post by nailer »

zdw wrote: post #6

Mac OS X and Linux are the only OS's that I'm aware of that put all ethernet nics in the same device namespace. Everyone else has separate device namespaces for - you might have an fxp0 , rl0, hme0, etc. on any BSD or Solaris machine. Rather than looking in /dev, they really ought to be parsing the output of ifconfig -a .

1. Linux gives unique names to each NIC. There are no namespace conflicts, because each NIC alias is unique within devices. I personally do not care about the chipset manufacturer and driver when working on a routing issue.

2. You mean (IIRC) 'ip link show'. ifconfig on linux isn't maintained, and breaks in a bunch of situations (Aliases on VLANs on bonds, for one)

3. And you should of course use python-procfs or your preferred equiv, not parse the output of other tools.

On the article in general: can't you use /dev/by-manufacturer these days or similar? I haven't been working on OS stuff recently so can't remember if that became standard.

Re: Eth0 no more?

#19

Post by nailer »

rdtsc wrote: post #12
CrLf wrote: post #7

Earlier quoted context omitted.

Network interfaces should not rename themselves after reboots. On Red Hat derived distributions, the device name is tied to the MAC address of the interface, so it never changes. On other distributions, "udev" accomplishes the same thing. The only point when interface naming is arbitrary is at installation time, then it stays the same forever. Not only this will add confusion by introducing a bunch of new names for n…

Good point, however, the problem is only half-solved. If the machine is coldstarted then previous devices could be randomly reshufled. Imagine you have a datacenter with 100 machines and you have some kind of provisioning scheme where you coldstart them often. It would be a nightmare having to run ethtool -p and replug cables. We have solved the problem by providing a consistent algorithm of sorting all the devices i…

> If the machine is coldstarted then previous devices could be randomly reshufled.

The detection order would change, but the ifcfg file (RH) or udev rules (SuSE and others) would not change, so your NICs will stay the same these days.

Re: Eth0 no more?

#20

Post by rdtsc »

nailer wrote: post #19
rdtsc wrote: post #12

Earlier quoted context omitted.

Good point, however, the problem is only half-solved. If the machine is coldstarted then previous devices could be randomly reshufled. Imagine you have a datacenter with 100 machines and you have some kind of provisioning scheme where you coldstart them often. It would be a nightmare having to run ethtool -p and replug cables. We have solved the problem by providing a consistent algorithm of sorting all the devices i…

> If the machine is coldstarted then previous devices could be randomly reshufled. The detection order would change, but the ifcfg file (RH) or udev rules (SuSE and others) would not change, so your NICs will stay the same these days.

ifcfg file is auto-generated by the coldstart. But you are right, if we save and restore ifcfg files then it would work. However if this saving and restoring has to be done after machine is coldstarted, its eth0 could be connected to another network completely.
Post reply on HN