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:
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.
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.
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.
No responses since 2005-5-10, closing it... Please re-open if it is still a problem.