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.<br>
<br>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.<br>
<br>Kevin<br><br><div class="gmail_quote">On Thu, Apr 14, 2011 at 12:34 PM, James Ewing Cottrell 3rd <span dir="ltr"><<a href="mailto:JECottrell3@comcast.net">JECottrell3@comcast.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#ffffff" text="#000000">
The key phrase is "once assigned". We are speaking of Initial
Assignment here.<br>
<br>
To restate Bryan's words:<br>
<br>
"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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Did I mention that there were two different type of ethernets? Two
dual-NIC cards.<br>
<br>
JIM<br>
<br>
On 3/24/2011 10:10 AM, Rajiv Gunja wrote:
<blockquote type="cite">
<div class="gmail_quote">On Wed, Mar 23, 2011 at 23:38, Bryan J
Smith <span dir="ltr"><<a href="mailto:b.j.smith@ieee.org" target="_blank">b.j.smith@ieee.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
From: Rajiv Gunja <<a href="mailto:opn.src.rocks@gmail.com" target="_blank">opn.src.rocks@gmail.com</a>><br>
<div>> Summary: What you see on Linux is normal
behavior for Linux,<br>
> HP-UX, AIX, Irix and Solaris.<br>
<br>
</div>
Not quite.<br>
<br>
With HP-UX, HP controls the PA-RISC platform.<br>
With AIX, IBM controls the POWER platform.<br>
With Irix, SGI controls the MIPS and IA-64 platforms.<br>
With Solaris, Sun controls the Sun platforms.<br>
<br>
</blockquote>
<div><span style="color:rgb(0, 0, 153);font-family:verdana,sans-serif">>>>> 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.</span><br style="color:rgb(0, 0, 153);font-family:verdana,sans-serif">
<br style="color:rgb(0, 0, 153);font-family:verdana,sans-serif">
<span style="color:rgb(0, 0, 153);font-family:verdana,sans-serif">>>>> 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.</span><br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
Unfortunately for Linux, it does _not_ control the PC
platform. Especially not<br>
with the legacy PC BIOS (EFI might be another story).<br>
<br>
</blockquote>
<div><span style="color:rgb(0, 0, 153);font-family:verdana,sans-serif">>>>> 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.</span><br style="color:rgb(0, 0, 153);font-family:verdana,sans-serif">
<br style="color:rgb(0, 0, 153);font-family:verdana,sans-serif">
<span style="color:rgb(0, 0, 153);font-family:verdana,sans-serif">>>>> 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.</span><br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
So when it comes to assigning devices to names, it's not
exacting by default,<br>
because of how the PC can rescan/reorder things.<br>
<br>
</blockquote>
<div><span style="color:rgb(0, 0, 153);font-family:verdana,sans-serif">>>>> 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)</span> <br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
Fortunately, if you set the MAC in the ifcfg-(device) files
(under<br>
/etc/sysconfig/network-scripts) on a Fedora-based system, you
will always get<br>
that MAC assigned to the (device). That is how it has been
since around Fedora<br>
Core 4 or so. To tie down other hardware assignments, udev is
utilized, such as<br>
for fixed disks.<br>
<font style="color:rgb(0, 0, 153);font-family:verdana,sans-serif" color="#888888"><br>
</font></blockquote>
<div><span style="color:rgb(0, 0, 153);font-family:verdana,sans-serif">>>>> 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.</span><br>
</div>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"><font color="#888888">
<br>
--<br>
Bryan J Smith Professional, Technical Annoyance<br>
Linked Profile: <a href="http://www.linkedin.com/in/bjsmith" target="_blank">http://www.linkedin.com/in/bjsmith</a><br>
------------------------------------------------------<br>
LS3 Z51: When you absolutely, positively need to pass<br>
that "Smart Car" by accelerating 60-100mph in 3rd gear<br>
in around 4s so you can shift back to 6th gear and get<br>
the same 30mpg at 75mph he struggles to get at 65mph+.<br>
</font></blockquote>
</div>
<br>
<pre><fieldset></fieldset>
No virus found in this incoming message.
Checked by AVG - <a href="http://www.avg.com" target="_blank">www.avg.com</a>
Version: 9.0.894 / Virus Database: 271.1.1/3527 - Release Date: 03/24/11 15:34:00
</pre>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
CALUG mailing list<br>
<a href="mailto:CALUG@unknownlamer.org">CALUG@unknownlamer.org</a><br>
<a href="http://lists.unknownlamer.org/listinfo/calug" target="_blank">http://lists.unknownlamer.org/listinfo/calug</a><br>
<br></blockquote></div><br>