I have an HP ProLiant DL360 G6 containing two onboard NICs as well as an HP NC375T (NetXen NX3031 chipset) 4-port PCIe card. The system was running with eth0 and eth1 belonging to the onboard NICs and eth2-eth5 on the NetXen card. I recently rebuilt the server and from the kickstart process onward, the NICs were reordered such that the onboard NICs became eth4 and eth5, while the NetXen card took over eth0-eth3.

I've had some experiences in the past where I tied NICs to specific interfaces via changes in the ifcfg-ethX config files, but this is the first time I've ever seen an add-in card take over eth0 from the motherboard's interfaces. This impacted my kickstart scripts, so:

1). How can I ensure that the onboard NICs take precedence in the kickstart arrangement.

2). What is the most consistent way to maintain that ordering through repeated reboots, kernel changes (e.g. going from a RHEL mainline kernel to a RHEL MRG realtime kernel), etc.

3). What is the interaction between the /etc/modprobe.conf module/NIC definitions, the /etc/sysconfig/network-scripts/ifcfg-ethX and the /etc/modprobe.d/blacklist functions in this context?


this is a known issue with RHEL5 and derivatives. There are two possible solutions:

  1. keep the HWADDR set up in the ifcfg scripts (you can make it smart y using scripted regex and MAC ranges for different NIC vendors)
  2. use udev rules, again, the MAC is playing a role here

You could use kssendmac option to get the NIC's MAC address sent to the Kickstart script. Parse it out with PHP and configure accordingly.

That way the known variable is the MAC of the onboard NIC and the unknown is the kernel assigned eth device.

This snippet will get and print all the headers. You'll have to come up with something that parses out the information you need. Your network configuration lines will be conditional based on what you get out of this.

$headers = getallheaders();
foreach ($headers as $key => $value)
{ echo "# $key: $value\n"; }

If you need some more help let me know. This should get you going in the right direction, though.


Inserting more than 1 NIC into a server can sometimes causes the new NIC(s) to boot up in their own order, not in the eth0(existing nic) , eth1 (new nic) , eth2 (new nic) order you'd expect

Red Hat/CentOS In Red Hat, for example, if the driver is called "tg3" (the Tigon driver) you simply specify the network name order you want by specifying the eth(x) order by editing

vi /etc/modprobe.conf

alias eth0 tg3

alias eth1 e1000

alias eth2 3com

The above example shows that the tg3 driver will be loaded before the e1000 and 3com kernels.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.