7 ms·

Eth0 no more?

154 points by PassTheAmmo 16y ago

javanix 16y ago
From the limitations section of the wiki page linked in the article: Not all add-in cards have a method to expose their Linux interface name(s) to external port mapping. biosdevname may provide incorrect names for such. Discussions are ongoing on the netdev mailing list to standardize a method of exposing such mapping. Seems like this would be kind of a deal-breaker for any wholesale move like this. I'd be fairly surprised if this got any widespread adoption anytime soon.
- onedognight 16y ago
  Looks like this https://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming https://fedoraproject.org/wiki/Features/ConsistentNetworkDev... is going to be the default in Fedora 15.
beoba 16y ago
Looks like this could solve the problem of network interfaces renaming themselves after reboots. Hooray!
- e1ven 16y ago
  There are a lot of other solutions to that. The Ububuntu one I favored in the 8.x era was /etc/iftab, it's a shame they retired it in favor of udev. While udev is more universal, iftab felt elegant and unixy.
- CrLf 16y ago
  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 network interfaces, it will also break applications that rely on them being called "ethX". It will also make it impossible to manually assign names to interfaces. For instance, if you have a configuration that uses an embedded interface and you want to add another interface on a card, you can manually assign the same "ethX" name to it, but not if the names depend on the physical characteristics of the hardware.
  - adobriyan 16y ago
    > Network interfaces should not rename themselves after reboots. But that's because PCI bus walk order doesn't change across reboots.
    - rdtsc 16y ago
      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).
      - moe 16y ago
        This! I once had a server (in the pre-udev era) that would occasionally shuffle its network devices after reboots. I don't remember how I fixed it but I do remember the short phase of amusement, followed by a longer phase of frustration.
    - mansr 16y ago
      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.
  - rdtsc 16y ago
    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 <dev> 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.
eklitzke 16y ago
There was a pretty good discussion about this on LWN a while back, I recommend it to anyone who wants more information (both the commentary their, as well as the linked article): https://lwn.net/Articles/424859/ https://lwn.net/Articles/424859/
zdw 16y ago
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.
- CrLf 16y ago
  Having all ethernet devices called "ethX" makes it much easier to parse the output of ifconfig and exclude any non-ethernet interfaces (tunnels and such).
- andrewf 16y ago
  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).
- nailer 16y ago
  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.
  - ominous_prime 16y ago
    somewhat OT: > 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) This seemingly simple change seems to be taking forever to gain traction; "use `ip` for network config on linux". There is so much googlable stuff instructing one to use ifconfig, route, etc. that it seems to self perpetuate. I often find people telling others that "you can't do that in Linux", when the real answer is along the lines of "you can't do that with the route command" (to give an example that I've seen a few times recently, route can't manipulate routing tables)
16s 16y ago
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=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 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.
rdtsc 16y ago
Here is a whitepaper from Dell that discusses some of these issues and provides some of the solutions. It is a couple of years old but still relevant: http://linux.dell.com/files/whitepapers/nic-enum-whitepaper-v3.pdf http://linux.dell.com/files/whitepapers/nic-enum-whitepaper-...
spydum 16y ago
People will whine and complain about this, but it's about time some sanity was brought to Linux's network device names. The eth* enumeration has been terrible for quite a long time, especially when dealing with servers housing multiple interfaces. And if you don't like the solution, they explicitly say you can just set biosdevname=0 on the kernel params and carry on with the previous insanity.
chopsueyar 16y ago
'know' one knows?
d135-1r43 16y ago
I assume any consumer OS will generate a symlink for compatibility reasons.
- pnathan 16y ago
  I certainly hope so. There's just way too honking much literature out there oriented on ethX to simply make ethX go away.
- sciurus 16y ago
  Network interfaces aren't files, so you can't create symlinks to them. I don't think linux has a facility for referring to a network interface by more than one name. My hope is that consumer distributions will stop presenting the device name and configuration at all. When I'm trying to show new Ubuntu users how to connect to wired and wireless networks, it's annoying to have to explain what NetworkManager means by "Auto eth0". https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/386900 https://bugs.launchpad.net/ubuntu/+source/network-manager/+b...
