> -----Original Message----- > From: Thomas Graf [mailto:tgraf@xxxxxxx] > Sent: Wednesday, November 29, 2006 6:12 AM > To: Tim Wright > Cc: David Miller; shemminger@xxxxxxxx; linux-net@xxxxxxxxxxxxxxx > Subject: Re: Arp undo issue in all 2.4 and 2.6 kernel releases > > * Tim Wright <timw@xxxxxxxxxxxxx> 2006-11-28 14:51 > > [root@nfstest root]# ip addr list > > 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 > > 5: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast > qlen 1000 > > link/ether 00:80:ad:72:3e:5a brd ff:ff:ff:ff:ff:ff > > inet 10.12.0.20/16 brd 10.12.255.255 scope global eth0 > > inet6 fe80::280:adff:fe72:3e5a/64 scope link > > valid_lft forever preferred_lft forever > > 6: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000 > > link/ether 00:80:ad:20:59:8b brd ff:ff:ff:ff:ff:ff > > 7: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000 > > link/ether 00:01:02:c6:fe:c1 brd ff:ff:ff:ff:ff:ff > > 8: sit0: <NOARP> mtu 1480 qdisc noop > > link/sit 0.0.0.0 brd 0.0.0.0 > > [root@nfstest root]# ping 10.12.0.22 > > PING 10.12.0.22 (10.12.0.22) 56(84) bytes of data. > > 64 bytes from 10.12.0.22: icmp_seq=0 ttl=64 time=0.108 ms > > 64 bytes from 10.12.0.22: icmp_seq=1 ttl=64 time=0.076 ms > > > > --- 10.12.0.22 ping statistics --- > > 2 packets transmitted, 2 received, 0% packet loss, time 1000ms rtt > > min/avg/max/mdev = 0.076/0.092/0.108/0.016 ms, pipe 2 > > > > > > It's not associated with any interface on the system. > Please try this > > yourself. It is trivially reproducible. > > The list of addresses really doesn't matter, it's the local > route that is relevant for arp and therefore the route cache > which may for some reason not be flushed in your case. > Therefore please provide exact kernel version, contents of > the local table, eventual routing rules(!) and list the route > cache ("ip r l c") > > Use of interface aliases via ifconfig is deprecated and > thinking in terms of putting a interface alias "up" or "down" > is dangerous because what you really do is adding/removing > secondary addresses. > Hi Thomas. I will do as you ask and send an update. I think I was not terribly clear given the apparent misunderstandings of my original post. If I bring up a single IP alias, the machines answers to arp requests. If I "down" it using the crufty old ifconfig, the address disappears and the machine no longer responds to arps. If I bring up one alias, then try to bring up a second with the same address, the second ifconfig fails, but it apparently has touched something wrt the route cache such that subsequently removing the original address does not clean up and the machine now responds to arps for an address that it no longer has on any interface. I will go and stick the latest kernel.org kernel on my test machine and reproduce the problem and collect the data you ask for. Thank you very much, Tim - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
