Bug 162888 - ifconfig drops every virtual interface of the same sub-net instead of just the one you want
Summary: ifconfig drops every virtual interface of the same sub-net instead of just th...
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: net-tools (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: i686 Linux
medium
medium
Target Milestone: ---
Assignee: Radek Vokal
QA Contact: Ben Levenson
URL:
Whiteboard: RHEL3U7NAK
Keywords:
Depends On:
Blocks: 189875
TreeView+ depends on / blocked
 
Reported: 2005-07-11 10:08 UTC by paco
Modified: 2008-08-02 23:40 UTC (History)
3 users (show)

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: ---


Attachments (Terms of Use)

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):
net-tools-1.60-20E.7

How reproducible:
Always

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")
3.
  

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
Hello.
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 xslaby@fi.muni.cz  2006-06-09 18:14 EST -------
Have you tried to set promote secondaries sysctl variable?
I.e.:
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.
Regards,
Jose

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:
http://www.redhat.com/security/updates/errata/
 
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.


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