Newsgroups: comp.protocols.appletalk
Path: utzoo!utgpu!cunews!bnrgate!bwdls61!bnr.ca!bschmidt
From: bschmidt@bnr.ca (Ben Schmidt (BNR))
Subject: Re: Large AppleTalk networks
Message-ID: <1991Feb20.173801.3301@bwdls61.bnr.ca>
Sender: usenet@bwdls61.bnr.ca (Use Net)
Organization: Bell-Northern Research
References: <9102191949.AA21308@hac2arpa.hac.com>
Date: Wed, 20 Feb 1991 17:38:01 GMT

In article <9102191949.AA21308@hac2arpa.hac.com> 
BALAMUT@morris.dnet.hac.com writes:
> I am interested in opening a dialog on large scale AppleTalk networking.
>
> I work for Hughes Aircraft. We have a very large extended Ethernet network.
> It spans most of southern California and several other states. We are 
> basically a bridged network. We currently 'support' about 60+ protocols
> on our Ethernet.
>  
> We filter AppleTalk Phase 1 between all major sites. We are filtering
> Phase 2 between several areas. The phase 2 filtering is due to various
> problems that we have experienced. Excessive multicasts, invalid RTMP
> data, phantom zones, to name a few.
>  
> ps: we have about 8,500 mac, 15,000 pcs, about 2-3000 other appletalk
>     devices. (thank goodness they are not all networked).

Morris, we've built an AppleTalk/IP network that links all our labs
across 3 countries (US, Canada, UK).  It's entirely ATP1-based and
built using cisco routers.  The *slowest links* run at 56kbits/sec.
Totalitarian control, (oops, I mean "administrative discipline") has
allowed us to minimize the number of different types of AT routers and
their individual configurations to stabilize the network.  It works
well.

Unfortunately AT (P1 or P2) is falling out of favour here as a viable
means of building WANs.  While our existing AT network: 6 cities, 250
nets, 2500 Macs, 400 printers, 60 servers, etc. is manageable, we're
unlikely to obtain approval to growing it to include say, the 70+
cities our parent corporation's global TCP/IP network, of which we are
a part, currently reaches.  The major issue is the lack of a scaleable
replacment routing protocol for RTMP (which suffers from a 15 hop
limit, and routing based solely on minimum hop count without regard to
bandwidth).  Subsidiary issues include ensuring that the various AT
routers can manage routing tables of 100's of nets/zones, and maintain
them efficiently.

Apple, goaded by customers like us, as well as hard working souls at
some of the AppleTalk router vendors (Cayman, Shiva, Webster, etc.),
is looking at doing something.  This something is apparently taking
the form of standarizing the boundary between an AT network and an IP
tunnel.  (FTP to apple.com for details.)  I don't know a lot about it,
but "tunnelling" leaves me with ambilvalent feelings:  if it solves
some problems, fine.  On the other hand if it doesn't address the
current scalability problems and at the same time introduces new ones:
maintaining static routes, performance hits for encapsulation
/decapsulation of AT, lack of diagnostic tools for encapsulated AT,
etc., I wonder whether I can use it to solve any of our problems?

Our approach has been to network AT where it makes sense, mindful of
the 15-hop count limit and AT's frustrating propensity to choose a
single hop 56kbit/s path over a 2-hop T1 link.  BUT, *at the same
time*, to ensure that *every* Mac also has access to TCP/IP protocols.

Hence we use only Macs directly attached to Ethernet, or behind
*DDP/IP* routers on LocalTalk. NO AT-only ghettos allowed here!  This
way, if the Mac correspondents can't reach the desired node by AT
protocols, at least they have the much large TCP/IP network to fall
back on, not to mention the far wider range of potential nodes to
communicate with:  UNIX workstations, IBM 3090 mainframes, etc.

Ben Schmidt     Bell-Northern Research, Ltd.   Ph: (613) 763-3906
Information     P.O. Box 3511, Station C       FAX:(613) 763-3283
Technology      Ottawa Canada K1Y 4H7          bschmidt@bnr.ca