Bug 156668 - ip address is used even after unconfigured
ip address is used even after unconfigured
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
ia64 Linux
medium Severity medium
: ---
: ---
Assigned To: David Miller
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-02 21:53 EDT by Rohit Rakshe
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-13 02:08:37 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)

  None (edit)
Description Rohit Rakshe 2005-05-02 21:53:36 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

Description of problem:
Note that 10.182.14.56 is not present on this machine.

# ip addr
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:04:23:9e:e1:90 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.155/20 brd 192.168.1.255 scope global eth0:0
    inet6 fe80::204:23ff:fe9e:e190/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:04:23:9e:e1:91 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::204:23ff:fe9e:e191/64 scope link
       valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:30:6e:f3:3d:fc brd ff:ff:ff:ff:ff:ff
    inet6 fe80::230:6eff:fef3:3dfc/64 scope link
       valid_lft forever preferred_lft forever
5: eth3: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:30:6e:f3:ed:84 brd ff:ff:ff:ff:ff:ff
    inet 10.182.14.155/20 brd 10.182.15.255 scope global eth3
    inet 10.182.14.55/20 brd 10.182.15.255 scope global secondary eth3:1
    inet6 fe80::230:6eff:fef3:ed84/64 scope link
       valid_lft forever preferred_lft forever
6: sit0: <NOARP> mtu 1480 qdisc noop
    link/sit 0.0.0.0 brd 0.0.0.0


Still the same machine replies to the ICMPs directed to 10.182.14.56...

# tcpdump -lenx  -i eth3 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth3, link-type EN10MB (Ethernet), capture size 96 bytes
21:30:09.803564 00:30:6e:f3:ed:3f > 00:30:6e:f3:ed:84, ethertype IPv4 (0x0800), length 98: IP 10.182.14.156 > 10.182.14.56: icmp 64: echo request seq 0
        0x0000:  4500 0054 0000 4000 4001 086a 0ab6 0e9c  E..T..@.@..j....
        0x0010:  0ab6 0e38 0800 06e8 7f08 0000 f8d0 6942  ...8..........iB
        0x0020:  0000 0000 4429 0d00 0000 0000 1011 1213  ....D)..........
        0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
        0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
        0x0050:  3435                                     45
21:30:09.811483 00:30:6e:f3:ed:84 > 00:30:6e:f3:ed:3f, ethertype IPv4 (0x0800), length 98: IP 10.182.14.56 > 10.182.14.156: icmp 64: echo reply seq 0
        0x0000:  4500 0054 5459 0000 4001 f410 0ab6 0e38  E..TTY..@......8
        0x0010:  0ab6 0e9c 0000 0ee8 7f08 0000 f8d0 6942  ..............iB
        0x0020:  0000 0000 4429 0d00 0000 0000 1011 1213  ....D)..........
        0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
        0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
        0x0050:  3435                                     45


Version-Release number of selected component (if applicable):
kernel-2.6.9-6.37.EL

How reproducible:
Couldn't Reproduce


Additional info:
Comment 1 David Miller 2005-05-10 15:32:41 EDT
Taking an interface down does not disassociate the IP addresses
from the HOST.  You must manually either remove the IP addresses
from the interface or unload the device driver module for the
machine to stop responding to those IP addresses.

You haven't listed explicitly how you reached this state
above, there could be downed interfaces not being listed
by "ip addr" but you aren't mentioning.

If one of those downed interfaces still have the IP address
in question configured to it, that explains the behavior and
that is fully correct behavior and not a bug.
Comment 2 Rohit Rakshe 2005-05-10 16:54:50 EDT
The IP address "10.182.14.56" was initially configured as eth3:2 on this
machine. It was taken down by Oracle, so I am not sure exactly what command it
used to unconfigure it. But after that, this IP address did not show up in
"ifconfig -a" or "ip addr" output. Hence, it is valid to expect that the machine
does not have the IP address any more. It should not be replying to ICMP pings.
Comment 3 David Miller 2005-05-10 18:08:28 EDT
Please find out exactly how Oracle (Oracle database changes IP
interface configuration?!?!?! that is news to me) removes the IP
address.  It is critical to know this in order to analyze this
bug properly.

It either uses netlink or the BSD socket ioctls, and those use
two totally different paths of processing.

Also, what does the routing table look like when it gets into
this state?  Maybe that's it, Oracle is leaving a lingering
route around.
Comment 4 Luming Yu 2007-08-13 02:08:37 EDT
No responses since 2005-5-10, closing it...
Please re-open if it is still a problem.

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