Bug 74918 - Adding second NIC to same network segment disables first NIC
Adding second NIC to same network segment disables first NIC
Status: CLOSED DEFERRED
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-02 15:47 EDT by Tom Wood
Modified: 2014-03-16 22:31 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-29 16:19:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
diagnostic commands run to illustrate the problem (with inline commentary) (6.66 KB, text/plain)
2002-10-02 16:23 EDT, Tom Wood
no flags Details

  None (edit)
Description Tom Wood 2002-10-02 15:47:58 EDT
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.
Comment 1 Tom Wood 2002-10-02 16:23:43 EDT
Created attachment 78224 [details]
diagnostic commands run to illustrate the problem (with inline commentary)
Comment 2 Tom Wood 2002-10-03 12:37:26 EDT
The same situation exists with stock 2.4.19 and 2.4.20-pre8 kernels.
Comment 3 Phil Knirsch 2002-10-04 11:16:57 EDT
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
Comment 4 Tom Wood 2002-10-04 14:25:18 EDT
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.
Comment 5 Habig, Alec 2002-10-07 16:53:16 EDT
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.
Comment 6 Tom Wood 2002-10-07 18:49:28 EDT
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.
Comment 7 Habig, Alec 2002-10-09 10:51:02 EDT
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.
Comment 8 Bill Nottingham 2005-09-29 16:19:27 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.