Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!psuvax1!rutgers!elbereth.rutgers.edu!madness.rutgers.edu!hobson From: hobson@madness.rutgers.edu (Kevin Hobson) Newsgroups: comp.protocols.appletalk Subject: Re: Large AppleTalk networks Message-ID: Date: 5 Mar 91 11:28:14 GMT References: <9102191949.AA21308@hac2arpa.hac.com> <1991Feb20.173801.3301@bwdls61.bnr.ca> Organization: Rutgers Telecommunications Lines: 66 To: bschmidt@bnr.ca bschmidt@bnr.ca (Ben Schmidt (BNR)) writes: >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? I personally do not like tunneling since the implementations I have seen use udp IP packets for it's transport. Since appletalk does not have similar Time-To-Live (ttl) in it's packet header (write a program similiar to IP "traceroute"), I would like to know how do one solve a "flapping" network. From my experience with IP, DECNET, and Novell, the only reliable method for diagnostics the problem is to use SNMP and poll every second for a routing update from the gateways involved. Once you have tunnelled your appletalk packet, depending on the path the IP packet takes (in a redundant network), you now have to look at the IP gateways involved. I do not think Apple (or any or the above companies) will have utilities to deal with encapsulated appletalk packets being drop (or rerouted) on and IP network (or DECnet/Novell). >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. Well, that HOP count has constrain some of our departments around our state-wide network when primary route has broken and they use the redundant route :-). Appletalk was developed for LAN not WAN. User community push it. I do not blame Apple for this reason but I blame them for saying it works over a WAN when third party vendors made it possible. Appletalk is not as mature as TCP/IP (or (sic) DECNET). Novell has the same problem. >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. If the person knows nothing about UNIX workstations, IBM 3090 mainframes, etc. that TCP/IP network is as good as a dead appletalk network. When was the last time, a person ask someone how to use UNIX TeX and lpr to format and print a paper after the appletalk network has gone down? I think that person will be calling on someone to fix the appletalk network or go to another location working appletalk network to do their work. >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 -- Kevin Hobson Internet: hobson@rutgers.edu Rutgers - The State University UUCP: {backbone}!rutgers!hobson P.O. Box 879, RUCS, Hill Center, Busch BITNET: hobson@{cancer,pisces}.BITNET Piscataway, N.J. 08855-0879 PHONE: (908) 932-4780