

Eth0 no more? - PassTheAmmo
http://lists.us.dell.com/pipermail/linux-desktops/2011-February/003757.html

======
iuguy
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
Documentation that references eth0 isn't badly written.

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

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

~~~
nailer
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
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)

~~~
zdw
It's not that it self-perpetuates, it's that nearly every other Unix does it
that way, and thus there's an expectation that ifconfig, if it exists, has
similar functionality on all platforms.

If you're going to deprecate a command, make running the old one either:

1\. Not exist, and thus have the shell throw an "command not found" error

2\. Print a useful message like "Use <newcommand> instead"

3\. Work, but do #2 as well.

The current situation is like leaving a pair of rusty pliers out in the open,
and hiding the brand new socket set when the goal is tightening a bunch of
bolts.

~~~
ominous_prime
I agree wholeheartedly that the old tools should be hidden away, and I assume
that they haven't been, because that will break more things than the actual
renaming of devices. I bet even adding deprecation warnings could cause a
ruckus, seeing how many times I've come across `ifconfig | something` both in
scripts and people shelling out from other languages. I do wish the distros
would just make a clean break, and let people fix their crappy code.

~~~
kelnos
Then you just make the deprecation warning go to stderr instead of stdout. '|'
only redirects stdout.

~~~
ominous_prime
True - I'm just grasping as straws to come up with an excuse as to why this
has gone on for so long.

------
javanix
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
Looks like this
[https://fedoraproject.org/wiki/Features/ConsistentNetworkDev...](https://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming)
is going to be the default in Fedora 15.

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

------
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=...](http://www.openbsd.org/cgi-
bin/man.cgi?query=em&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html)

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
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-...](http://linux.dell.com/files/whitepapers/nic-enum-
whitepaper-v3.pdf)

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

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

~~~
CrLf
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
> Network interfaces should not rename themselves after reboots.

But that's because PCI bus walk order doesn't change across reboots.

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

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

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

------
d135-1r43
I assume any consumer OS will generate a symlink for compatibility reasons.

~~~
sciurus
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/+b...](https://bugs.launchpad.net/ubuntu/+source/network-
manager/+bug/386900)

------
chopsueyar
'know' one knows?

------
BlazingFrog
"... something else that _know one_ will recognise ..."

Really??

