sater@cs.vu.nl (Staveren van Hans) (07/03/90)
Recently I posted a question to these groups to which, to my surprise, I received no reactions at all. This seems strange since it addresses a problem that many of us are going to face. Now there is of course the possibility that this is so obvious that you were all embarrassed by the question, but I doubt it. Suppose part of a network looks like this --------------------------------------------------------- network A | | | ----------------- ----------------- ---------- | A.1 | | A.2 | | A.3 | | Host foo | | Host bar | |Host zot| | B.6 | | B.7 | | | ----------------- ----------------- ---------- | | --------------------------------------------------------- network B so two parallel networks with some multihomed and some singlehomed hosts. Further suppose that network B is preferable to network A, because of load, politics or because it is 10x as fast (hint: FDDI vs Ethernet). How would one set up addressing and routing for such a configuration? Using the DNS address lookup you get two addresses for each machine, but most software doesn't understand that currently and only uses the first one. Now the documentation suggests that you can order the addresses so that certain preferred networks come in front, but looking at our bind source code shows that that is not implemented. So host foo looks up host bar, and gets the address set (A.2, B.7). Both addresses are on directly connected networks. How do you make sure that either it uses B.7, or it uses A.2 but still routes it over network B. Ideally this should be done by the routing layer of course, but current routing software will probably send a packet for A.2 onto network A, unless a host route for A.2 points to B.7. You can of course set up all these routes by hand, but if the network size increases this gets to be too much trouble. You could imagine that host bar propagates a host route for A.2 on network B, and all hosts are persuaded that network A is expensive by messing around with metrics, but that would lead to a proliferation of host routes floating around the network, and maybe even propagating to the rest of the Internet, which would be extremely undesirable. How do people solve this? Do people actually have situations like this already? Inquiring minds want to know. Hans van Staveren Vrije Universiteit Amsterdam, Holland
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) (07/04/90)
In article <7050@star.cs.vu.nl> sater@cs.vu.nl (Staveren van Hans) writes: >Suppose part of a network looks like this > > --------------------------------------------------------- network A > | | | > ----------------- ----------------- ---------- > | A.1 | | A.2 | | A.3 | > | Host foo | | Host bar | |Host zot| > | B.6 | | B.7 | | | > ----------------- ----------------- ---------- > | | > --------------------------------------------------------- network B > >so two parallel networks with some multihomed and some singlehomed hosts. >Further suppose that network B is preferable to network A, because of >load, politics or because it is 10x as fast (hint: FDDI vs Ethernet). >How would one set up addressing and routing for such a configuration? TOPS-20 had a concept (which I invented) called "preferred IP address" and "preferred network" which answered this question. There was, from the beginning, a "default IP address" which was used in IP datagrams where it was not obvious which local address of a multi-homed host was best to use as the source IP address. The problem was that very often network A would be a lower-speed backbone and network B a higher-speed stub network. The default mechanism would ensure that host foo would use its A.1 address in talking to host zot and host zowie on a network C (since the only way to reach the B.6 address from outside of network B would be to go through an A->B gateway, so you might as well use the A.1 address and save a hop). In talking to host bink which only had a B.8 address, host foo would use its B.6 address. The problem was which address to use for bar. Hence the "preferred" address and network, which would take precedence in any choice between a "preferred" and any other (including the default) address. Foo and bar would make network A be "default" and network B be "preferred." I'm surprised Unix hasn't picked up on this yet. _____ | ____ ___|___ /__ Mark Crispin, 206 842-2385, R90/6 pilot, DoD#0105 _|_|_ -|- || __|__ / / 6158 Lariat Loop NE "Gaijin! Gaijin!" |_|_|_| |\-++- |===| / / Bainbridge Island, WA "Gaijin ha doko ka?" --|-- /| |||| |___| /\ USA 98110-2098 "Niichan ha gaijin." /|\ | |/\| _______ / \ "Chigau. Gaijin ja nai. Omae ha gaijin darou" / | \ | |__| / \ / \"Iie, boku ha nihonjin." "Souka. Yappari gaijin!" Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
hedrick@athos.rutgers.edu (Charles Hedrick) (07/04/90)
You haven't gotten an answer because there's no good answer. It depends upon the routing and domain technology that you use, and even then solutions tend to be kludges rather than general solutions. We prefer to keep all routing knowledge in our routers, so generally hosts do not run routing protocols. Our routers do proxy ARP, so we normally use default routes with a zero metric, i.e. route add default `hostname` 0 This causes all destinations to be treated as if they were on the local Ethernet. With more than one Ethernet address, I normally set things up to use the default on the "preferred" Ethernet, and hardwire routes for the specific subnets that I want on the other Ethernet. Typically it's just the connected subnet, which of course happens automatically. The problem with this is that you don't automatically change to take advantage of the secondary network if the primary one is down. However Ethernets so seldom go down that this isn't a concern for me. In general the Internet has not solved the problem of how hosts find routers, particularly with multiple Ethernets. There are lots of solutions known in principle, but the commonly used TCP/IP implementations don't have the right features to use the known solutions. 4.3 is a lot better than 4.2, but still doesn't really supply all the necessary features. The IETF hasn't helped, by failing to specify a gateway-finding mechanism, such as the proposed "ICMP wheres-my-gateway".
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (07/05/90)
In article <7050@star.cs.vu.nl>, sater@cs.vu.nl (Staveren van Hans) writes: > Recently I posted a question ... > Further suppose that network B is preferable to network A, because of > load, politics or because it is 10x as fast (hint: FDDI vs Ethernet). > How would one set up addressing and routing for such a configuration? > ... > Hans van Staveren > Vrije Universiteit > Amsterdam, Holland This problem exists within FDDI itself. FDDI is a dual ring of two 100Mbit counter rotating rings. 100Mbit/sec is only 10 times faster than 10MHz ethernet, and so is not considered "fast" by some of us. Notice that workstations today are 100 times faster than in the early 1980's when 10MHz ethernet became popular (i.e. 0.25-1.0 VUPS then and 5 to 200 VUPS now) (1 VUPS=1 "MIPS"=1 VAX 11/780). The birthday paradox ensures that either an FDDI ring will almost never be "wrapped" or it will be partitioned too much of the time. This means that dual attached, dual-MAC stations could at least in principle push more bytes than single-MAC stations. Unfortunately, the only currently publically demonstrated and known scheme for using both rings involves using two IP networks, one for each ring. This works, but is at best a clunky kludge. In the absense of some smarter routing, applications must somehow split their traffic between two IP hostnumbers. There are applications for which this is not a hardship, but it is in general far from satisfying. Proposals for combining both rings into a single IP network have been made, but to the best of my knowledge, there is no such single-IP network proposal that has had all of the holes, gotchas, and boundary cases covered. The single-network proposals involve varying but substantial amounts of complexity in the link layers, including extensions to ARP. As far as I know, the current draft standards (ie. IETF) suggest using a dual-IP-network until a single-IP-network scheme is completed and accepted. It would be really swell if someone could solve the FDDI-ethernet load balancing problem that at least two people have mentioned in recent months in this forum. It would make the trivial to implement dual-IP-network solution for FDDI tolerable, eliminating the need for the complicated ARP and other link layer extensions needed for the single-IP-network ideas. Vernon Schryver Silicon Graphics vjs@sgi.com
kwe@bu-it.bu.edu (Kent England) (07/16/90)
In article <7050@star.cs.vu.nl>, sater@cs.vu.nl (Staveren van Hans) writes: > Recently I posted a question to these groups to which, to my surprise, > I received no reactions at all. This seems strange since it addresses a > problem that many of us are going to face. Now there is of course the > possibility that this is so obvious that you were all embarrassed by > the question, but I doubt it. > > Suppose part of a network looks like this > > --------------------------------------------------------- network A > | | | > ----------------- ----------------- ---------- > | A.1 | | A.2 | | A.3 | > | Host foo | | Host bar | |Host zot| > | B.6 | | B.7 | | | > ----------------- ----------------- ---------- > | | > --------------------------------------------------------- network B > > so two parallel networks with some multihomed and some singlehomed hosts. > Further suppose that network B is preferable to network A, because of > load, politics or because it is 10x as fast (hint: FDDI vs Ethernet). > How would one set up addressing and routing for such a configuration? > What is the Internet Protocol supposed to do? In the TCP/IP frame of reference, IP was designed to route internet datagrams from source address to destination address. IP understands interfaces. But applications understand hosts/servers/service-entities. How does one tie an "entity" to a "set of addresses" as one moves down the protocol stack? How does one deal with so-called multi-homed hosts? The answer is, IP does not deal with the issue. Should it? Good philosophical question... and can of worms. Let us assume that IP should not deal with entities, only interfaces (addresses). Can the applications (or some other level in the stack) deal with the translation of entity name to "ordered set of addresses"? I think they can. I would suggest that the place to attack this problem is in the resolver. I recall discussions in times past about whether the name servers should be able to do this based on source address, but it seemed to me at that time that that was impossible for the name servers to do, since the source entity could be multi-homed. The resolver will need to be able to get some kind of routing or preference metric from the network layer. Many options. I would also suggest that there are many places in the protocol stack where a domain name would work better than an ip- address. Of course, machines may have many names, but at least we have the concept of canonical name. We also have the concept of multicast (implying groups of servers that are in some sense equivalent). So we are torn in search of the correct paradigm and are tied to others' past decisions in the history of TCP/IP. More grist for the philosophers... --Kent