On Wed, Jul 2, 2008 at 8:14 PM, John Zornig <[EMAIL PROTECTED]> wrote:
> John Haxby wrote:
>
> We were talking about this here the other day. You obviously know about
>> the issues of hardware discovery changing from one kernel release to another
>> and the whether you do a breadth-first search or a depth-first search.
>> The particular case we were talking about was that the hardware doesn't do
>> PCI device detection in a deterministic fashion under some circumstances.
>> It's not quite random, but it's variable enough to bevexing. I'm afraid
>> you're stuck with using HWADDR in the ifcfg-eth* files or using a similar
>> device uuid to distinguish one NIC from another. We suspect that this random
>> behaviour will become the norm in future.
>> jch
>>
> I have a number of Dell systems, running RHEL5.2 suffering badly from this
> issue. They all have two on-board NICs and one or two 2-port or 4-port PCI
> cards.
>
> I can't set HWADDR in the ifcfg-eth* files because most of the NICs are in
> bonded pairs and it is the ifcfg-bond* which has a HWADDR which is shared
> between the two NICs which are slaves to that bond*.
>
> I've just discovered the pci=bfsort kernel parameter yesterday and begun to
> configure it on the systems, but it is too early to say if it works, as the
> issue is random at boot time.
>
> I had no luck configuring udev/rules.d to do HWADDR matching using rules
> like:
> KERNEL=="eth*",DRIVER=="bnx2",SYSFS{address}=="00:1d:09:1e:b0:a9",
> NAME="eth0"
> It seemed to be ignored.
>
> JZ
>
>
John -->
I hope someone more knowledgeable would have answered this by now.
First of all, the udev rules and parameters appears to be a a state of flux
or change. For 5.x, I don't believe that "SYSFS{address}==..." is still
supported.
Next, I believe from my experimentation that using UDEV and locking to
the PCI slot is probably the best way to go (at least for my application).
I
haven't migrated to 5.2 yet, but here is a write-up I did on the CentOS
list for a similar question. I hope it helps ...
============== Forwarded Message =====================
On Sat, Apr 19, 2008 at 3:53 PM, Joseph L. Casale <[EMAIL PROTECTED]>
wrote:
> >Modify /etc/sysconfig/network-scripts/ifcfg-ethX and remove the HWADDR
> >line if you have one, and add a MACADDR with the mac address you want
> >to use.
> >
> >Beware, some network cards may protest having the mac address changed,
> >and using both HWADDR and MACADDR can cause issues. See
> >/usr/share/doc/initscripts-*/sysconfig.txt for details.
>
> Jim,
> I appreciate the confirmation, that was the method I was going to use. I am
> only unsure about what *could* happen with the HWADDR in there, can eth{n}
> now maybe bind to a different nic under some circumstance?
>
> How can I always force the nic in question to use this script?
>
> Thank you!
> jlc
>
Here is an outline of what I do to "lock-down" interfaces -- which relies
mainly on using a fairly new feature "udev":
/etc/modprobe.conf: make sure the lines --
alias eth? <driver>
are in the correct order, e.g.:
alias eth0 e1000
alias eth1 e1000
alias eth2 tg3
/etc/udev/rules.d/: create network rules file (if needed) and
add lines that associate a given NIC to its eth? interface.
Use "udevinfo -a -p /sys/class/net/eth?" to get various
features or attributes to find the NIC that you want to call
eth<X>. [Note: this seems to change from release to
release, so this is a little general.] You might want to put
lines like:
Kernel==eth? ID==0000:03:02.0 Name=eth0
Kernel==eth? ID==0000:03:02.1 Name=eth1
or
Kernel==eth? Sys{vendor}==0x8086 Sys{device}==0x032a Name=eth0
Kernel==eth? Sys{vendor}==0x8086 Sys{device}==0x1079 Name=eth1
/etc/sysconfig/network-scripts/ifcfg-eth<X>:
As other have suggested, now put MACADDR= into these files with the
desired MAC address that you want the interface to be set to and
delete the HWADDR.
Now, reboot, test and repeat as needed:-):-) ...
I hope that helps and is useful ...
-rak-
Note: I just checked a Fedora 8 box and some of the above has
changed -- udev is the way to go, but be advised that this feature
appears to be evolving and changing -- hopefully for the better!
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
