[CALUG] Random Network Interfaces

Thu Apr 14 16:44:16 EDT 2011

I'd like to clarify one thing about the
/etc/sysconfig/network-scripts/ifcfg-ethX files.  AFAIK, specifying the MAC
address here only assigns your networking parameters to that interface if
that MAC and interface name match what is specified in that file with what
has already been configured by the OS via udev.  But it does NOT actually
assign the interface device name to the NIC with the matching MAC address.
This is handled by udev, and if you need to change this you can do so in the
/etc/udev/rules.d/70-persistent-net.rules file.

In fact, if your ifcfg-ethX file information doesn't match what is in the
udev rules, you're going to end up with misconfigured interfaces when you
reboot and networking may not function at all.  I've run into this situation
a number of times due to cloning virtual machines, which of course causes
the MAC addresses to change.  I have to be careful to match the correct MAC
address to the correct device in udev or what I think should be eth0 might
actually be eth2 or similar, then when the ifcfg-ethX scripts run, the OS
starts trying to assign incorrect networks to those physical interfaces.

Kevin

On Thu, Apr 14, 2011 at 12:34 PM, James Ewing Cottrell 3rd <
JECottrell3 at comcast.net> wrote:

>  The key phrase is "once assigned". We are speaking of Initial Assignment
> here.
>
> To restate Bryan's words:
>
> "With Solaris, Sun controls the Sun Platforms" means that "Sun can Decree
> that the BIOS/DMI/Whatever that scans the devices does so in the same order
> as Solaris itself. Furthermore, altho Sun may not control the PC Platform,
> it might be big enough to request a Customized BIOS for the machines it
> sells, or it just might bite the bullet and emulate their scanning order.
>
> Linux, OTOH, has to run everywhere, and has little or no influence with the
> BIOS folks. Anything that works will do, regardless of whether it is
> compatible with another OS.
>
> What I thing Beyan is saying later on is that if the ifcfg-xxx# file
> contains HWADDR=yyyyyy then /dev/xxx# will be associated with the NIC hard
> that has MAC address yyyyyy.
>
> I suppose there are incantations to make
> PXE/Anaconda/udev/bootflags/whatever happy, but in the end it's just easier
> to say "we're using eth2" in the Kickstart Files.
>
> Did I mention that there were two different type of ethernets? Two dual-NIC
> cards.
>
> JIM
>
> On 3/24/2011 10:10 AM, Rajiv Gunja wrote:
>
> On Wed, Mar 23, 2011 at 23:38, Bryan J Smith <b.j.smith at ieee.org> wrote:
>
>> From: Rajiv Gunja <opn.src.rocks at gmail.com>
>> > Summary: What you see on Linux is normal behavior for Linux,
>> > HP-UX, AIX, Irix and Solaris.
>>
>>  Not quite.
>>
>> With HP-UX, HP controls the PA-RISC platform.
>> With AIX, IBM controls the POWER platform.
>> With Irix, SGI controls the MIPS and IA-64 platforms.
>> With Solaris, Sun controls the Sun platforms.
>>
>>  >>>> Guess you did not read what I wrote. In all the above Operating
> Systems, irrespective of the platform, the hardware name once assigned will
> not change unless you move the physical location of the network card or
> peripheral, on their respective bus. This is true even on convexOS and
> OSF/1.
>
> >>>> By the way, Linux distros are available on SPARC, IA-64, MIPS and
> POWER platforms and it behaves exactly the same way. Granted that each
> platform will have its own way of naming the peripheral depending the driver
> and kernel module.
>
>
>> Unfortunately for Linux, it does _not_ control the PC platform.
>>  Especially not
>> with the legacy PC BIOS (EFI might be another story).
>>
>>  >>>> What in the world does "_not_control" mean? OSes do not control the
> hardware. OSes are interfaces to the hardware. Kernel of each OS scans the
> hardware in whatever order and presents it to the OS/applications. Yes there
> are helpers to each platform: eeprom, bios, etc. But the underlying
> principle is the same.
>
> >>>> Same thing goes for EFI, it too is an interface for the underlying
> hardware. If the OS is EFI aware, then it makes use of it. Of course that
> seems redundant as none other than OSX seem to use it at the moment.
>
>
>> So when it comes to assigning devices to names, it's not exacting by
>> default,
>> because of how the PC can rescan/reorder things.
>>
>>  >>>> Isn't that what I said? each OS will perform a scan in a certain
> order and that remains constant, that is why we were able to install images
> on our Dell servers without having to look at each hardware to see if the OS
> assigned eth0 or eth2 for the first network interface. (Solaris eeprom scans
> the last bus first)
>
>  Fortunately, if you set the MAC in the ifcfg-(device) files (under
>> /etc/sysconfig/network-scripts) on a Fedora-based system, you will always
>> get
>> that MAC assigned to the (device).  That is how it has been since around
>> Fedora
>> Core 4 or so. To tie down other hardware assignments, udev is utilized,
>> such as
>> for fixed disks.
>>
>>  >>>> I would not suggest changing mac address, unless you are sure that
> there will be no other machine with the same address. Plus I do not see a
> point to changing mac address, as it is unique to each network card
> manufactured around the world.
>
>>
>> --
>> Bryan J  Smith       Professional, Technical Annoyance
>> Linked Profile:     http://www.linkedin.com/in/bjsmith
>> ------------------------------------------------------
>> LS3 Z51:  When you absolutely, positively need to pass
>> that "Smart Car" by accelerating 60-100mph in 3rd gear
>> in around 4s so you can shift back to 6th gear and get
>> the same 30mpg at 75mph he struggles to get at 65mph+.
>>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.894 / Virus Database: 271.1.1/3527 - Release Date: 03/24/11 15:34:00
>
>
>
>
> _______________________________________________
> CALUG mailing list
> CALUG at unknownlamer.org
> http://lists.unknownlamer.org/listinfo/calug
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.unknownlamer.org/pipermail/calug/attachments/20110414/73649e29/attachment.htm 