BlazingFrog 16y ago
"... something else that know one will recognise ..." Really??
iuguy 16y ago
I can understand why people will resist this, thinking that somehow renaming eth0 to em0 or similar will break stuff, but here's the rub: It'll only break stuff that's badly written. There's a right way to enumerate network interfaces and a wrong way (which is dependent on the language you're using for enumeration - the wrong way is assuming that eth0 is the only network device). Bear in mind that the new convention is not entirely dissimilar to how WiFi cards have worked on Linux for some time, so the only things that will break will be things that: a) Assume eth0 instead of enumerating devices b) Have a legitimate reason for using eth0 only (I can't think of one, but I wouldn't be surprised if one existed)
- nl 16y ago
  Documentation that references eth0 isn't badly written.
  - wglb 16y ago
    How is that? Would you care to elaborate?
  - iuguy 16y ago
    On the surface it would seem like you're correct, but only so in some cases. If for example you're running Linux on a Macbook Air you have no eth0 by default. Ergo, documentation referencing it is technically incorrect - it would be possible to say badly written at this point but that's even more pedantic than your comment ;)
  - pmcginn 16y ago
    Yes it is. Obviously, this is just my anecdotal experience, but the first time I tried to install Linux the troubleshooting documentation I was working off of only mentioned eth0. I tried to configure everything to eth0, and nothing worked. I gave up and swore off Linux for years. Eventually, I tried Ubuntu, where everything worked, and figured it was a driver issue that Ubuntu had solved. I got around to trying out Gentoo, which has amazing documentation that really drills down into what you're doing and why. That's when I ran ifconfig and iwconfig for the first time and realized I probably would have been using Linux years earlier if I had known how to find out that my NIC was wlan0. So I'd say referencing eth0 throughout is fine, as long as at the beginning you take the time to point out that it may not be eth0, and more importantly, how to find out what it is.
samuel1604 16y ago
From a quick look on a fresh ubuntu small server install it does not seem there is much that reference eth* scheme : ~$ sudo egrep -Irl 'eth[0-9]' /etc /usr 2>/dev/null |wc -l 27
deleted 16y ago
[deleted]
dhughes 16y ago
With eth changing to em and mile long IPv6 addresses it's going to be a strange world.

154 points by PassTheAmmo 16y ago

From the limitations section of the wiki page linked in the article: Not all add-in cards have a method to expose their Linux interface name(s) to external port mapping. biosdevname may provide incorrect names for such. Discussions are ongoing on the netdev mailing list to standardize a method of exposing such mapping. Seems like this would be kind of a deal-breaker for any wholesale move like this. I'd be fairly surprised if this got any widespread adoption anytime soon.

onedognight 16y ago
Looks like this https://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming https://fedoraproject.org/wiki/Features/ConsistentNetworkDev... is going to be the default in Fedora 15.

beoba 16y ago

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

e1ven 16y ago
There are a lot of other solutions to that. The Ububuntu one I favored in the 8.x era was /etc/iftab, it's a shame they retired it in favor of udev. While udev is more universal, iftab felt elegant and unixy.
CrLf 16y ago
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 network interfaces, it will also break applications that rely on them being called "ethX". It will also make it impossible to manually assign names to interfaces. For instance, if you have a configuration that uses an embedded interface and you want to add another interface on a card, you can manually assign the same "ethX" name to it, but not if the names depend on the physical characteristics of the hardware.
- adobriyan 16y ago
  > Network interfaces should not rename themselves after reboots. But that's because PCI bus walk order doesn't change across reboots.
  - rdtsc 16y ago
    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).
    - moe 16y ago
      This! I once had a server (in the pre-udev era) that would occasionally shuffle its network devices after reboots. I don't remember how I fixed it but I do remember the short phase of amusement, followed by a longer phase of frustration.
  - mansr 16y ago
    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.
- rdtsc 16y ago
  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 <dev> 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.

eklitzke 16y ago

There was a pretty good discussion about this on LWN a while back, I recommend it to anyone who wants more information (both the commentary their, as well as the linked article): https://lwn.net/Articles/424859/ https://lwn.net/Articles/424859/

zdw 16y ago

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.

