At 12/25/05 16:24, James Knott wrote:
Michael W Cocke wrote:
On Sun, 25 Dec 2005 15:59:12 -0500, you wrote:
Eric Hines wrote:
At 12/25/05 07:51, James Knott wrote:
Eric Hines wrote:
At 12/24/05 18:53, James Knott wrote: > Eric Hines wrote: <snip> Either I'm missing something or you're missing something. Those files are tied directly to a NIC, with the corresponding MAC address. They don't work with any other. Now eth0, eth1 etc., may wander around, but why is that an issue? Servers talk to IP addresses, not NICs. It's up to the IP stack to figure out which NIC to talk to. You shouldn't have any need to worry about whether a NIC is eth0 or not.
James, I think you're assuming that the OP understands as much about this as you do. I went thru the same learning/aggravation cycle when I installed SuSE 9.3 on my firewall system.
Eric, What you're encountering is a raceway condition that's set up during boot. What happens is that a whole bunch of initialization tasks are started in a batch, and whatever NIC is initialized first is named eth0, second is eth1, etc.
There are actually several ways to work around what may be the dumbest design decision in operating system history since 640K.
The one that I use is explained here: http://www.catherders.com/tikiwiki-1.9.1/tiki-read_article.php?articleId=36
The one that James is trying to explain is more elegant but requires you to understand the contents of /etc/sysconfig/network/. In a nutshell, find the file named ifcfg-eth-id-mac address of the particular nic. Edit the contents to assign the ipaddress you want to the particular NIC with that MAC address. Repeat for the rest of your NICs.
Interesting. However, that author is also making the same mistake that you have to deal with eth0 etc. For example, he uses it in a default route statement. What's wrong with specifying a default route network and then letting the IP stack figure out which NIC to use? Is there any reason why a configuration has to specify a particular NIC, instead of a network address?
I think I have an understanding of what's going on (and it was me that was missing something), and I now have a stable set up. What Mike is describing is consistent with the ifstatus man page saying that ethx is no longer bound to a NIC, since the advent of removable NICs (e.g., via USB). James is saying the same thing when he says don't worry about which eth is which, just get the NICs and IP addresses right. I followed James' suggestion and edited the ifcfg-eth-id-<MAC Address> files, and I've had a stable (under my clearer understanding of the meaning of "stable") set up since. There was one of two things going on with the latter: either YaST was messing up when I used it to edit the files, and I straightened that out when I edited the files directly, or I was collecting bad data and there were no wandering NIC/IP address problems all along. Unfortunately, I have to lean toward the latter. At any rate, thanks for taking the time to set me in the right direction. And Merry Christmas. Eric Hines There is no nonsense so errant that it cannot be made the creed of the vast majority by adequate governmental action. --Bertrand Russell