Ethernet device naming

Topics in this article

What's the "right" name for an ethernet device?

When you have several NICs on a system, the chassis silkscreen label and BIOS-given name for an ethernet device (e.g. "Gb1", "Gb2") may not map to the expected Linux device name (e.g. "eth0" and "eth1" respectively), but instead maps to another name (e.g. "eth1" and "eth0" respectively, which can be considered backwards).  This is highly confusing to system admins with such hardware.
 
Over the past year I've developed 3 separate "fixes" – each more generic than the last.

1) a kernel patch in 2.6.19-rc3, which implements "pci=bfsort".

2) name_eths, scripts that modify on-disk config files (/etc/sysconfig/network-scripts/ifcfg-eth* HWADDR lines on Red Hat / Fedora systems; /etc/udev/rules.d/30-net_persistent_names rules on SLES/OpenSuSE).

Because there was no explicit information available from the BIOS to know what names to use, these relied on heuristics and guesswork.  I wrote a whitepaper  that describes the problems and these solutions, and hinted at a permanent solution to come.

Since then, Dell worked with the SMBIOS Working Group on a proposal, included in the latest SMBIOS version 2.6 DRAFT, to add explicit BIOS device naming assignments to the SMBIOS tables.   See extended Type 9 “System Slots” and the new Type 41 “Onboard Devices Extended Information” for the new data. Future Dell systems will provide this data in their SMBIOS table implementations.  This will let the OS query SMBIOS directly to find out the name a given device "should" have (from the BIOS perspective).

So now, we need a program in the OS to read and use this data.  Introducing

3) bios_dev_name, a udev helper.  For example, a udev rule:

KERNEL=="eth*", ACTION=="add", PROGRAM="/sbin/bios_dev_name -i %k", NAME="%c"

which, given the kernel's name for a device, retreives the BIOS-expected name, and sets it to that.  It also can read the HP OEM-specific SMBIOS table entries and use those too.

We have 15 characters with which to name devices, why should we be limited to using only ethN (for positive integers of N)?

bios_dev_name can use several naming policies.  The one I’m most fond of names the embedded NICs as eth0, eth1, … and names the cards in PCI slots as eth_s3_0, eth_s3_2,   to denote multi-port NICs in PCI slot 3.  This makes it clear when looking at the system which port physically maps to the logical name the OS uses.  This is similar to how network switches work, using a card/port naming convention (e.g. 4/21 is the port on switch blade 4, port 21, as it’s labeled on the chassis).

I'd like to see this incorporated into distros ASAP so we can solve the BIOS name != kernel name problem forever, using explicit data from the BIOS that we've never had before.  I'm also very open to including this udev helper app into udev itself.  This is applicable to i386 and x86_64 architectures at least, likely ia64, and others that have SMBIOS tables and/or the PCI IRQ Routing Table.

About the Author: Matt Domsch

Topics in this article