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
--
Martin A. Brown --- Wonderfrog Enterprises --- martin@xxxxxxxxxxxxxx
-
: 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
