Assigning eth0 to a particular NIC

More than once, I've found that RedHat assigned eth0 to the card I
intended (and wired) as eth0, and vice versa. I figured there had to be
some way to get Linux to do what I wanted, instead of what it wanted.
And there is.

However, I had so much trouble finding the answer to these questions, I
thought I'd better post the information I found. I've seen several
postings of some variation of this question, and most went unanswered.

What's below works for me . . . but that doesn't guarantee anything for you!

As best I can tell, there are two (2.5?) ways, and two references. My
apologies for any errors: corrections are welcomed.

In Redhat, it appears that you can modify the ifcfg-ethxx files using
the MACADDR and the HWADDR configuration variables. At present, this is
documented here (along with many of the other ifcfg variables):
http://www.redhat.com/docs/manuals/e...nterfaces.html

The MACADDR variable is apparently used to force a particular network
device, say eth0, to report the ASSIGNED MAC, rather than the burned in MAC.

The HWADDR variable is used to force the eth0 device handle to be
assigned to the network interface card (in a mult-NIC environment)
having a MAC = HWADDR.

At least, this is what I *think* happens: I haven't tested it. Some one
more skilled in reading Bash scripts than I may be able to confirm this,
by checking the relevant scripts. It appears that the following scripts
(under RH9) read the HWADDR value:
/etc/sysconfig/network-scripts/ifdown
/etc/sysconfig/network-scripts/ifup
/etc/ppp/plugins/rp-pppoe.so
/etc/pcmcia/wireless

and these read the MACADDR value:
/etc/sysconfig/network-scripts/ifdown
/etc/sysconfig/network-scripts/ifup
/etc/sysconfig/netdump
/etc/rc.d/init.d/netdump
/etc/rc.d/rc0.d/K50netdump
/etc/rc.d/rc1.d/K50netdump
/etc/rc.d/rc2.d/K50netdump
/etc/rc.d/rc3.d/K50netdump
/etc/rc.d/rc4.d/K50netdump
/etc/rc.d/rc5.d/K50netdump
/etc/rc.d/rc6.d/K50netdump
/etc/init.d/netdump
/etc/rc0.d/K50netdump
/etc/rc1.d/K50netdump
/etc/rc2.d/K50netdump
/etc/rc3.d/K50netdump
/etc/rc4.d/K50netdump
/etc/rc5.d/K50netdump
/etc/rc6.d/K50netdump

Only ONE of these variables should be used in a network device
configuration file. I assume that configuring the device handles this
way is persistent over a reboot, but also that it only works with RedHat
installations. Also in RedHat, the "neat" GUI tool can be used to set
these values, but the results some users reported were erratic and
unpredictable.



There's another way, that I HAVE tested. Assignments made this way will
NOT survive a reboot (unless you write a boot script) but the method
should work with most distros. The "ip" program can be used to either
assign a particular MAC to a particular NIC *or* to assign a particular
handle to a particular NIC.

Anyhow, to switch eth0 and eth1 name assignments (and assign eth0 to
the card of MY choice):

ip link set eth0 down
ip link set eth1 down
ip link set dev eth0 name eth9
ip link set dev eth1 name eth0
ip link set dev eth9 name eth1
ip link set eth0 up
ip link set eth1 up

As a script, this takes less than a second to run on my machine.
Documentation for the "ip" tool is found in Alex Kuznetsov's "IP Command
Reference". Here's one copy:
http://linux-ip.net/gl/ip-cref/

Ben


************************************************** *****************
Additional Google keys:

How can you bind an network device handle to a particular NIC?
Binding a NIC to a MAC
How can you bind eth0 to a particular NIC?

On Tue, 04 Nov 2003, Ben <(E-Mail Removed)> wrote:
>
> More than once, I've found that RedHat assigned eth0 to the card I
> intended (and wired) as eth0, and vice versa. I figured there had to be
> some way to get Linux to do what I wanted, instead of what it wanted.
> And there is.
>
> However, I had so much trouble finding the answer to these questions, I
> thought I'd better post the information I found. I've seen several
> postings of some variation of this question, and most went unanswered.

If the nics are identical, it would be simplest to just swap cables.
Although, your info may help if they randomly flip-flop as to which is
which.

If the nics are different (different modules) simply swap which module is
used for alias eth0, alias eth1, etc. in /etc/modules.conf.

--
David Efflandt - All spam ignored http://www.de-srv.com/
http://www.autox.chicago.il.us/ http://www.berniesfloral.net/
http://cgi-help.virtualave.net/ http://hammer.prohosting.com/~cgi-wiz/

David Efflandt wrote:
> On Tue, 04 Nov 2003, Ben <(E-Mail Removed)> wrote:

> If the nics are identical, it would be simplest to just swap cables.
> Although, your info may help if they randomly flip-flop as to which is
> which.

