Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!b-tech!netnews.engin.umich.edu!billkatt From: billkatt@caen.engin.umich.edu (billkatt) Newsgroups: comp.protocols.appletalk Subject: UDPTalk as a backbone Message-ID: <1989Sep3.063402.22872@caen.engin.umich.edu> Date: 3 Sep 89 06:34:02 GMT Reply-To: billkatt@caen.engin.umich.edu.UUCP (billkatt) Organization: Univ. of Michigan College of Engineering Lines: 112 I really cannot believe that so many people would be so enthusiastic about UDPTalk on a group called comp.protocols.appletalk. UDPTalk is, to steal a quote, a "complex non-solution to a simple non-problem". UDPTalk is good for allowing UNIX machines to communicati an a AppleTalk network, but it is not a protocol to ROUTE AppleTalk on top of. We tried it for two years here at the University and have decided we can go no farther with it. We are currently negotiating with Proteon for AppleTalk routing software for our 80Mbit/sec Fiber Token Ring. Here is an explanation of why UDPTalk is not the savior that the poster from Kinetics would have your believe. It can NOT be used to allow two Macintoshes on the Internet to communicate (without serious trouble). +---+ +-----------+ +---+ ! A +---------+ IP router +---------+ B ! +---+ +-----------+ +---+ For the all intensive purposes, the single IP router shown here can be replace with as many IP routers as you want. Macintosh A will NEVER be able to communicate with Macintosh B via UDPTalk. In order for the two Macintoshes to communicate with each other, they must know of each others Networks. The way to find this is for a Mac (for example, A) to listen for RTMP packets containing information about other networks (i.e. the network B is on). Since there is no AppleTalk router on network A, network A never learns of network B, and vice-versa. +----------------+ +---+ +-----------+ +---+ +----------------+ ! ATalk router 1 +---+ A +----+ IP router +----+ B +---+ ATalk router 2 ! +----------------+ +---+ +-----------+ +---+ +----------------+ For all intensive purposed, the single IP router shown here can be replaced with as many IP routers as you want. In this case there are routers (i.e. sources of RTMP packets) on each network. But the Macs will still never be able to communicate with each other. AppleTalk router 1 broadcasts its RTMP info (about network A) on network A. This Mac A learns that it is on network A. But, the IP router does not understand the content of the UDP packet containing the RTMP info, so it does not pass it on to network B, since broadcasts are limited to a single network in IP. Again, Macintosh A never learns of Macintosh B. There are only a few ways for Macintosh A on one IP subnet to learn of Macintosh B on another IP subnet. One possibility is that the IP routers understand to pass RTMP packet broadcasts through to its other side. This has two problems. The first problem is where to stop. If there were routers like this on the Internet, everyone would be on the same AppleTalk Internet (time to test the limit of zones in the Chooser, eh?) but it wouldn't matter because the volume of broadcasts would jam the Internet. Second, to do this, you are making your IP router understand AppleTalk, so why bother with UDPTalk? And existing installations have to be modified to work anyway. A second possibility is to run a central administrator such as atalkad. This administrator preloads the AppleTalk machines with routes across the IP router. The problem with this is that all machines which want to communicate with UDPTalk have to be preloaded, i.e. they must understand UDPTalk. This ruins the possibility of having UDPTalk hosts available to all Macs. A variation on this theme is used by Kinetics, with their routers translating UDPTalk to AppleTalk (both EtherTalk and LocalTalk- based). This is also unsuitable for routing AppleTalk on IP. In this case only preloaded routers (FastPaths) can communicate across IP gateways. This makes it futile to use any other kind of AppleTalk router such as an Apple Internet Router. The problem is very similar to the second case above. RTMP packets are not passed from one side of an IP router to another. Thus, only routers in the same IP subnet as a gateway which was not in the preload table can communicate across this gateway. There is almost certainly a poor, kludgey solution to making UDPTalk work correctly across IP routers, but it would involve as much work and cost as finding a solution with only EtherTalk. For an example I submit our case at the University of Michigan. We currently have two AppleTalk "universes", that is AppleTalk Internets based on IP routing of UDPTalk. We have two because we have more than 64 routes (a limit inherent in atalkad). Currently, one of our universes has 39 routes and the other has 62 routes. I administer the one with 62 routes. (side note, I took over after Dave Falkenburg left to work at Apple) We have roughly 40 Kinetics FastPaths doing EtherTalk/LocalTalk to UDPTalk translation so AppleTalk can be routed via our 12 MBit/sec Apollo ring and our 80 MBit/sec Proteon ring. We have many IP subnets within our AppleTalk Internet. We spent approximately $2500 per FastPath (that's $100,000). We also have spent many hours modifying our atalkad table (atalkatab). What do we have to show for this? slow routing of AppleTalk and a lot of FastPaths crashing. Since we have to preload our gateways, we can not add any cheap ($280 educational price) Apple Internet Routers. And since our atalkatab is full, we cannot add anymore $2500 FastPaths even if we wished to. In short, we have an expensive network which we cannot expand. When we switch to routing AppleTalk on our Proteon (via EtherTalk on the Ethernets feeding in), we will be able to add as many FastPaths and Apple Internet Routers as we wish. In fact, some of the money we spent on FastPaths was unneeded since we have Mac IIx's available to run Apple Internet Routers. In short, UDPTalk as a routing protocol is an expensive stop-gap measure. If we had switched earlier, we could have save tens of thousands of dollars in hardware alone. This is in addition to the amount of time spent learning to administer a network like this. For the record, I am not against UDPTalk. But I do not like the claims made by Kinetics and others as the solution to bridge your AppleTalk networks through non-AppleTalk savvy routers. I think that only Charlie Kim really knew what UDPTalk was good for. Steve Bollinger AppleTalk Internet Administrator University of Michigan Computer Aided Engineering Network billkatt@caen.engin.umich.edu