CrLf 16y ago
Having all ethernet devices called "ethX" makes it much easier to parse the output of ifconfig and exclude any non-ethernet interfaces (tunnels and such).
andrewf 16y ago
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).
nailer 16y ago
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.
- ominous_prime 16y ago
  somewhat OT: > 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) This seemingly simple change seems to be taking forever to gain traction; "use `ip` for network config on linux". There is so much googlable stuff instructing one to use ifconfig, route, etc. that it seems to self perpetuate. I often find people telling others that "you can't do that in Linux", when the real answer is along the lines of "you can't do that with the route command" (to give an example that I've seen a few times recently, route can't manipulate routing tables)

16s 16y ago

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=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 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.

rdtsc 16y ago

Here is a whitepaper from Dell that discusses some of these issues and provides some of the solutions. It is a couple of years old but still relevant: http://linux.dell.com/files/whitepapers/nic-enum-whitepaper-v3.pdf http://linux.dell.com/files/whitepapers/nic-enum-whitepaper-...

spydum 16y ago

People will whine and complain about this, but it's about time some sanity was brought to Linux's network device names. The eth* enumeration has been terrible for quite a long time, especially when dealing with servers housing multiple interfaces. And if you don't like the solution, they explicitly say you can just set biosdevname=0 on the kernel params and carry on with the previous insanity.

chopsueyar 16y ago

'know' one knows?

d135-1r43 16y ago

I assume any consumer OS will generate a symlink for compatibility reasons.

pnathan 16y ago
I certainly hope so. There's just way too honking much literature out there oriented on ethX to simply make ethX go away.
sciurus 16y ago
Network interfaces aren't files, so you can't create symlinks to them. I don't think linux has a facility for referring to a network interface by more than one name. My hope is that consumer distributions will stop presenting the device name and configuration at all. When I'm trying to show new Ubuntu users how to connect to wired and wireless networks, it's annoying to have to explain what NetworkManager means by "Auto eth0". https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/386900 https://bugs.launchpad.net/ubuntu/+source/network-manager/+b...

BlazingFrog 16y ago

"... something else that know one will recognise ..." Really??

iuguy 16y ago

I can understand why people will resist this, thinking that somehow renaming eth0 to em0 or similar will break stuff, but here's the rub: It'll only break stuff that's badly written. There's a right way to enumerate network interfaces and a wrong way (which is dependent on the language you're using for enumeration - the wrong way is assuming that eth0 is the only network device). Bear in mind that the new convention is not entirely dissimilar to how WiFi cards have worked on Linux for some time, so the only things that will break will be things that: a) Assume eth0 instead of enumerating devices b) Have a legitimate reason for using eth0 only (I can't think of one, but I wouldn't be surprised if one existed)

nl 16y ago
Documentation that references eth0 isn't badly written.
- wglb 16y ago
  How is that? Would you care to elaborate?
- iuguy 16y ago
  On the surface it would seem like you're correct, but only so in some cases. If for example you're running Linux on a Macbook Air you have no eth0 by default. Ergo, documentation referencing it is technically incorrect - it would be possible to say badly written at this point but that's even more pedantic than your comment ;)
- pmcginn 16y ago
  Yes it is. Obviously, this is just my anecdotal experience, but the first time I tried to install Linux the troubleshooting documentation I was working off of only mentioned eth0. I tried to configure everything to eth0, and nothing worked. I gave up and swore off Linux for years. Eventually, I tried Ubuntu, where everything worked, and figured it was a driver issue that Ubuntu had solved. I got around to trying out Gentoo, which has amazing documentation that really drills down into what you're doing and why. That's when I ran ifconfig and iwconfig for the first time and realized I probably would have been using Linux years earlier if I had known how to find out that my NIC was wlan0. So I'd say referencing eth0 throughout is fine, as long as at the beginning you take the time to point out that it may not be eth0, and more importantly, how to find out what it is.

samuel1604 16y ago

From a quick look on a fresh ubuntu small server install it does not seem there is much that reference eth* scheme : ~$ sudo egrep -Irl 'eth[0-9]' /etc /usr 2>/dev/null |wc -l 27

deleted 16y ago

[deleted]

dhughes 16y ago

With eth changing to em and mile long IPv6 addresses it's going to be a strange world.