BALAMUT@morris.dnet.hac.com (02/20/91)
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.
Please contact me (or this list).
Morris Balamut
balamut@hac2arpa.hac.com
(213) 513-5829
ps: we have about 8,500 mac, 15,000 pcs, about 2-3000 other appletalk
devices. (thank goodness they are not all networked).
bschmidt@bnr.ca (Ben Schmidt (BNR)) (02/21/91)
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
hobson@madness.rutgers.edu (Kevin Hobson) (03/05/91)
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