Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!hercules!fernwood!portal!cup.portal.com!rpA-Inc
From: rpA-Inc@cup.portal.com (RP and Ainc)
Newsgroups: comp.protocols.appletalk
Subject: (Temporary) Conclusion to the Internetwork Router/TOPS Saga
Message-ID: <31240@cup.portal.com>
Date: 28 Jun 90 23:54:24 GMT
Organization: The Portal System (TM)
Lines: 63

Thanks to:

Reinhard Doelz / Biocomputing Basel <sun!SWIBA0.VMSMAIL.UNIBAS.com>
Jennifer B. Minge <apple!jbm>
brianb@kinetics.com (Brian Bulkowski)
boerner@emx.utexas.edu (Brendan B. Boerner) 

for their replies to my original query. 

To restate the problem: the Apple Internetwork Router was interfering with 
the TOPS connection between a Mac II and a Sun 3/480 server. The consensus 
among the respondents was that one should:

a. Make sure all nodes are running Phase II Appletalk (Ethertalk 2.0)
b. Ditch TOPS.
c. Ditch the InterNetwork Router.

Only (a) appeared to be feasible. Further investigation did reveal that
in fact, the Mac II being trampled on was running Phase I AT (there is no
such choice with TOPS, you get what you get). TOPS tech support was
helpful and suggested Zone name and number changes which didn't work.
Apple Tech Support (after about 1/2-hour on hold and endless queries
about "dealer name and number") suggested we get new Ethernet cards 
("There is no upgrade path for your Apple Ethernet card.")

Let's see now:
- Phase II Ethertalk crashes on the Mac II Ethernet board (old ROM level).
- TOPS has no plans about Phase II Appletalk (and in fact, appears to have
  conflicts with the driver).
- The Internetwork Router, does not support routing between multiple zones 
  off the Ethernet if Phase I is used. 
- Mixing Phase I and II Ethertalk drivers seems to make everyone unhappy.

Quite a mess, isn't it?

Temporary solution: The Sun, all the other group's Mac's as well as the
interrupted Mac and everyone else is thrown onto a single Zone, all running
off of Phase I Appletalk drivers. Though this is not at all desirable, it 
at least allows the TOPS link to function while the IR package is active 
(we have had to schedule "down-times" on the IR to let people use TOPS). 
This solution requires tighter security on the Sun though, since now 
anyone with TOPS can get to the Sun server.

Fortunately, TOPS asks for valid Sun/Unix username/password information
before allowing mounts to take place, and also honors Unix ownership
information even if someone does find a valid password.

This problem will not go away. It has only been identified on one floor. 
The building has 31 floors and is completely connected through a broadband 
Ethernet backbone, as well as various bridges, and many many routers. I 
hear there are a few other TOPS nodes out there. I am fairly certain the 
IR has also screwed up their connections, it's just that they haven't tracked 
it down to this floor yet (shades of the movie "Brazil"). We're bracing
ourselves though...

Anyway... thanks for all the help.
Thanks again to all the respondents for their astute observations...


Ramin Firoozye'
rp&A Inc.
San Francisco, CA.
415.826.3113