Simplest? Sort of depends where *your* system's 'butt' is placed. If
it's in a dark corner where my head doesn't fit, where my *gd* bifocals
don't work, and where light doesn't reach, then swapping cables is the
*last* think I want to try . . . especially on a 3 NIC gateway machine.

Maybe I'm just too old for this stuff? ;-)

But, I've seen some other folk's machines in even worse places. Also,
though I hadn't mentioned it, one point of this (for me) is to develop
a generic script that allows me to answer the inevitable multi-NIC new
box question: "Which NIC is which?" Again, I've found this particularly
annoying and irritating on 3-NIC boxes. I'm not sure about yours, but
none of my NIC's come with little banks of LED's of which 1, 2, or 3
light up, indicating assignment as eth0, eth1, or eth2. There may be
some pattern, based on PCI slot location, but I haven't identified it,
if there is. Maybe there *is* a pattern, but it's mobo-specific?

> If the nics are different (different modules) simply swap which module is
> used for alias eth0, alias eth1, etc. in /etc/modules.conf.

Hm-m-mh.

I need to do some further checking.

I'm not sure how using the "ip" tool interacts with modules.conf.

I'd only tested the single switch case, and it worked consistently.
But, if I flop the cards back and forth, I found I had to issue "ifup
eth0" to get predictable results. One thing I *did* confirm is that the
RedHat "NEAT" GUI tool gets totally confused by all this, and does NOT
report correct information.

Ben

> There may be
> some pattern, based on PCI slot location, but I haven't identified it,
> if there is. Maybe there is a pattern, but it's mobo-specific?

No, I don't think so. My two NICs swap between eth0 and eth1 seemingly at
random at boot time. And this is true even though I've aliased one of them
to eth0 and the other to eth1 in /etc/modules.conf-- which was David's
suggestion. It's screwy, I know.

The only reliable way I've found to ensure the order of the NICs is to force
the modules to load in the order that I want, by mentioning them in
/etc/modules. The first one that I mention there loads first, and becomes
eth0 (even if its alias happens to be eth1, though of course I alias it to
eth0).

This isn't an elegant solution, but it works reliably for me. If you find a
better one, by all means let us know.

As far as determining programmatically which device is which, I'm sure you
can find the information in /proc if you dig around long enough.

Good luck,
Andrew.

--
To reply by email, change "deadspam.com" to "alumni.utexas.net"

Andrew Schulman wrote:
>>There may be
>>some pattern, based on PCI slot location, but I haven't identified it,
>>if there is. Maybe there is a pattern, but it's mobo-specific?


> No, I don't think so. My two NICs swap between eth0 and eth1 seemingly at
> random at boot time. And this is true even though I've aliased one of them
> to eth0 and the other to eth1 in /etc/modules.conf-- which was David's
> suggestion. It's screwy, I know.

Yikes! I never knew it got THAT bad. I wonder how widespread your flavor
of the problem is?

On a multi-NIC gateway machine, that could potentially result in a
serious security breach, which in turn implies that firewalling scripts
must absolutely determine 'which NIC is which', as they run.


> The only reliable way I've found to ensure the order of the NICs is to force
> the modules to load in the order that I want, by mentioning them in
> /etc/modules. The first one that I mention there loads first, and becomes
> eth0 (even if its alias happens to be eth1, though of course I alias it to
> eth0).

I assume, though, that this works ONLY if you have NICs which use two
DIFFERENT drivers, ie, you can't have two NICs using the 'tulip' module,
and still be able to count on this. This happens to be the case on the
particular machine that got me started on this, but is not true of other
machines I operate.

Ben

>> The only reliable way I've found to ensure the order of the NICs is to
>> force the modules to load in the order that I want, by mentioning them in
>> /etc/modules.**The*first*one*that*I*mention*there*loads*first,*and
>> becomes eth0 (even if its alias happens to be eth1, though of course I
>> alias it to eth0).
>
> I assume, though, that this works ONLY if you have NICs which use two
> DIFFERENT drivers, ie, you can't have two NICs using the 'tulip' module,
> and still be able to count on this. This happens to be the case on the
> particular machine that got me started on this, but is not true of other
> machines I operate.

That's true-- what a mess.

The new udev system (successor to devfs, which is dead before it was ever
fully alive) is supposed to fix this problem, by allowing the user to
specify that a device with characteristics X becomes device file Y. But I
don't know if it applies to network interfaces, since they're not device
files. Hm. See http://kernel.org/pub/linux/utils/ke...tplug/udev-FAQ.

--
To reply by email, change "deadspam.com" to "alumni.utexas.net"

