Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!software.org!kint
From: kint@software.org (Rick Kint)
Newsgroups: comp.sys.apollo
Subject: Re: changing our net topology. advice needed.
Summary: Go for it
Message-ID: <2672@sunny.software.org>
Date: 16 Jan 90 16:27:36 GMT
References: <90@blender.UUCP>
Sender: usenet@software.org
Reply-To: kint@software.org (Rick Kint)
Organization: Software Productivity Consortium, Herndon, Virginia
Lines: 73

In article <90@blender.UUCP> herb@blender.UUCP (Herb Peyerl) writes:
>We are in the midst of submitting a proposal to the big-wigs to
>obtain some more admin nodes and alter our network topology

	We have this:

        1
       /|\
      | 4 |
      |/ \|
      2---3

(My apologies for the diagram; there are limits to character graphics).

	The idea is that rings 1, 2, and 3 (which correspond to floors
in our building) can get to each other directly, and ring 4 (the control
ring, which has central servers and the systems on which backups are run)
can get to rings 1, 2, and 3 directly--we didn't want backup traffic
competing with user traffic.  We use six routers, between the following
pairs of rings: 12, 23, 31, 41, 42, and 43.  The first three are also
gateways between the Apollos and Ethernet and run NFS.  These are DN3000s
with extra memory.  There are about 180 nodes total.

	We can lose any two routers without losing connectivity.  With a
year of experience behind us, yes, it's overbuilt, but these nodes handle
TCP/IP traffic as well.  Older TCP/IP was very unstable so we needed the
redundancy then.

>1) Is the Domain routing smart enough to recognize that a gateway has
>gone down and automatically route packets the other way around???

	Sure.  We've gone for extended periods without noticing that
a gateway has crashed (or that routing has died).  One may have doubts
about Apollos in some areas (like UNIX compatibility), but it's hard to
fault their networking.  It just works...

>2) Is there any sort of special setup in the rtsvc or startups that we
>should do to reflect this topology and possibly account for the alternate
>routing???

	No.  The alternate routing will happen magically at need.  Just
make sure that the rtsvc commands are correct.

>3) Is anyone doing this and have you ever experienced any rude and
>twisted problems with this sort of thing?

	The only twisted problem we've seen was our own fault.  If two
gateways broadcast different network numbers (set in the rtsvc command)
on the same ring, life gets very interesting very quickly.  If you move
gateways around, don't be sloppy.

>4) How good is TCP/IP for dealing with this sort of thing.  I would
>think routed would handle this with relative ease.

	Yes, with a couple of reservations.  In early SR10 releases,
Apollo recommended using the "-h" option to routed on non-gateways.
DO NOT DO THIS;  it was removed from rc.local at SR10.2.  This turns
routed into the equivalent of makegate;  it sets up the routing table
and then exits.  You get a process slot back but lose dynamic routing,
which is often not a beneficial tradeoff.

	The length of time it takes to update the routing table depends
on a number of circumstances (see the man page for routed, or RFC 1058).
If you are replacing a route with a more expensive route, it takes longer
and a connection may die if one end is pounding on it in the interim.

	Note that you don't get TCP/IP routing automatically when you
have Domain routing.  For the first you use routed, for the second rtsvc.

--
Rick Kint                          CSNET:   kint@software.org
Software Productivity Consortium   ARPANET: kint%software.org@relay.cs.net   
Herndon, VA                        UUNET:   ...!uunet!sunny!kint