Donate

Categories

Advert

XHTML

Valid XHTML 1.0 Transitional

Ethernet Interface Naming

As far as I recall the standard for naming Linux Ethernet devices has always been ethX where X is a number starting at 0. Until fairly recently the interface names were based on the order that device drivers were loaded or the order in which the PCI bus was scanned. This meant that after hardware changes (replacing network cards or changing the BIOS settings related to the PCI bus) it was often necessary to replace Ethernet cables or change the Linux network configuration to match the renumbering. It was also possible for a hardware failure to cause an Ethernet card to fail to be recognised on boot and thus change the numbers of all the others!

In recent times udev has managed the interface naming. In Debian the file /etc/udev/rules.d/70-persistent-net.rules can be edited to change the names of interfaces, so no matter the scanning order as long as an interface retains it’s MAC address it will get the correct name – or at least the name it initially had. One of the down-sides to the way this operates is that if you remove an old Ethernet card and replace it with a new one then you might find that eth1 is your first interface and there is no eth0 on the system – this is annoying for many humans but computers work quite well with that type of configuration.

I’ve just renamed the interfaces on one of my routers by editing the /etc/udev/rules.d/70-persistent-net.rules file and rebooting (really we should have a utility like /sbin/ip with the ability to change this on a running system).

I have decided to name the Ethernet port on the motherboard mb0. The PCI slots are named A, B, and C with A being the bottom one and when there are two ports on a PCI card the one closest to the left side of the system (when viewed from the front – the right side when viewed from the read) is port 0 on that card. So I have interfaces pcia0, pcia1, pcib0, pcib1, and pcic0. Now when I see a kernel message about the link going down on one of my ports I won’t have to wonder which port has the interface name eth4.

I did idly consider naming the Ethernet devices after their service, in which case I could have given names such as adsl and voip (appending a digit is not required). Also as the names which are permitted are reasonably long I could have used names such as mb0-adsl, although a hyphen character might cause problems with some of the various utilities and boot scripts – I haven’t tested out which characters other than letters and digits work. I may use interface names such as adsl for systems that run at client sites, if a client phoned me to report Internet problems and messages on the console saying things like “adsl NIC Link is Down” then my process of diagnosing the problem would become a lot easier!

Does anyone else have any good ideas for how to rename interfaces to make things easier to manage?

I have filed Debian bug report #592607 against ppp requesting that it support renaming interfaces. I have also filed Debian bug report #592608 against my Portslave package requesting that provide such support – although it may be impossible for me to fix the bug against Portslave without fixing pppd first (I haven’t looked at the pppd code in question for a while). Thanks to Rusty for suggesting this feature during the Q/A part of my talk about Portslave for the Debian mini-conf in LCA 2002 [1].

9 comments to Ethernet Interface Naming

  • jimcooncat

    I’ve been wrestling with this as well. You’ve come up with a pretty good solution where the naming is based on the placement of the jacks in the case.

    I’ve seen schemes where the network segment are color coded for types of access, like red (unfiltered internet), green (guest clients), blue (storage backend like dedicated DRBD), yellow (private clients). Some stickers next to the nics and you’re quite set, and you could just call the interfaces by the color name.

    But naming by usage has a downside when you make temporary infrastructure changes, like if a NIC fails. Sometimes you never get back to fixing things up correctly.

  • Jan Niehusmann

    Why not use /sbin/ip to change the name of an interface on a running system?
    ‘ip link set eth0 name eth1′ works quite well :-)

  • Matthew W. S. Bell

    PPP connections have the same problem to a greater extent (as kernel PPP link numbers are allocated every time a connection is created) so I have a patch for pppd that sets a specific interface name as the interface is created. I then use the format ppp-.

  • You can do this online easily. After downing the interface try this: /sbin/ip link set eth2 name ETBE

  • Ben Hutchings

    There are some changes on the way to expose BIOS labels for PCI devices: . If you’re using servers from the major OEMs that bother to set those labels, you will then be able to use them in 70-persistent-net.rules as the basis for persistent names.

  • Ewoud Kohl van Wijngaarden

    You can use udevadm trigger to trigger a reload. Like Jeff said, the interface must be down in order to rename it.

    donald ~ # sed -i ‘s/eth0/eth1/’ /etc/udev/rules.d/70-persistent-net.rules
    donald ~ # udevadm trigger
    donald ~ # dmesg | tail -n 1
    udev: renamed network interface eth0 to eth1
    donald ~ #

  • etbe

    Jan, Jeff, and Ewoud: thanks for that information.

    Matthew: Please email me the patch.

    Ben: that’s something to keep in mind for the next time I do a green-fields deployment of big-name servers. But most of the systems I work with are desktop systems and low end servers. Of the real servers I run a mix of DC deployed systems that have only one Ethernet port and virtual servers. I don’t have many real serious servers with lots of ports.

  • John Hughes

    “I did idly consider naming the Ethernet devices after their service, in which case I could have given names such as adsl and voip (appending a digit is not required)”

    That’s what I do.

    I use a dymo machine to stick labels on the pc case/pci card with the name on to make cable insertion easier.

    “But naming by usage has a downside when you make temporary infrastructure changes, like if a NIC fails. Sometimes you never get back to fixing things up correctly.”

    If you’re sloppy you’ll have problems. This is true.