I&#39;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&#39;t match what is in the udev rules, you&#39;re going to end up with misconfigured interfaces when you reboot and networking may not function at all.  I&#39;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">&lt;<a href="mailto:JECottrell3@comcast.net">JECottrell3@comcast.net</a>&gt;</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 &quot;once assigned&quot;. We are speaking of Initial
    Assignment here.<br>
    <br>
    To restate Bryan&#39;s words:<br>
    <br>
    &quot;With Solaris, Sun controls the Sun Platforms&quot; means that &quot;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&#39;s just
    easier to say &quot;we&#39;re using eth2&quot; 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">&lt;<a href="mailto:b.j.smith@ieee.org" target="_blank">b.j.smith@ieee.org</a>&gt;</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 &lt;<a href="mailto:opn.src.rocks@gmail.com" target="_blank">opn.src.rocks@gmail.com</a>&gt;<br>
          <div>&gt; Summary: What you see on Linux is normal
            behavior for Linux,<br>
            &gt; 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">&gt;&gt;&gt;&gt; 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">&gt;&gt;&gt;&gt; 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">&gt;&gt;&gt;&gt; What in the world does
            &quot;_not_control&quot; 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">&gt;&gt;&gt;&gt; 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&#39;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">&gt;&gt;&gt;&gt; Isn&#39;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">&gt;&gt;&gt;&gt; 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 &quot;Smart Car&quot; 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>