Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!agate!riacs!cincsac.arc.nasa.gov!medin
From: medin@cincsac.arc.nasa.gov (Milo S. Medin)
Newsgroups: comp.protocols.appletalk
Subject: Re: Administrative overhead of routing multiple protocols through cisco
Message-ID: <1991May21.014822.16834@riacs.edu>
Date: 21 May 91 01:48:22 GMT
Article-I.D.: riacs.1991May21.014822.16834
References: <9105171831.AA22334@psuoradm.cc.pdx.edu> <May.18.21.16.18.1991.13337@athos.rutgers.edu>
Sender: news@riacs.edu
Reply-To: medin@cincsac.arc.nasa.gov (Milo S. Medin)
Organization: NASA Science Internet Project Office
Lines: 50

>...
>If you have lots of Macs there is probably no way
>to avoid routing Appletalk.  Can you really afford to be unable to
>access printers, servers, etc., around the campus?  But if you have a
>substantial network, expect to have a person doing Atalk support.
>...

Chuck, it's clear that most campuses will have to bite the bullet and 
support Appletalk around their facilities at some point, if there 
a fair number of Mac's around.  But this doesn't mean all the problems
with excess dynamicism that Appletalk "classic" is known for.  

At Ames, we have a huge number of Mac's.  I think we ranked in the top 10 in total
number of Mac's on site in some Mac rag's survey of large mac sites.  Almost
all these mac's are wired together via the campus lan, but instead of 
using Appletalk classic, we run a modified KIP and "static" routing via atalkad
instead of RTMP and ZIP and all that running around.  The campus net
backbone is right now basically a huge bridged system, nearly the worst
case situation for Appletalk, and things work pretty well with 70+ Kboxes
and a few Gatorboxes sprinkled around the facility.  No, Phase II isn't supported,
and while many mac's have ethernet's in them, they use the localtalk interfaces
to run Mac stuff, and use MacTCP stuff on their ethernets.  One day, when 
we have "internal node" support for Mac's, they'll be allowed to use Appletalk
via their ethernets as well.  Besides, most of the applications our scientists
want/need high performance for are really IP based anyways, talking to the
various "real" computers around the facility and the world.   

All this works by and large pretty nicely, and atalkad things are taken care of
by an operations type (ie not a network weenie), and centralized management
lets us know who attaches to the network so we can keep track of them
and make sure things keep working.  If network management is important
to you, you have to be able to enforce some restrictions on what the network
looks like and is built out of.  I realize this goes against the grain
of what most appletalk types want, but sometimes you just have to put your
foot down, if you need to use the net for other things.   

I'm not saying what we do is perfect, but it supports a huge appletalk
system with little engineering labor required, and avoids the need to
deal with RTMP and such.  Maybe one day things will work much better and
we won't have to resort to doing this sort of thing, but for now, we have to
do what we can.  Note if you wanted to support a lot of different vendors,
your support requirements go through the roof because getting the vendors
to do the right things with KIP isn't easy, but both Shiva and Cayman seem
to be trying real hard to make their code work well with KIP.  


							Thanks,
							   Milo

PS usual disclaimers apply