Return to BSD News archive
Xref: sserve comp.protocols.tcp-ip:27668 comp.unix.bsd:13483 comp.unix.ultrix:21543
Path: sserve!newshost.anu.edu.au!munnari.oz.au!ihnp4.ucsd.edu!library.ucla.edu!agate!howland.reston.ans.net!pipex!uknet!EU.net!julienas!sophia.inria.fr!mitsou.inria.fr!huitema
From: huitema@mitsou.inria.fr (Christian Huitema)
Newsgroups: comp.protocols.tcp-ip,comp.unix.bsd,comp.unix.ultrix
Subject: Re: How do multi-homed hosts choose the interface?
Date: 25 Feb 1994 15:01:15 GMT
Organization: INRIA, Sophia-Antipolis (Fr)
Lines: 74
Distribution: world
Message-ID: <2kl3rr$21o@sophia.inria.fr>
References: <2khb6f$9fl@breeze.dra.hmg.gb> <2kkst5$hen@irzr17.inf.tu-dresden.de>
NNTP-Posting-Host: mitsou.inria.fr
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
The problem of "multi-homed hosts" has several different implications. The
first thing you have to remember is that while the applications deals with
names, IP deals with interfaces. At the application level, you see:
FDDI ring
--------------------------------------
| Iaf | Iuf
Alpha Ultrix
| Iae | Iue
-------------------------------------
ethernet
because you name the machines, say "alpha" and "ultrix". At the IP level, you
only see Ip addresses. Suppose that you are sending a packet from "alpha":
there is no difference for the IP code between the figure above and:
FDDI ring
--------------------------------------
| Iuf | Iaf
(foo) Alpha Ultrix
| Iae | Iue
-------------------------------------
ethernet
When presented with the address "Iuf", the IP code of alpha will observe that
it is on the same "network" as "Iaf": the most significant bits of the
address, under the subnet mask, match. It will thus very naturally route it
through the FDDI ring. Similarly, a packet sent to "Iue" will naturally travel
through the Ethernet.
You can indeed change that by a routing instruction, telling the IP code to
route every packet bound to "Iue" through the interface "Iuf" (this is the
command suggested by R. Bradshaw). It has only one inconvenient: you loose the
inherent reliability of having two routes.
In fact, you should rather try to pick the correct address within the
application. One very simple way to solve this is to have an additional entry
in the DNS for "alpha-fddi" and "ultrix-fddi". This is the solution we are
actually using right now in my lab when we want to be absolutely sure of the
way the packets are routed, e.g. when doing comparisons of performances.
The real solution however is to change the "gethostbyname" code so that when it
returns multiple addresses it tries to sort them by "distance". This is very
hard to implement in the general case, for you don't have access to the
distance: your host is not a router. Listening to RIP packets is *not* a
recommanded practice - it will not be very useful if the network uses OSPF.
Besides, RIP distances are essentially hop-counts which will not be terribly
helpful in your case. Also, you should note that even the routers don't know
the "end to end" distance in the general case: real distances are not carried
by EGP or BGP. Thus the estimation of distance will largely be an heuristic,
based on:
* the local knowledge: the local addresses and subnet masks are known,
can be associated with a throughput indication. In any case, an address
on a local subnet should be prefered to a remote address.
* past statistics: the typical host only has a limited number of
correspondants. It can keep statistics of the previous connections and
use them to "rate" addresses.
* probes: if you are going to send gigabytes, it may make sense to actually
build the statistic before engaging in the real connection.
Note that there are several usages to this "address ratings": multi-homed hosts
is one, but another is picking one server out of several candidates. Like the
nearest mail gateway out of several MX records of equal precedence...
Last but not least: if you don't know how to chose, picking one at random is
usually better than always picking the same one!
Christian Huitema