Newsgroups: comp.dcom.sys.cisco
Path: utzoo!utgpu!cunews!bnrgate!bwdls61!bnr.ca!bschmidt
From: bschmidt@bnr.ca (Ben Schmidt (BNR))
Subject: Re: Wide Area ApplTalk
Message-ID: <1991Mar5.005841.23836@bwdls61.bnr.ca>
References:<32816@boulder.Colorado.EDU> <1991Mar3.235147.6931@bwdls61.bnr.ca>
Sender: usenet@bwdls61.bnr.ca (Use Net)
Organization: Bell-Northern Research
Date: Tue, 5 Mar 1991 00:58:41 GMT

In article <1991Mar3.235147.6931@bwdls61.bnr.ca> fortinp@bwdls56.bnr.ca 
(Pierre Fortin) writes:
> Yes, ALL must be unique!  So we centrally control these.  We have also
> specified recommended naming conventions for the zones (remember the 
Chooser).

Essentially you want the entire zonename to be visible.  With the current 
System Release 6.0.x Chooser that means approximately no more than 16 
characters.  With the Chooser in System Release 7.0, the full 32 
characters allowed under ATalk's ZIP for zonenames, should be visible.

> 
> >     3. What services are supported on the WAN?
> >        Timbuktu, AppleShare, Printing, Public Folder, X-Windows?
> 
> All, though I'm not absolutely certain about Timbuktu (Ben??)

Yup, Timbuktu works over our AppleTalk WAN.  Performance varies on who you 
talk to.  For file transfer, early versions of Timbuktu used some pretty 
non-optimum settings for ADSP.  Newer versions seemed to have addressed 
this, although screen-sharing is still done over DDP which means that 
error-recovery, timeout, packet re-ordering is completely under program 
control.  It's anyone's guess how well the program handles narrow WAN 
links compared to Mac-to-Mac over Ethernet.

> >     4. How do you address security?
> 
> User education. 

Lot's of.  For example, don't leave things in Michael Pierce's Public 
Folder INIT.  Don't leave your Timbuku wide-open to remote access.  Ensure 
that Guest Access is truly limited on your private AppleShare fileservers. 
 I anticpate personal AppleShare in System 7.0 will introduce new ways for 
people to inadvertently expose themselves on the network, but that's what 
makes life interesting.  :-)

>We also provide the network applications preconfigured to
> turn off server functions (disallow incoming ftp on the telnets, etc.)

This is a tough user education point, as so many people are unaware that a 
very useful FTP server is built into just about every Mac telnet going, 
and they should disable when they don't need it, or setup a password.  
(Setting up a password in NCSA telnet, for one,  is decidely 
un-Mac like   :-)

And we monitor the number of ATalk nets and zones on our internet daily to 
detect failures or accidental (or otherwise) connection of our ATalk 
network to another, with the security exposure that that implies.

> Oh, they're using AppleShare
> alright, but I'd be surprised if they are printing over the WAN (better 
to
> get the file and print locally...)

Printer access is done via PAP and like AFP, it doesn't always responsd to 
narrow WAN links, dropped packets, etc. in an optimum manner.  If only 
Apple would let you tune timeout's, and window sizes!!  And of course 
LaserWriters have their own job-kill timeouts which can make printing a 
large report over a WAN, an exercise in futility.

>       7. What ATalk routers do you have on your AT internet?
> 
> ONLY cisco and KFP4s running K-Star.  If you don't want to turn grey (not
> to mention hot shades of red :^), get rid of all other types.  Our goal 
is 
> to migrate all our Macs onto Ethernet and do away with as many KFPs as 
> possible.  

Well I'd like to temper that for my friends at Cayman, NRC, Webster, etc, 
by saying that each AppleTalk router has it's own idiosyncracies.  When 
building a large internet with finite resources, it's better to have a few 
vendor types whose idiosyncracies you understand **well**, then having a 
vendor-of-the-month approach.  So the message is less "which vendor(s) you 
use", and more "pick a small number of vendors and know their product 
well".  Sort of like the 1990's morality on safe sex!   :-)

And as far as Ethernet is concerned - well if you've got 1000's of 
Ethernet drops for UNIX workstations anyhow, it can actually be cheaper 
from the point of view of maintenance of multiple technologies, to 
encourage direct Ethernet connection for your Macs, new laser printers, 
etc, rather than encouraging a proprietary physical layer topology like 
LocalTalk.  But of course, each site is unique.

>       8. How big an AT internet can you build?
> 
> That's an easy one:  it must *NEVER* have a diameter (in *any* direction)
> which will exceed AT's 15 hop limit.  Remember:  a Mac on LocalTalk to a 
KFP
> on Ethernet to a cisco, over a serial link, another cisco, ethernet to 
another
> KFP to another Mac results in a network diameter of **FIVE** nets... and 
the 
> limit is 15...!

You can engineer around this, although WAN's cannot be cheaply configured 
as star topologies, the way that MAN's can.  I mean, it's a lot cheaper to 
daisy-chain links around the world, then star everything back to Paris, in 
order to minimize hop count!  :-)

But an even more frustrating problem in a mesh network, is that your 
primary links can be ignored by AppleTalk, in favour or your skinny backup 
links.  The classic "1" 56kbit/sec link is better than "2" consecutive T1 
links decision, made by all distance routing algorithms, including Apple's 
RTMP.  Hence it can be downright difficult for an AppleTalk WAN to take 
advantage of automatic fault-tolerance without ensuring all links are the 
same speed.

> Seriously, the first thing you want to do is have (in great gory detail):
>   - a list of *ALL* ATalk routers on the LANs of interest

remember you're going to have to ensure that these are properly 
configured, maintained, upgraded (ATalk phase 2, etc), or face choas...

>   - a list of *ALL* ATalk net numbers on these LANs

for uniqueness of ATalk net numbers...

>   - a list of *ALL* the zone names for these nets

the Chooser sorts the list alphabetically, so a domain-style naming scheme 
will give you a geographical sorting of your zones...lower-case zone names 
make better use of minimal Chooser zonename specify than upper-case 
zonenames, since a proportional font is used.

>   - a list of *ALL* the users who have dial-up devices on your LANs

It won't help for you to ensure that all AT net numbers are unique if 
someone is routinely dialing-in from the local University or competition 
down the road and inadvertently interconnecting your ATalk network with 
theirs with each phone call.  The clash of AT net numbers will mess up the 
routing tables.  The appearance of new AT net numbers from the foreign AT 
network can cause what's known as a ZIP storm as all your AT routers 
attempt to find out the zonenames associated with the dialed-in ATalk 
internet.  :-)

...and lastly, Good Luck, you'll need it...  :^)

Come now, it's not that bad.  There's nothing here that you didn't learn 
setting up a global DECnet and IP internet, right?

best wishes, 

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