jln@casbah.acns.nwu.edu (John Norstad) (10/23/90)
At Northwestern University we are currently experiencing explosive growth in both our IP and AppleTalk internets. We have several dozen IP networks joined together with Cisco routers and PC routers, plus several dozen AppleTalk networks. I have been relying heavily on Shiva FastPath 4 boxes and atalkad tunneling to join together AppleTalk networks into one big campus AppleTalk internet. This strategy is currently working very well, and we're quite happy with it. We also have a number of Caymen Gatorboxes on campus, and I hope to also have them participate in atalkad tunneling, although I haven't been able to get it to work yet. My problem is that I'm beginning to worry about various limits in atalkad. According to my ancient KIP documents, and according to the output of atalkad -c, I'm approaching some of these limits. The documented limits are 256 bytes for all zone names (I'm up to 191 bytes), 32 zones (I'm up to 16), and 64 routes (I'm up to 27). My first question is: Are these limits absolute? Is there any way to increase them? My second question is: What are the reasonable alternatives to atalkad tunneling for building a large campus AppleTalk internet? I know that Cisco routers can do AppleTalk routing, but PC Routers can't. Replacing all of our many PC routers with Cisco routers would be very nice for many reasons, and we'd all like to do it, but it's just too expensive. Replacing all of our FastPaths by Gatorboxes or vice-versa is also out of the question. I know that other universities have very large AppleTalk internets. How do you do it? John Norstad Academic Computing and Network Services Northwestern University jln@casbah.acns.nwu.edu
sec@cs.umn.edu (Stephen E. Collins) (10/23/90)
jln@casbah.acns.nwu.edu (John Norstad) writes: >At Northwestern University we are currently experiencing explosive growth >in both our IP and AppleTalk internets. We have several dozen IP networks >joined together with Cisco routers and PC routers, plus several dozen >AppleTalk networks. You ought to visit your alma mater and see your future. We're also experiencing explosive growth in networking on campus (isn't everyone?). We currently have well over 100 AppleTalk zones on campus, with around 200 FastPaths (a single zone can share several FastPaths). We have experimented repeatly with the GatorBox, but without success. (Their Tech support people always give up after a while; seems to be a problem with our large & strange network). We also have more IP networks than I care to count. The main backbone is segmented with Cisco routers for IP (and other) traffic, and has Apple Routers running in parallel with the Cisco routers to handle AppleTalk traffic. I wasn't involved with testing the Cisco AppleTalk support, but I seem to recall that Cisco routers and AppleTalk traffic didn't get along very well. >My problem is that I'm beginning to worry about various limits in atalkad. >According to my ancient KIP documents, and according to the output of >atalkad -c, I'm approaching some of these limits. The documented limits >are 256 bytes for all zone names (I'm up to 191 bytes), 32 zones (I'm up >to 16), and 64 routes (I'm up to 27). >My first question is: Are these limits absolute? Is there any way to >increase them? Most of these limits have increased quite a bit in the new FastPaths. Also keep in mind that you can set up a FastPath to configure itself dynamically; they don't all have to be in your static routing table. We try to limit the static routing table to only those FastPaths which are pointed to by CAP servers or need to be there for some other specific reason. The rest are dynamic. >My second question is: What are the reasonable alternatives to atalkad >tunneling for building a large campus AppleTalk internet? I know that >Cisco routers can do AppleTalk routing, but PC Routers can't. Replacing >all of our many PC routers with Cisco routers would be very nice for many >reasons, and we'd all like to do it, but it's just too expensive. >Replacing all of our FastPaths by Gatorboxes or vice-versa is also out of >the question. Also consider the Apple Router as I mentioned. It's a cheap solution for routing Appletalk packets on your IP network; it's been working well for us for quite a while. I'm not sure about the current state of the Cisco AppleTalk package. I'd also watch the GatorBoxes carefully as your network grows. We never figured out quite what the problem was on our campus. The GatorBox would run fine for a day or two, and and then hang up. >I know that other universities have very large AppleTalk internets. How >do you do it? I hope I gave you a few leads; feel free to contact me if you want any more information. If you ever visit your old homestead, drop in and we can give you a tour. >John Norstad >Academic Computing and Network Services >Northwestern University >jln@casbah.acns.nwu.edu Stephen E. Collins University of Minnesota Microcomputer & Workstation Networks Center sec@boombox.micro.umn.edu | sec@umnacvx.bitnet
hedrick@athos.rutgers.edu (Charles Hedrick) (10/26/90)
My preference is to move away from IPTalk to Ethertalk. My primary concerns are - that I want to put Ethernet cards in Macs, and that means they are going to run Ethertalk. Commercial Unix and VMS software also runs Ethertalk. IPTalk is fine if all you have is Localtalk, and need a way to connect Localtalk networks. But I don't think we're going to be able to deal with Localtalk bandwidth for long. As we move to Ethertalk, it makes more sense for our main routers to route Ethertalk as well as IP. - routing in mixed IPTalk/Ethertalk setups is obscure. You have Appletalk and IP routing protocols interacting in strange ways. Thus we are moving to use of Ethertalk for the main campus backbone. Fortunately all of our main routers are ciscos, which support Ethertalk. In some ways I prefer the IPtalk protocol, but since most products for Ethernet use Ethertalk, I don't see how we can stick with IPtalk forever. I haven't seen any problems with Ethertalk phase 1 in cisco's 8.1 release. 8.2 is still in beta, so I can't comment on it, but I certainly don't anticipate letting them take it out of beta without functional Ethertalk phase 1 and 2. The major Appletalk developer at cisco seems pretty good, and he seems to be in contact with the Appletalk developers at Apple to make sure everything is done in an approved manner. The IPtalk/Ethertalk transition is not without its problems. I think some of my colleagues are less than enthusiastic. I'm still doing a bit of tweaking of the CAP Ethertalk support. The big problem is that CAP Ethertalk has to use system-dependent facilities, so porting it to many kinds of Unix is going to be a lot harder than porting the original CAP. (It has to use system-dependent facilities because there is no standard way to ask a Unix system to give you all Appletalk packets addresses to a sort Appletalk port number. You end up either installing the packet filter software in the kernel or using some generic network hook, typically intended by the vendor for packet monitoring.)