Once you have a Linux OS on the server, it's fairly trivial to re-enumerate the
NICs any way you desire.
(well, as trivial as kudzu/udev rules can be).
On SLES 10, you write MAC-addr based udev rules. Here's an example:
# cat 30-net_persistent_names.rules
SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:14:22:12:cc:f9",
IMPORT="/lib/udev/rename_netiface %k eth2"
SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:14:22:12:cc:f8",
IMPORT="/lib/udev/rename_netiface %k eth1"
SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:0e:0c:7e:b9:62",
IMPORT="/lib/udev/rename_netiface %k eth0"
On RHEL 3/4/5, it's even easier. You just modify the "HWADDR=" lines in
/etc/sysconfig/network-scripts/ifcfg-eth*. Here's an example ifcfg-eth0 entry.
HWADDR=00:24:E8:6D:FD:B6
Programmatically setting up these udev rules or HWADDR lines in your
post-install is a pain. But fortunately Matt Domsch wrote a utility to do this
yrs ago. That was a problem solved yrs ago.
As far as interfaces not being called "eth*" being a problem.....
We alias our iSCSI NICs to iscsi0 and iscsi1 all the time. That is, we have an
ifcfg-iscsi0 and ifcfg-iscsi1 config file. As long as you put in that config
file the actual true name by which the OS discovers the interface, you're good.
That is, in ifcfg-iscsi0 you have:
DEVICE=eth2
(purely an example. Your exact enumeration depends on server model/config,
etc.)
It works, no problem. High-level cmds (like ifup/ifdown) work on iscsi0/iscsi1
no problem. Low-level cmds (like ifconfig) work on the underlying actual
devices (eth2/3 in this example). But since this is under iscsid/iscsiadm
control, we essentially never need those low-level cmds. (For consistency, we
name our iSCSI interfaces iscsi0 and iscsi1 as well).
No, I think the *real* problem that Matt is trying to solve is the random
enumeration of the NICs on the vendor-supplied boot image. Which is a big pain
if you have multiple NICs/multiple server models/multiple server configs.
Spike White
[email protected]
PS I don't care about the color of the bike shed, I'm just happy Matt D has
fixed this frustrating time-consuming Linux quirk. (Wish the kernel developers
had accepted this, but it's frankly not a problem for them. Only for us Linux
administrators).
> From: [email protected]
> Subject: RE: Consistent Network Device Naming for LOMs coming...
> To: [email protected], [email protected]
> Message-ID:
> <of5a736686.8970b0ac-on852577dd.004ba921-852577dd.004de...@lyrix.com>
> Content-Type: text/plain; charset="us-ascii"
>
> I think I understand some of the problem.
>
> Here is how I understand things:
> Linux network drivers cannot decide the N in ethN when they scan for NICs.
> The kernel provides "add a network device" and "remove a network
> device" functions only. (I'm guessing here)
> Linux network drivers have no control over when they are initialized. The
> kernel decides which drivers are initialized and in what order.
> Linux network drivers are written by different developers, so the scanning
> algorithm and methods are different for each driver. One driver might
> search the PCI/PCIe address space from the bottom up while another might
> scan from the top down.
> Different kernel versions might call network driver initialization
> functions in a different order.
> A Linux system administrator might load and unload network drivers using
> 'rmmod' and 'modprobe'/'insmod' in random order.
> This means, if you have a Broadcom NIC on the motherboard and an e1000 NIC
> in a PCI slot, if the kernel calls the bcm->initialize() function first,
> then eth0 is the Broadcom NIC and the e1000 driver will be told that eth1
> is the add-in NIC's device. On the other hand, if the kernel calls the
> e1000->initialize() function first, then eth0 is the add-in NIC, and the
> bcm driver will be given eth1 for the motherboard NIC.
> I don't think Linux network drivers have the ability to tell the kernel "I
> want this NIC to be eth0". The kernel decides what the next 'N' should
> be in 'ethN' when a driver says "hey, I want to add a network device to
> your already-existing list of network devices".
>
> Matt said the proposed solution for the kernel was to reserve N "slots"
> for on-board devices.
> I can sort-of understand why it was rejected. What value of N is good
> enough? 2? 4? Someday a motherboard could have 8 NICs.
> Not to mention the non-linearity of ethN assignment that would result.
> Suppose N was 4. If you have a motherboard with 2 on-board NICs, then
> you'd have eth0 and eth1, but no eth2 or eth3. The first add-in NIC
> would be eth4. All scripts that search for all NICs in a system are
> designed to stop once they hit eth2 since it doesn't exist. They'd miss
> eth4.
>
> I don't really like the proposal either, but I don't see how to solve the
> real problem.
> Even if a network driver that detected that the NICs it owns are indeed
> the motherboard NICs and could "take over" eth0 from another network
> driver (moving the old eth0 to a new location like eth3, for example,
> assuming the kernel supposed such a thing), the randomness of ethN
> numbering for all non-motherboard NICs would be a disaster (although
> debatable if it would be any worse than it already is today).
>
> - Brian
_______________________________________________
Linux-PowerEdge mailing list
[email protected]
https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Please read the FAQ at http://lists.us.dell.com/faq
