From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 Description of problem: After I added a second NIC to my Psyche box, kudzu added it as eth1 and ran netconfig. This second NIC is not connected to the network. The IP address for eth1 is on the same network segment as the existing eth0 (I have my reasons for this, mainly testing). The first NIC no longer functions properly. The routing table now is dependent on eth1, not eth0. And eth0 can't even ping machines on the same segment. "ifdown eth1" drops all routes except to loopback. "ifdown eth0;ifup eth0" restores the routes, but the interface isn't operational. "service network restart" doesn't help either. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Install 8.0 or upgrade to 8.0. 2.Add second NIC. 3.Allow kudzu to run netconfig. 4.Configure new NIC with address on same network segment as original NIC. 5. Observe eth0 cease to function. 6. ifdown eth1 7. ifdown eth0; ifup eth0 8. Observe eth0 still not function. Actual Results: eth0 no longer is able to communicate. The routing table now references eth1. Expected Results: No disabling of eth0 and no routing changes. Additional info: Please see attached ifcfg-eth0, ifcfg-eth1, output of manually stepping through the above with routing information and test pings.
Created attachment 78224 [details] diagnostic commands run to illustrate the problem (with inline commentary)
The same situation exists with stock 2.4.19 and 2.4.20-pre8 kernels.
ifup and ifdown are part of the initscripts, so i reassign it to the proper component. But agreed, this is not the 'desired' behaviour. :-) You should be able to get the 'correct' behaviour for your test setup with 2 nics in the same system on the same subnet using the ip and route commands manually. Read ya, Phil
Phil, I've tried exactly what you suggest with manually setting routes. That doesn't help. The first NIC gets creamed by the second's presence. Nothing I can think of will restore the routing, even though netstat -r looks fine. That's why I thought this was kernel related.
I bumped into this too, but the problem doesn't depend on being on the same network segment. My configuration is a standard ip-masq'ing one: eth0 - DHCP assigned parameters, talks to world eth1 - static interface to private 192.168.1. net Even with explicitly stating DEFROUTE=no in the ifcfg-eth1, bringing up the eth1 interface clobbers the eth0 routing to the world. Worked fine in 7.3 and previous releases.
My problem isn't limited to being on the same network either. It's just that my initial configuration had both NICs on the same segment. Whatever interface comes up last wins the battle and kills its opponents.
I found a work-around for my problem. Somehow, a GATEWAY definition had found its way into my ifcfg-eth1 file. Removing this seems to have removed the ifup script's desire to add a new default route. This doesn't solve the bug though, the scripts should not ignore DEFROUTE=no and should not clobber existing routes. Not sure how the GATEWAY line got in there - it was bogus (the little local subnet has none) and isn't in my other 7.3 machines. I don't know if it was in this machine's file before the upgrade to 8.0 or if the upgrade was trying to be helpful. I have not run any net configuration scripts, I just edit the files myself.
Closing bugs on older, no longer supported, releases. Apologies for any lack of response. If this persists on a current release, such as Fedora Core 4, please open a new bug.