Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 162888

Summary: ifconfig drops every virtual interface of the same sub-net instead of just the one you want
Product: Red Hat Enterprise Linux 3 Reporter: paco
Component: net-toolsAssignee: Radek Vokal <rvokal>
Status: CLOSED WONTFIX QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: djoo, jirislaby, pgraner
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard: RHEL3U7NAK
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-19 18:58:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 189875    

Description paco 2005-07-11 10:08:09 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Description of problem:
Background: a physical interface (i.e.: eth0) with a few virtual interfaces associated to it (i.e.: eth0:0, eth0:1, eth0:2...).

When you try to drop just one of the virtual interfaces (i.e.: eth0:3) with "ifconfig eth0:x down", it drops that interface AND all the next interfaces of the same subnet (i.e.: eth0:3, 3th0:4, eth0:5).

A weird thing is that previous interfaces remain "up" even if they belong to the same subnet (i.e.: eth0:2).

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Create a few virtual interfaces (i.e.: "ifconfig eth0:x 192.168.10.x up", etc.).
2.Drop the first of them (i.e.: "ifconfig eth0:0 down")

Actual Results:  Instead of just dropping the interface mentioned, it drops all the virtual interfaces you created.

Expected Results:  It should have just dropped one virtual interface, the one you gave in the "ifconfig" command.

Additional info:

It happens also using "ifdown", but it's normal 'cause it's a script that calls "ifconfig", isn't it?

Comment 1 Radek Vokal 2005-07-20 11:11:51 UTC
Fixed in rawhide, net-tools-1.60-55. Will appear in some later RHEL3 update. 

Comment 7 masanari iida 2006-04-21 15:59:56 UTC
Has this fix (in 1.60-55) already included in net-tools of RHEL3 released??

Comment 12 Radek Vokal 2006-06-14 07:08:58 UTC
Can we please get the inputs reposted. I'm missing yesterday comments here due
to the raid failure. Thanks

Comment 15 Jiri Slaby 2006-06-14 08:40:36 UTC
------- Additional Comments From  2006-06-09 18:14 EST -------
Have you tried to set promote secondaries sysctl variable?
ifconfig eth0:x 192.168.10.x/24
sysctl net.ipv4.conf.eth0.promote_secondaries=1
ifconfig eth0:0 down

Addresses on the same subnets are noted as secondaries, when you remove the very
first, i.e. primary one, kernel kills others. When you don't want this
behaviour, enable promoting of secondaries and kernel will choose the following
address (virtual device) and set is as primary.

Tip: try to convert to ip(8), it says you they're secondary.

Comment 16 Jose Plans 2006-06-15 14:48:58 UTC
Hi Jiri,
 Thanks for the provided comments, it is exactly that the issue the customer is
encountering. However the 2.6.12 kernel workaround proposing that feature has
not yet been included in RHEL3/4. 
 It is possible to use this feature in FC5 as it includes a newer kernel, but as
I said, it is not yet possible to promote secondary devices with RHEL.

Comment 19 RHEL Product and Program Management 2007-10-19 18:58:20 UTC
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.