On Fri, 07 Nov 2003 22:03:37 -0500, Andrew Schulman wrote:
>>> The only reliable way I've found to ensure the order of the NICs is to
>>> force the modules to load in the order that I want, by mentioning them in
>>> /etc/modules.**The*first*one*that*I*mention*there*loads*first,*and
>>> becomes eth0 (even if its alias happens to be eth1, though of course I
>>> alias it to eth0).
>>
>> I assume, though, that this works ONLY if you have NICs which use two
>> DIFFERENT drivers, ie, you can't have two NICs using the 'tulip' module,
>> and still be able to count on this. This happens to be the case on the
>> particular machine that got me started on this, but is not true of other
>> machines I operate.
>
> That's true-- what a mess.


Quite, please do not tell my Mandrake linux about that because it has
been working for several years and releases. I am using 2 linksys
10/100 nics with eth1 to the cable modem and eth0 to a Linksys hub.

cat /etc/modules.conf

alias eth1 tulip
alias eth0 tulip

Bit Twister wrote:


>>>I assume, though, that this works ONLY if you have NICs which use two
>>>DIFFERENT drivers, ie, you can't have two NICs using the 'tulip' module,
>>>and still be able to count on this. This happens to be the case on the
>>>particular machine that got me started on this, but is not true of other
>>>machines I operate.
>>
>>That's true-- what a mess.
>

> Quite, please do not tell my Mandrake linux about that because it has
> been working for several years and releases. I am using 2 linksys
> 10/100 nics with eth1 to the cable modem and eth0 to a Linksys hub.
>
> cat /etc/modules.conf
>
> alias eth1 tulip
> alias eth0 tulip
>

Yes, it's all stable if you leave it alone. But, have you been
"swopping 'em back-n-forth"?

That's where it get's sticky.

Andrew Schulman wrote:

>>I assume, though, that this works ONLY if you have NICs which use two
>>DIFFERENT drivers, ie, you can't have two NICs using the 'tulip' module,
>>and still be able to count on this. This happens to be the case on the
>>particular machine that got me started on this, but is not true of other
>>machines I operate.
>
>
> That's true-- what a mess.
>
> The new udev system (successor to devfs, which is dead before it was ever
> fully alive) is supposed to fix this problem, by allowing the user to
> specify that a device with characteristics X becomes device file Y. But I
> don't know if it applies to network interfaces, since they're not device
> files. Hm. See http://kernel.org/pub/linux/utils/ke...tplug/udev-FAQ.
>

A poster below started a new thread on this topic (more or less) and
noted that the cards get assigned in physical order, so long as all
are connected at bootup, but that all h*** broke loose if one of them
wasn't connected.

It just occurred to me that you can not only use ip to script device
handle assignment by MAC, but that you could, using ip, ping, and grep,
write a script that would VERIFY that an established network was still
connected properly, by testing that a given card could ping an address
on the network it was *supposed* to be assigned to.

Suppose you have three cards (nic1, nic2, nic3 -- in bus order) assigned
*and cabled* to the networks 10.1.1.1/24, 10.2.2.1/24 and 10.3.3.1/24
respectively. Further assume that 10.1.1.2, 10.2.2.2, 10.3.3.2 were
ping-able devices on each network. In this case, the script could
successively test each card and verify that it had been assigned,
internally, to the network to which it was connected externally.
Even if one or two cards weren't cabled at bootup, the script
would still get the one that was connected properly.

Obviously, ugly.

But, it seems like it could work AND be reliable, in a network
specific sort of way. And since, it is a network specific sort of
problem, I suppose that's tolerable. Of course, "woe unto" the
replacement sysadmin who didn't know that such a script was
active! In fact, it would probably be smart to log some messages
to both SYSLOG and the screen just so nobody would forget about
it.

Ben

Hi

Ben wrote:
>
> A poster below started a new thread on this topic (more or
less) and
> noted that the cards get assigned in physical order, so long
as all
> are connected at bootup, but that all h*** broke loose if one
of them
> wasn't connected.
>
That's me.

I put the same question to our "local" Linux User Group
http://www.lug.lk and got received these answers:

Supun Ratnayake
> I have observed this pattern in many occasions.
[in the order they sit in the PCI bus]

> eth0 gets assigned to the first network card in the PCI
> bus towards motherboard then eth1 and so on.

Nimal Ratnayake
> Have you tried disabling PCI plug and play in the bios?
> Also check disabling the "Wake on LAN" feature on the cards.


Sarod Yatawatta
> according to the man page
> nameif - name network interfaces based on MAC addresses
>
> nameif renames network interfaces based on mac addresses.
> When no arguments are given /etc/mactab is read.

Nishantha Wimaladharma
> alias eth0 3c59x
> alias eth1 3c59x
> options eth0 -o 3c59x-0 io=0x240 irq=5
> options eth1 -o 3c59x-1 io=0x300 irq=7

The complete thread is in the archive
http://mail.lug.lk/pipermail/members...er/004719.html

In my case, I can live with "physical order in the PCI bus"
as long as the numbering is independent of *active or not*.

In the long run, we have to understand the mechanism.

Visvanath.