Xref: utzoo comp.protocols.tcp-ip:12024 comp.protocols.tcp-ip.domains:179 Path: utzoo!attcan!uunet!lll-winken!elroy.jpl.nasa.gov!sdd.hp.com!ucsd!rutgers!aramis.rutgers.edu!athos.rutgers.edu!hedrick From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: Re: parallel networks problem Message-ID: Date: 3 Jul 90 21:11:12 GMT References: <7050@star.cs.vu.nl> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 27 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".