hedrick@athos.rutgers.edu (Charles Hedrick) (05/19/88)
I agree in theory that hosts shouldn't know anything about routing. However I find that in practice, BSD-derived implementations make it hard to carry that out. Other implementations seem to have similar problems as well, but I know BSD the best. The simplest approach is to set a default route for a nearby gateway and depend upon it for redirects. The problem is, what if one of of the gateways goes down. There is no way to get a crashed gateway to redirect you back to the default, nor is there any way to handle a default gateway going down. However if you are more concerned with lines going down than gateways going down, that's a reasonable alternative. This is under 4.2. Under 4.3, routes will be declared down if a TCP connection is about to time out. This means that routing will return to the default. Theoretically I suspect one could specify several defaults, and if the first one goes down another one would be tried, but I haven't verified that. Our problem is that this only works for TCP. NFS doesn't talk to the routing layer, so if you have a path that is used only by NFS, and the route goes down, you lose. We are currently using a default with a metric of 0. This is effect makes our machines treat everything as local, and issue ARP's for everything. Since our gateways do proxy ARP, that works. However even this has a problem: ARP entries time out if they aren't used, but if somebody keeps retrying something, a bad ARP entry will stay there forever. In my view, 4.3 has made enough improvements that the default gateway approach is probalby better for 4.3-based code, while the proxy ARP approach is probalby better for 4.2-based code. But none of the approaches is a complete solution. Running RIP in passive mode sounds like it would be a complete solution, if your gateways run RIP. However it is going to create performance problems for networks with lots of diskless nodes. That's because when a packet arrives, all your workstations will have to swap in their copy of routed, and so you'll have lots of synchronized network traffic, which will likely saturate your network. I understand that a subcommittee of the IETF is working on this problem, and plans to add one or two new ICMP types. Unfortunately, this is likely to take several years to make it through the vendors (some of whom don't even do subnets yet). This is probably the biggest disadvantage of TCP/IP. It seems to take someone with a reasonable knowledge of routing to set up a network and add hosts to it. This contrasts with DECnet, where about all you have to do is set the DECnet address, and routing is handled automatically. I regard TCP/IP as a better protocol for larger networks, and the newer TCP/IP routing technology as better than DECnet phase IV (but probably not phase V). But I have to say that TCP/IP networks of small or moderate size appear to be harder to set up and to diagnose routing problems in.