On 7 April 2013, at 16:35, Pandu Poluan wrote: > On Apr 7, 2013 3:56 PM, "Stroller" <strol...@stellar.eclipse.co.uk> wrote: > >> AIUI the motive for these changes are so that you can unpack an >> enterprise-type server, the ones with two NICs on the motherboard, and >> always know which NIC is which. You can then unpack a pallet load of them, >> and deploy them without any need for determining which is which or for any >> manual intervention. This is actually pretty important and useful, but I'm >> not sure this has all been done the best way. > > AFAICT, on-board NICs have sequential MAC Adresses, with the one labeled > "Port 1" has the smallest MAC Address. So far, *all* Linux distros I've used > on a server will reliably name "Port X" as "eth$((X-1))". So it's never a > puzzle as to which port bears which "ethX" moniker.
I would expect this to be the case, too, but I'm told it's not always so - you cannot be certain of it. I think that the kernel allocates interfaces to NICs in the order in which they're found - eth0 to the first one, eth1 to the second, and so on. A pair of on-board NICs may be allocated interface IDs in the same order as their MACs, but they may not be - especially if, for some reason, one responds abnormally slowly to probing from the kernel. A really good long discussion of this is available at [1], see also [2]: Without biosdevname, you get all ethX names - they're just in completely non-deterministic order. Often times after the first non-deterministic order is set in 70-persistent-net.names, and with no other configuration changes to your system, on reboot you'll get those same names for those devices again, but only because no renames are actually taking place - the kernel accidentally names them in the same way each time. You cannot swizzle them within the ethX namespace and have it work - it's racy and failure-prone. You must change out of ethX in order to get consistency at all. > The new naming scheme, however, is much less intuitive. Where originally I > just immediately use eth0, now I have to enumerate the monikers first, > because even between servers of the same model (let's say, HP's DL360 G7), > the PCI attachment point might differ. I agree. However, attempts to solve this in kernel (I think *several* of them), which would have allowed the eth0, ethX namespaces to be retained, were rejected. See [3]. I believe that HP shared involvement in this - I think they collaborated with Dell on how the BIOS would declare the NICs in a way that would be available to the kernel. Stroller. [1] http://marc.info/?l=linux-netdev&m=128163454631618&w=3 [2] http://lists.us.dell.com/pipermail/linux-poweredge/2010-November/043586.html [3] http://marc.info/?l=linux-netdev&m=128518030400371&w=3
