On Wed, 30 Jan 2008, Adrian Knoth wrote:
let me point out that the assumption "One interface, one address"
isn't true.
Strictly speaking when configuring one address to one interface:
For Linux, "one interface, one address" isn't true; for Solaris and
other Unices it is. The standards allow either of "assign addresses to
interfaces" (Solaris way) and "assign addresses to hosts" (Linux way)
to be used; this is a decision of the kernel network stack writers and
can't be changed, however there are ways to configure the Linux stack
to behave similar to the Solaris one from this point of view by
limiting the ARP behaviour. The decision to assign addresses to hosts
in Linux was made such that there is a better chance of reaching the
host in case of misconfiguration or network problems. Indeed, even if
an interface is down (f.e. cable unplugged or 'ifconfig ethX down'),
the address is reachable via other interfaces, as a new ARP
association is made between the IP address and the MAC address of the
interface which is used.
As mentioned earlier: it's very common to have multiple addresses per
interface
That's the other case: an interface could have several addresses
configured for it, f.e. via repeated 'ip add ... dev ethX', but this
just adds to the number of addresses assigned to the host.
The results is that, with the default Linux kernel settings, there is
no way to tell which way a connection will take in a multi-rail TCP/IP
setup. Even more, when the ARP cache expires and a new ARP request is
made, the answer (MAC address) from the target/destination could be
different, so that from that moment on the connection could switch to
a different media. I've tested this recently with the RHEL5 kernels
with one gigabit and one Myri-10G connection, seeing a TCP stream
switching randomly between the gigabit and the Myri-10G connection.
--
Bogdan Costescu
IWR, University of Heidelberg, INF 368, D-69120 Heidelberg, Germany
Phone: +49 6221 54 8869/8240, Fax: +49 6221 54 8868/8850
E-mail: bogdan.coste...@iwr.uni-heidelberg.de
