On Tue, 2006-06-13 at 08:48 -0500, Martin A. Brown wrote: > Eli, > > : > > Now I bring host B's ib1 interface down > : > > (ifconfig ib1 down) and I expect that the interface's IP address will no > : > > : > > longer exists. > : > > : > This would be an incorrect assumption. > : > > : > Deleting an address and preventing traffic on an interface are two > : > different operations. As long as there is a route, through any > : > interface, all addresses identify the same machine and will be > : > delivered. This isn't Linux-specific behavior. > : > : But the interface is now down. And suppose I would bring ib1 down > : on host B and at the same time assign its IP address to another > : interface on host C (this is legal isn't it?). Where would the > : packets go then? > > This might very well be Linux-specific behaviour. I would encourage > you to read the iproute2 documentation and compare the output of "ip > address show" with your expectations. > > When you bring an interface down, the IP address is still listed on > that interface. If the system has another link to the network, the > IP address on the "downed interface" is still reachable. Some > people view this as counterintuitive behaviour, but this reflects a > core decision within the kernel's networking stack: > > IP addresses are associated with the host. > > Check out the following behaviour on two hosts. Note, first, that > the machine multipleInterfaces has several IP addresses. We are > only going to be concerned with the addresses on eth1 (but, observe, > that all packets exchanged below pass over eth0). > > [multipleInterfaces]$ ip -4 addr show > 1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue > inet 127.0.0.1/8 scope host lo > 3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 > inet 10.10.20.33/24 brd 10.10.20.255 scope global eth0 > inet 10.10.20.44/24 brd 10.10.20.255 scope global secondary eth0:copula > 4: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 > inet 10.10.20.77/32 scope global eth1 > > [hostA]$ ping -nc1 10.10.20.77 > PING 10.10.20.77 (10.10.20.77) from 10.10.20.1 : 56(84) bytes of data. > 64 bytes from 10.10.20.77: icmp_seq=1 ttl=64 time=0.303 ms > > --- 10.10.20.77 ping statistics --- > 1 packets transmitted, 1 received, 0% loss, time 0ms > rtt min/avg/max/mdev = 0.303/0.303/0.303/0.000 ms > > OK, this is no surprise. We sent a ping packet from h -> m and > received a reply. It doesn't matter that eth1 is not connected to > an Ethernet. The traffic simply passes over eth0. > > [multipleInterfaces]$ ip link set dev eth1 down > > [hostA]$ ping -nc1 10.10.20.77 > PING 10.10.20.77 (10.10.20.77) from 10.10.20.1 : 56(84) bytes of data. > 64 bytes from 10.10.20.77: icmp_seq=1 ttl=64 time=0.305 ms > > --- 10.10.20.77 ping statistics --- > 1 packets transmitted, 1 received, 0% loss, time 0ms > rtt min/avg/max/mdev = 0.305/0.305/0.305/0.000 ms > > Wait! Didn't we "turn off" the eth1 interface? Why is the machine > responding. Let's double-check our work: > > [multipleInterfaces]$ ip -4 addr show dev eth1 > 4: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000 > inet 10.10.20.77/32 scope global eth1 > > Well...the interface is not up. Let's try blowing away the > IPs on interface eth1. > > [multipleInterfaces]$ ip addr flush dev eth1 > > [hostA]$ ping -nc1 10.10.20.77 > PING 10.10.20.77 (10.10.20.77) from 10.10.20.1 : 56(84) bytes of data. > > --- 10.10.20.77 ping statistics --- > 1 packets transmitted, 0 received, 100% loss, time 0ms > > That's better! No reply! > > So, Eli, you may need to adjust your system and/or scripts to > reflect the actual behaviour of the Linux kernel on this matter. > > Good luck, > > -Martin > Hi Martin, thanks a lot for the thorough explanation. I will do some more testing. - : 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
