kint@software.org (Rick Kint) (04/25/89)
Bob Weiner writes: > I finally found an Apollo tech rep in Texas who knew about this and > said that yes, none of the routing on the non-gateway nodes will work > after the gateway node is taken down and then rebooted. He said we > would need a script that checked every so often if the gateway had > gone down and then executed /etc/routed -f -h on all of the other > nodes again. This brings up something I meant to ask long ago. TCP 3.1 was a major improvement. One of its best features was that the routed worked, delivering us from static routing. Having delivered a working routed, Apollo added the -h option so to make routed exit after building a routing table, essentially returning us to the pre-3.1 static routing days. Why? It seems that one hand gives us dynamic routing, and then the other hand castrates it. When we set up routing after TCP 3.1 came in, we saw three alternatives: 1) Run /etc/routed (no options) on all systems. On gateways, routed advertises itself as a gateway; on non-gateways, routed listens for these messages and updates the routing table accordingly. When a gateway ceases broadcasting its availability, routed on non-gateways deletes it from the table and adds another route (if it exists) automatically. This is how we use routed on our Unix systems, and at TCP 3.1 it proved to work on our Apollos as well. 2) Run /etc/routed -h on hosts and /etc/routed with no options on gateways as recommended in the release notes. On non-gateways, routed listens for gateway broadcasts and exits five minutes after it sees no changes. If a gateway goes down after this five-minute period (a problem which generally comes to light when a user is unable to rlogin or rcp), routed is no longer there to update the routing table. So /etc/routed -f -h must be run manually on non-gateways to update the routing table. This is a lot of work, and doesn't prevent problems. 3) Keep the old system where tcp_server calls tcpinit and makegate. The limitations of this setup for BSD connections are well known. We chose the first; we don't use -h, and TCP/IP works splendidly. A single gateway crash no longer guarantees the inaccessibility of other networks. One major problem area is now gone. If we used -h, we'd be just as badly off as we were before TCP 3.1. Can anyone explain the rationale behind the -h option? Is there something I'm missing? Are we just uniquely lucky in having routed work for us? We have four Domain rings and one (logical) ethernet, with alternate paths between all networks. We are mostly still at SR9.7.0.3 or SR9.7.5 and use the BSD flavor of TCP 3.1, and the vast majority of our TCP use is BSD-oriented (X, rlogin, NFS, /usr/ucb/ftp). But we don't use the -h option on our SR10.1 nodes either and routed still works fine. ================== Rick Kint Network Utility Infielder Software Productivity Consortium CSNET: kint@software.org Internet: kint%software.org@relay.cs.net UUCP: {...}!uunet!sunny!kint
tvb@bugeater.UUCP (Terry Bush) (04/26/89)
> 1) Run /etc/routed (no options) on all systems. On gateways, routed > advertises itself as a gateway; on non-gateways, routed listens > for these messages and updates the routing table accordingly. When a > gateway ceases broadcasting its availability, routed on non-gateways > deletes it from the table and adds another route (if it exists) > automatically. This is how we use routed on our Unix systems, and at > TCP 3.1 it proved to work on our Apollos as well. Rick, I have come to nearly the same conclusion that you have concerning TCP routing. One exception is that I run routed with the '-q' option on all non-gateway nodes. This assures me (falsely maybe) that those hosts do not add to our already loaded network traffic. Peace, Terry V. Bush The Veritable Bugeater