billkatt@caen.engin.umich.edu (billkatt) (09/03/89)
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.edumedin@nsipo.arc.nasa.gov (Milo S. Medin) (09/04/89)
Steve, I completely disagree with you. Forcing router vendors to spend time implementing more non-standard limited protocols is not what I want my vendors to do. Here at Ames, we essentially banned Ethertalk on our large bridged backbone network. We have not been sorry about the decision. Ethertalk is one of the poorest implementations I have ever dealt with. It broadcasts way more than is needed, and generates a lot more routing traffic than necessary. UDPtalk or IPtalk is MUCH nicer, and all my routers can switch IP. We sucessfully run IPtalk through routers all the time, and some of these routers are BSD machines, which I seriously doubt will ever understand Ethertalk. Our Mac's which directly connect to ethernet speak TCP/IP on the ethernet. It works fine. For Mac type applications, they have localtalk interfaces which connect to K-boxes which use the IP backbone as a transit, and can talk to CAP machines, etc... In general, if the application is performance driven, it can usually by handled by IP (our Crays don't speak Appletalk)... If Kinetics and whoever else only support Ethertalk would support IPtalk also, we'd certainly welcome them into our market of several hundred if not thousands of Macs. I'm sure the people at LBL (who also ban Ethertalk from their backbone) would also agree. In small networks, or even medium sized networks, I'm sure Ethertalk works out all right. But you judge a protocol by how well it scales, and Ethertalk doesn't scale very well at all. Large facilities like Ames have a lot of unique problems to deal with. IPtalk solves one of them. We like it a lot. Anyone that supports it in their products is part of our solution space... Thanks, Milo
billkatt@caen.engin.umich.edu (billkatt) (09/05/89)
In article <31297@ames.arc.nasa.gov> medin@nsipo.arc.nasa.gov.UUCP (Milo S. Medin) writes: >Steve, I completely disagree with you. Forcing router vendors to spend time >implementing more non-standard limited protocols is not what I want >my vendors to do. Here at Ames, we essentially banned Ethertalk on our >large bridged backbone network. We have not been sorry about the decision. I'm familiar with that situation. That's the way it was here until we found the limitations of UDPtalk. > >Ethertalk is one of the poorest implementations I have ever dealt with. It >broadcasts way more than is needed, and generates a lot more routing traffic >than necessary. UDPtalk or IPtalk is MUCH nicer, and all my routers can switch >IP. I don't see how you can say that. Phase 2 fixes many of the routing traffic problems of phase 1. As for the broadcasts, I agree. However, I don't see any other way to do name lookups. And name lookups ARE a good idea. They offer possibilities that other networking systems can't offer. I think Apple's interface to name lookups is poor, but their implementation is sound. I think the broadcast problem is overrated, though. With increasing processor speeds, the amount of overhead in receiving a broadcast not meant for you is becoming academic. And a little work on ethernet cards can make it so NO processor time is needed to reject broadcasts. We can't stay static with the times. Anyone who has a 10mbit ethernet for a backbone two years from now isn't taking themselved seriously. > >We sucessfully run IPtalk through routers all the time, and some of these >routers are BSD machines, which I seriously doubt will ever understand >Ethertalk. We do too, currently. We use atalkad. Is that what you use? > >Our Mac's which directly connect to ethernet speak TCP/IP on the ethernet. >It works fine. For Mac type applications, they have localtalk interfaces >which connect to K-boxes which use the IP backbone as a transit, and can >talk to CAP machines, etc... In general, if the application is performance >driven, it can usually by handled by IP (our Crays don't speak Appletalk)... I agree with what you say. MacTCP is quite fast and is a better idea for many Mac to Unix communications, anyway. What does that have to do with UDPTalk? CAP is the only exception (like I said), but CAP does not involve routing UDPTalk. > >If Kinetics and whoever else only support Ethertalk would support IPtalk >also, we'd certainly welcome them into our market of several hundred >if not thousands of Macs. I'm sure the people at LBL (who also ban Ethertalk >from their backbone) would also agree. Maybe you should research your facts. Kinetics INVENTED UDPTalk. The original FastPaths (1's) were invented to bridge LocalTalk to UDPTalk (EtherTalk didn't exist yet). What Kinetics doesn't support is atalkad and UDPTalk backboning. They don't support it at all, you ask them. I did. I was operating under the assumption they did and that everyone must be discontent with Kinetics. When I finally figured out that they only support it for communicating to CAP, it made sense. FastPaths work very well in that situation. > >In small networks, or even medium sized networks, I'm sure Ethertalk >works out all right. But you judge a protocol by how well it scales, >and Ethertalk doesn't scale very well at all. Large facilities like Ames >have a lot of unique problems to deal with. IPtalk solves one of them. >We like it a lot. Anyone that supports it in their products is part >of our solution space... If you are happy with UDPTalk, then you shouldn't be talking to me about scale. We were happy with UDPTalk when we were on a small scale, too. When you reach the limits of atalkad or don't want to spend $2500 per LocalTalk, you'll see it my way. Io hope people heed my warning. Many of you have probably read Dave Falkenburg's article on KIP/CAP. He was very pro-atalkad in that article. You should talk to him now (falken@caen.engin.umich.edu). If you read that article and found many good reasons to use atalkad and UDPTalk then, you should listen to me (or talk to Dave) and understand the reasons not to use UDPTalk now. We thought we had a great stopgap solution. We kept believing it until we had spent $100,000 on FastPaths. Then, within a few short weeks, we switched 180 degrees and realize we had spent about $40,000 too much. I finally have a little peace of mind, too, knowing that our network will finally work right again. If you are unhappy with AppleTalk, maybe it is for the same reasons I was. > Thanks, > Milo -Steve Bollinger (billkatt@caen.engin.umich.edu)
medin@cincsac.arc.nasa.gov (Milo S. Medin) (09/05/89)
In article <1989Sep4.202733.6326@caen.engin.umich.edu> billkatt@caen.engin.umich.edu (billkatt) writes: >I don't see how you can say that. Phase 2 fixes many of the routing traffic >problems of phase 1. As for the broadcasts, I agree. However, I don't see >any other way to do name lookups. And name lookups ARE a good idea. They >offer possibilities that other networking systems can't offer. I think >Apple's interface to name lookups is poor, but their implementation is sound. >I think the broadcast problem is overrated, though. With increasing processor >speeds, the amount of overhead in receiving a broadcast not meant for you is >becoming academic. And a little work on ethernet cards can make it so NO >processor time is needed to reject broadcasts. We can't stay static with the >times. Anyone who has a 10mbit ethernet for a backbone two years from now >isn't taking themselved seriously. Increasing processor speeds? Why should all the hosts on the LAN pay the price for the miscreant Ethertalk hosts broadcasting all over creation? Phase II will be interesting. I don't see it going far enough to solve the real problems here, and it is no more standardized than Phase I. We'll see how it goes. We'll have faster nets here too (we have gigabit Ultra nets already on the facility - hmmm, no Appletalk drivers for them though :-))... Being needlessly inefficient is always a bad idea. > >I agree with what you say. MacTCP is quite fast and is a better idea for >many Mac to Unix communications, anyway. What does that have to do with >UDPTalk? CAP is the only exception (like I said), but CAP does not involve >routing UDPTalk. My point was that we restrict Mac connections to Appletalk nets to localtalk speeds (since we don't allow Mac's to run Ethertalk on the LAN, only TCP/IP). The high speed applications are generally better served by IP protocols. >Maybe you should research your facts. Kinetics INVENTED UDPTalk. The original >FastPaths (1's) were invented to bridge LocalTalk to UDPTalk (EtherTalk didn't >exist yet). What Kinetics doesn't support is atalkad and UDPTalk backboning. >They don't support it at all, you ask them. I did. I was operating under >the assumption they did and that everyone must be discontent with Kinetics. >When I finally figured out that they only support it for communicating to CAP, >it made sense. FastPaths work very well in that situation. Ahem. IPtalk (as implemented by KIP) existed before Kinetics did. I recall early implementations using the famous Stanford "Butcher-block" gateway. When Kinetics started making gateways (based on the Stanford design), KIP of course ran on it. For awhile, it was the only thing that ran on that hardware. IPtalk actually predates Ethertalk! Atalkad is VERY useful because it allows us to centralize configuration and management. When you have 40+ K-boxes out there, having users trying to configure things is a disaster. Besides, they don't want the bother! Now if we could only get the silly things to boot via TFTP or the like, we wouldn't need access to Macs on the Localtalk segment at all! > >If you are happy with UDPTalk, then you shouldn't be talking to me about scale. >We were happy with UDPTalk when we were on a small scale, too. When you >reach the limits of atalkad or don't want to spend $2500 per LocalTalk, you'll >see it my way. > >Io hope people heed my warning. Many of you have probably read Dave >Falkenburg's article on KIP/CAP. He was very pro-atalkad in that >article. You should talk to him now (falken@caen.engin.umich.edu). If you >read that article and found many good reasons to use atalkad and UDPTalk then, >you should listen to me (or talk to Dave) and understand the reasons not to >use UDPTalk now. > >We thought we had a great stopgap solution. We kept believing it until we >had spent $100,000 on FastPaths. Then, within a few short weeks, we switched >180 degrees and realize we had spent about $40,000 too much. I finally have >a little peace of mind, too, knowing that our network will finally work right >again. If you are unhappy with AppleTalk, maybe it is for the same reasons I >was. There are more scale issues to worry about than numbers as well. How do you manage the network anyways? Especially if you have to have users on the net configure and load the K-boxes. The LBL KIP I use gives me stats on error rates the K-box is seeing on the Localtalk and Ethernet sides. That's not just gravy, we have found serious problems on localtalk nets thanks to that feature. How do you know how bad off you are if the Kbox won't tell you what it's seeing? We buy K-boxes anyways. We have about 40 now with no end in sight. People wire things with localtalk and ethernet now. As long as you have localtalk, you will have K-boxes, and as long as you have K-boxes, they ought to behave themselves. It's true the LBL KIP has a few more configuration features than the usual distribution. Some of these makes our life a lot easier in larger environments. But the bottom line is still the same. We have a LOT of network plumbing to talk to (more than most sites). All of it speaks IP. I don't want to have to deal with seperate solutions for all the silly protocols we have out there (3com, Appletalk, etc...). You can go nuts trying to build seperate solutions for each special interest group. You can't support 7 things well even with a huge staff. By using standardized solutions, we can provide excellent service to everyone who uses them, and that means the folks who can do their work in using that environment will be better off than those who don't. I'd like our Mac users to be on the right side. I'm sorry IPtalk didn't work out for you. It's working quite well for us. Thanks, Milo
amanda@intercon.uu.net (Amanda Walker) (09/05/89)
In article <1989Sep4.202733.6326@caen.engin.umich.edu>, billkatt@caen.engin.umich.edu (billkatt) writes: > Maybe you should research your facts. Kinetics INVENTED UDPTalk. The > original FastPaths (1's) were invented to bridge LocalTalk to UDPTalk > (EtherTalk didn't exist yet). Methinks the gentleman is a bit rusty on his history. Bill Croft at Stanford invented AppleTalk-over-UDP. Kinetics from the start has pushed their version, which started as "ELAP" and is now EtherTalk. It is only with the recent release of K-STAR that they are supporting UDP encapsulation. -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda -- "The trouble with doing something right the first time is that nobody appreciates how difficult it was" --Walt West
billkatt@caen.engin.umich.edu (billkatt) (09/06/89)
Newsgroups: comp.protocols.appletalk Subject: Re: UDPTalk as a backbone Summary: Expires: References: <1989Sep3.063402.22872@caen.engin.umich.edu> <31297@ames.arc.nasa.gov> <1989Sep4.202733.6326@caen.engin.umich.edu> <31353@ames.arc.nasa.gov> Sender: Reply-To: billkatt@caen.engin.umich.edu (billkatt) Followup-To: Distribution: Organization: Computer Aided Engineering Network (CAEN), University of Michigan Keywords: In article <31353@ames.arc.nasa.gov> medin@cincsac.arc.nasa.gov.UUCP (Milo S. Medin) writes: >In article <1989Sep4.202733.6326@caen.engin.umich.edu> billkatt@caen.engin.umich.edu (billkatt) writes: All right, I came off as a jerk, I realize that now. I'll try to be a little more constructive and open. I don't like the current situation, but I don't want to discourage the possibility of a future solution which WILL work. > >>I don't see how you can say that. Phase 2 fixes many of the routing traffic >>problems of phase 1. As for the broadcasts, I agree. However, I don't see >>... >>times. Anyone who has a 10mbit ethernet for a backbone two years from now >>isn't taking themselved seriously. > >Increasing processor speeds? Why should all the hosts on the LAN pay the >price for the miscreant Ethertalk hosts broadcasting all over creation? >Phase II will be interesting. I don't see it going far enough >to solve the real problems here, and it is no more standardized than >Phase I. We'll see how it goes. We'll have faster nets here too >(we have gigabit Ultra nets already on the facility - hmmm, no Appletalk drivers >for them though :-))... Being needlessly inefficient is always a bad idea. Gee, you should have told that to the people who wrote UNIX. It seems that UNIX and a lot of the software which runs under it is based on ineffeciency, all the way down to cc. It seems to be the current thing to give up effeciency for portability and flexibility. Lets not be hypocritical here. >> >>I agree with what you say. MacTCP is quite fast and is a better idea for >>many Mac to Unix communications, anyway. What does that have to do with >>UDPTalk? CAP is the only exception (like I said), but CAP does not involve >>routing UDPTalk. > >My point was that we restrict Mac connections to Appletalk nets to localtalk >speeds (since we don't allow Mac's to run Ethertalk on the LAN, only TCP/IP). >The high speed applications are generally better served by IP protocols. Hmmm... You're not the first person I have heard of who does that. Is there an overriding reason? I don't see one. Or do you use a different physical backbone for IP as AppleTalk? > >>Maybe you should research your facts. Kinetics INVENTED UDPTalk. The original >>FastPaths (1's) were invented to bridge LocalTalk to UDPTalk (EtherTalk didn't >>exist yet). What Kinetics doesn't support is atalkad and UDPTalk backboning. >>They don't support it at all, you ask them. I did. I was operating under >>the assumption they did and that everyone must be discontent with Kinetics. >>When I finally figured out that they only support it for communicating to CAP, >>it made sense. FastPaths work very well in that situation. > >Ahem. IPtalk (as implemented by KIP) existed before Kinetics did. I recall >early implementations using the famous Stanford "Butcher-block" gateway. >When Kinetics started making gateways (based on the Stanford design), KIP >of course ran on it. For awhile, it was the only thing that ran on >that hardware. IPtalk actually predates Ethertalk! Atalkad is VERY ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Isn't that what I said? >useful because it allows us to centralize configuration and management. >When you have 40+ K-boxes out there, having users trying to configure things >is a disaster. Besides, they don't want the bother! Now if we could only get >the silly things to boot via TFTP or the like, we wouldn't need access to >Macs on the Localtalk segment at all! You just restated what I said about Kinetics. The Kinetics FastPath sprang from that Graduate Project which was the "Butcher-block" gateway. Kinetics was an offshoot to capitalize (financially) on it. I like the TFTP idea, maybe someone should start from scratch with some new ideas like that. >> >>If you are happy with UDPTalk, then you shouldn't be talking to me about scale. >>We were happy with UDPTalk when we were on a small scale, too. When you >>reach the limits of atalkad or don't want to spend $2500 per LocalTalk, you'll >>see it my way. >> >>Io hope people heed my warning. Many of you have probably read Dave >>Falkenburg's article on KIP/CAP. He was very pro-atalkad in that >>article. You should talk to him now (falken@caen.engin.umich.edu). If you >>read that article and found many good reasons to use atalkad and UDPTalk then, >>you should listen to me (or talk to Dave) and understand the reasons not to >>use UDPTalk now. >> >>We thought we had a great stopgap solution. We kept believing it until we >>had spent $100,000 on FastPaths. Then, within a few short weeks, we switched >>180 degrees and realize we had spent about $40,000 too much. I finally have >>a little peace of mind, too, knowing that our network will finally work right >>again. If you are unhappy with AppleTalk, maybe it is for the same reasons I >>was. > >There are more scale issues to worry about than numbers as well. How do you >manage the network anyways? Especially if you have to have users on the >net configure and load the K-boxes. The LBL KIP I use gives me stats on >error rates the K-box is seeing on the Localtalk and Ethernet sides. That's >not just gravy, we have found serious problems on localtalk nets thanks to that >feature. How do you know how bad off you are if the Kbox won't tell you >what it's seeing? We currently run atalkad. It is holding us back, but the Proteon software isn't available for about two months. We won't have users on the net configuring the K-boxes. It will be necessary to physically go to a box to reconfigure it, but we feel that is better than having Joe User set up his own box. Thankfully, K-boxes require little maintainance once they are set up (unless you are running atalkad, whih wreaks havoc on them) so we will only have a problem when we update the software on the FastPaths. Stats don't mean much to us. We don't really consider LocalTalk a viable networking scheme. We recommend EtherTalk as the lowest speed that is viable. > >We buy K-boxes anyways. We have about 40 now with no end in sight. People >wire things with localtalk and ethernet now. As long as you have localtalk, >you will have K-boxes, and as long as you have K-boxes, they ought to behave >themselves. It's true the LBL KIP has a few more configuration features >than the usual distribution. Some of these makes our life a lot easier in >larger environments. But the bottom line is still the same. We have a LOT >of network plumbing to talk to (more than most sites). All of it speaks IP. >I don't want to have to deal with seperate solutions for all the silly protocols >we have out there (3com, Appletalk, etc...). You can go nuts trying to >build seperate solutions for each special interest group. You can't support >7 things well even with a huge staff. By using standardized solutions, we >can provide excellent service to everyone who uses them, and that means the >folks who can do their work in using that environment will be better off than >those who don't. I'd like our Mac users to be on the right side. Apple's Internet Router is a fantastic way to join LocalTalks to a backbone. You can join two LocalTalks and a combination of 6 EtherTalks and TokenTalks with one machine which can also function as an AppleShare server. So LocalTalks and FastPaths don't go hand-in-hand anymore. 40 FastPaths and no end in sight? I can see and end. You will have to split your network into multiple networks or stop expanding when you reach 64 networks. I am kind of worried about having to run around to re-configure our FastPaths but we simply have no choice. We can't use atalkad anymore. We have a FULL table. > >I'm sorry IPtalk didn't work out for you. It's working quite well for us. Good Luck in the future with it, you'll need it. Keep me posted with what you do when you reach the 64 route limit of atalkad. -Steve
billkatt@caen.engin.umich.edu (billkatt) (09/06/89)
In article <1435@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: >In article <1989Sep4.202733.6326@caen.engin.umich.edu>, >billkatt@caen.engin.umich.edu (billkatt) writes: >> Maybe you should research your facts. Kinetics INVENTED UDPTalk. The >> original FastPaths (1's) were invented to bridge LocalTalk to UDPTalk >> (EtherTalk didn't exist yet). > >Methinks the gentleman is a bit rusty on his history. Bill Croft at Stanford >invented AppleTalk-over-UDP. Kinetics from the start has pushed their >version, which started as "ELAP" and is now EtherTalk. It is only with >the recent release of K-STAR that they are supporting UDP encapsulation. Yes, K*Star is newer than KIP. Maybe I mistated what I mean, but the FastPath was simply a hardware device to run KIP. Sure, Kinetics supplied different software (EtherTalk), but that's not what people ran. If you only consider what Kinetics sends and supports as being the use for their hardware, then you can't include atalkad as software which is made for it. atalkad is part of KIP, which Kinetics doesn't supply or support, but that's what people run. -Steve > >-- >Amanda Walker >InterCon Systems Corporation > >amanda@intercon.uu.net | ...!uunet!intercon!amanda >-- >"The trouble with doing something right the first time is that nobody > appreciates how difficult it was" --Walt West
billkatt@ucbvax.berkeley.edu (billkatt) (09/06/89)
In article <31353@ames.arc.nasa.gov> medin@cincsac.arc.nasa.gov.UUCP (Milo S. Medin) writes: >In article <1989Sep4.202733.6326@caen.engin.umich.edu> billkatt@caen.engin.umich.edu (billkatt) writes: All right, I came off as a jerk, I realize that now. I'll try to be a little more constructive and open. I don't like the current situation, but I don't want to discourage the possibility of a future solution which WILL work. > >>I don't see how you can say that. Phase 2 fixes many of the routing traffic >>problems of phase 1. As for the broadcasts, I agree. However, I don't see >>... >>times. Anyone who has a 10mbit ethernet for a backbone two years from now >>isn't taking themselved seriously. > >Increasing processor speeds? Why should all the hosts on the LAN pay the >price for the miscreant Ethertalk hosts broadcasting all over creation? >Phase II will be interesting. I don't see it going far enough >to solve the real problems here, and it is no more standardized than >Phase I. We'll see how it goes. We'll have faster nets here too >(we have gigabit Ultra nets already on the facility - hmmm, no Appletalk drivers >for them though :-))... Being needlessly inefficient is always a bad idea. Gee, you should have told that to the people who wrote UNIX. It seems that UNIX and a lot of the software which runs under it is based on ineffeciency, all the way down to cc. It seems to be the current thing to give up effeciency for portability and flexibility. Lets not be hypocritical here. >> >>I agree with what you say. MacTCP is quite fast and is a better idea for >>many Mac to Unix communications, anyway. What does that have to do with >>UDPTalk? CAP is the only exception (like I said), but CAP does not involve >>routing UDPTalk. > >My point was that we restrict Mac connections to Appletalk nets to localtalk >speeds (since we don't allow Mac's to run Ethertalk on the LAN, only TCP/IP). >The high speed applications are generally better served by IP protocols. Hmmm... You're not the first person I have heard of who does that. Is there an overriding reason? I don't see one. Or do you use a different physical backbone for IP as AppleTalk? > >>Maybe you should research your facts. Kinetics INVENTED UDPTalk. The original >>FastPaths (1's) were invented to bridge LocalTalk to UDPTalk (EtherTalk didn't >>exist yet). What Kinetics doesn't support is atalkad and UDPTalk backboning. >>They don't support it at all, you ask them. I did. I was operating under >>the assumption they did and that everyone must be discontent with Kinetics. >>When I finally figured out that they only support it for communicating to CAP, >>it made sense. FastPaths work very well in that situation. > >Ahem. IPtalk (as implemented by KIP) existed before Kinetics did. I recall >early implementations using the famous Stanford "Butcher-block" gateway. >When Kinetics started making gateways (based on the Stanford design), KIP >of course ran on it. For awhile, it was the only thing that ran on >that hardware. IPtalk actually predates Ethertalk! Atalkad is VERY ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Isn't that what I said? >useful because it allows us to centralize configuration and management. >When you have 40+ K-boxes out there, having users trying to configure things >is a disaster. Besides, they don't want the bother! Now if we could only get >the silly things to boot via TFTP or the like, we wouldn't need access to >Macs on the Localtalk segment at all! You just restated what I said about Kinetics. The Kinetics FastPath sprang from that Graduate Project which was the "Butcher-block" gateway. Kinetics was an offshoot to capitalize (financially) on it. I like the TFTP idea, maybe someone should start from scratch with some new ideas like that. >> >>If you are happy with UDPTalk, then you shouldn't be talking to me about scale. >>We were happy with UDPTalk when we were on a small scale, too. When you >>reach the limits of atalkad or don't want to spend $2500 per LocalTalk, you'll >>see it my way. >> >>Io hope people heed my warning. Many of you have probably read Dave >>Falkenburg's article on KIP/CAP. He was very pro-atalkad in that >>article. You should talk to him now (falken@caen.engin.umich.edu). If you >>read that article and found many good reasons to use atalkad and UDPTalk then, >>you should listen to me (or talk to Dave) and understand the reasons not to >>use UDPTalk now. >> >>We thought we had a great stopgap solution. We kept believing it until we >>had spent $100,000 on FastPaths. Then, within a few short weeks, we switched >>180 degrees and realize we had spent about $40,000 too much. I finally have >>a little peace of mind, too, knowing that our network will finally work right >>again. If you are unhappy with AppleTalk, maybe it is for the same reasons I >>was. > >There are more scale issues to worry about than numbers as well. How do you >manage the network anyways? Especially if you have to have users on the >net configure and load the K-boxes. The LBL KIP I use gives me stats on >error rates the K-box is seeing on the Localtalk and Ethernet sides. That's >not just gravy, we have found serious problems on localtalk nets thanks to that >feature. How do you know how bad off you are if the Kbox won't tell you >what it's seeing? We currently run atalkad. It is holding us back, but the Proteon software isn't available for about two months. We won't have users on the net configuring the K-boxes. It will be necessary to physically go to a box to reconfigure it, but we feel that is better than having Joe User set up his own box. Thankfully, K-boxes require little maintainance once they are set up (unless you are running atalkad, whih wreaks havoc on them) so we will only have a problem when we update the software on the FastPaths. Stats don't mean much to us. We don't really consider LocalTalk a viable networking scheme. We recommend EtherTalk as the lowest speed that is viable. > >We buy K-boxes anyways. We have about 40 now with no end in sight. People >wire things with localtalk and ethernet now. As long as you have localtalk, >you will have K-boxes, and as long as you have K-boxes, they ought to behave >themselves. It's true the LBL KIP has a few more configuration features >than the usual distribution. Some of these makes our life a lot easier in >larger environments. But the bottom line is still the same. We have a LOT >of network plumbing to talk to (more than most sites). All of it speaks IP. >I don't want to have to deal with seperate solutions for all the silly protocols >we have out there (3com, Appletalk, etc...). You can go nuts trying to >build seperate solutions for each special interest group. You can't support >7 things well even with a huge staff. By using standardized solutions, we >can provide excellent service to everyone who uses them, and that means the >folks who can do their work in using that environment will be better off than >those who don't. I'd like our Mac users to be on the right side. Apple's Internet Router is a fantastic way to join LocalTalks to a backbone. You can join two LocalTalks and a combination of 6 EtherTalks and TokenTalks with one machine which can also function as an AppleShare server. So LocalTalks and FastPaths don't go hand-in-hand anymore. 40 FastPaths and no end in sight? I can see and end. You will have to split your network into multiple networks or stop expanding when you reach 64 networks. I am kind of worried about having to run around to re-configure our FastPaths but we simply have no choice. We can't use atalkad anymore. We have a FULL table. > >I'm sorry IPtalk didn't work out for you. It's working quite well for us. Good Luck in the future with it, you'll need it. Keep me posted with what you do when you reach the 64 route limit of atalkad. -Steve
amanda@intercon.uu.net (Amanda Walker) (09/06/89)
In article <1989Sep5.193002.15583@caen.engin.umich.edu>, billkatt@caen.engin.umich.edu (billkatt) writes: > Yes, K*Star is newer than KIP. Maybe I mistated what I mean, but the FastPath > was simply a hardware device to run KIP. Sure, Kinetics supplied different > software (EtherTalk), but that's not what people ran. If you only consider > what Kinetics sends and supports as being the use for their hardware, then > you can't include atalkad as software which is made for it. atalkad is part > of KIP, which Kinetics doesn't supply or support, but that's what people run. > -Steve That's a fairer description, but I still think it's inaccurate. A FastPath is *not* a Seagate box. It is almost functionally identical, and lots of people who got into AppleTalk over Ethernet (notably universities) used them as a hardware device that they could run KIP on (and that had the advantage of coming preassembled :-)). However, there are also many, many people who ran the ELAP gateway from Kinetics (and later, the "combined gateway" and now K-Star). Thinking of "the purpose of a FastPath" as "what I and my friends use FastPaths for" is just as limiting as only considering Kinetics' software. -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda -- "Nihil est ab omni parte beatum" --Horace tr.: "Nothing is an unmixed blessing"
medin@cincsac.arc.nasa.gov (Milo S. Medin) (09/06/89)
In article <1989Sep5.192546.15473@caen.engin.umich.edu>, billkatt@caen.engin.umich.edu (billkatt) writes: > > >My point was that we restrict Mac connections to Appletalk nets to localtalk > >speeds (since we don't allow Mac's to run Ethertalk on the LAN, only TCP/IP). > >The high speed applications are generally better served by IP protocols. > > Hmmm... You're not the first person I have heard of who does that. Is there > an overriding reason? I don't see one. Or do you use a different physical > backbone for IP as AppleTalk? Our buildings typically come pre-wired for RS232, Localtalk (PhoneNet), and ethernet. Relatively few Mac's have ethernet controllers in them, so they need localtalk and Kinetics boxes anyways. Mac's can certainly buy ethernet controllers and run TCP/IP over them, but we do not allow them to use Ethertalk. That's the overriding reason. We ban Ethertalk from our basewide network. > >Ahem. IPtalk (as implemented by KIP) existed before Kinetics did. I recall > >early implementations using the famous Stanford "Butcher-block" gateway. > >When Kinetics started making gateways (based on the Stanford design), KIP > >of course ran on it. For awhile, it was the only thing that ran on > >that hardware. IPtalk actually predates Ethertalk! Atalkad is VERY > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Isn't that what I said? > You said Kinetics invented UDPtalk. That's simply not true. Bill Croft and the SUMEX folks did, and before Ethertalk was in existance. I will take this oppurtunity and apologize for having my facts screwed up however. The Butcher block gateway was a CMU effort. The Stanford/SUMEX effort was the SEAGATE gateway, which turned into the FastPath line. KIP always ran on the FastPaths... > We currently run atalkad. It is holding us back, but the Proteon software > isn't available for about two months. We won't have users on the net > configuring the K-boxes. It will be necessary to physically go to a box to > reconfigure it, but we feel that is better than having Joe User set up his > own box. Thankfully, K-boxes require little maintainance once they are set > up (unless you are running atalkad, whih wreaks havoc on them) so we will > only have a problem when we update the software on the FastPaths. > > Stats don't mean much to us. We don't really consider LocalTalk a viable > networking scheme. We recommend EtherTalk as the lowest speed that is > viable. Well, I can undersatnd why people like Proteon want to support Appletalk. I wish they'd work on more productive things is all. As for Atalkad, it works fine with the LBL KIP. Those boxes stay up for weeks at a time. Maybe it drives K*Star crazy, but we have never gotten a piece of Kinetics software to do what we want, and the LBL KIP does, so that's what we run. It works very well. Localtalk has to be dealt with. It comes on all the little monsters. Stats mean a lot when you find out that your Phonenet is dropping 5% of it's packets because of CRC errors! Then you can call out your ops people to actually fix the problem! As I said before, the high bandwidth applications typically use TCP/IP here, and that runs over ethernet. We have localtalk anyway, so this combonation solves a big problem (Ethertalk) with low marginal cost. > Apple's Internet Router is a fantastic way to join LocalTalks to a backbone. > You can join two LocalTalks and a combination of 6 EtherTalks and TokenTalks > with one machine which can also function as an AppleShare server. So > LocalTalks and FastPaths don't go hand-in-hand anymore. 40 FastPaths and > no end in sight? I can see and end. You will have to split your network into > multiple networks or stop expanding when you reach 64 networks. > I am kind of worried about having to run around to re-configure our FastPaths > but we simply have no choice. We can't use atalkad anymore. We have a > FULL table. I'm sorry, Apple's Internet router is rubbish. How do you do net management and control? SNMP? CMIP? Nothing is not an acceptable answer! It doesn't perform IP gateway functions, so our NCSA Telnet users can't talk to the rest of the systems on base though it. We have major mail applications on base (MacPOP) that our management people use to read mail that requires CAP interoperation. How does the Apple IR do that? I'm sure it does a fine job of doing LocalTalk to Ethertalk. That however, is a solution to a problem I don't have. And again, you have to figure net management into the equation. Things occaisionally do go wrong... :-) Run out at 64 nets? That's just a constant in the KIP code. Source is great. Maybe KStar can't deal with it, but we don't run KStar... If you are looking for the mod, change NANETS to 96 or 128 or whatever. Make sure the KIP code you use also can deal with it. As I said, source code is great. It's in the UNIX tradition of course, not the Mac tradition... Thanks, Milo
leres@ace.ee.lbl.gov (Craig Leres) (09/06/89)
Milo S. Medin writes: > Now if we could only get > the silly things to boot via TFTP or the like, we wouldn't need access to > Macs on the Localtalk segment at all! Actually, my vote goes for bootp; but anything is better than having to visit the localtalk segment (well, anything but ethertalk). > The LBL KIP I use gives me stats on > error rates the K-box is seeing on the Localtalk and Ethernet sides. That's > not just gravy, we have found serious problems on localtalk nets thanks to that > feature. How do you know how bad off you are if the Kbox won't tell you > what it's seeing? Yeah, it's hard to imagine living without the same per interface statistics a typical BSD Unix system (or turnkey router) gives you. And I've actually had k-boxes point out serious ethernet problems. Craig
liam@cs.qmc.ac.uk (William Roberts) (09/06/89)
Westfield College, University of London, UK. Keywords: Webster Multigate In article <3745@helios.ee.lbl.gov> leres@helios.ee.lbl.gov (Craig Leres) writes: >Milo S. Medin writes: >> Now if we could only get >> the silly things to boot via TFTP or the like, we wouldn't need access to >> Macs on the Localtalk segment at all! > >Actually, my vote goes for bootp; but anything is better than having to >visit the localtalk segment (well, anything but ethertalk). > It's worth pointing out that the Webster Multigate does all of the things a good AppleTalk-Ethernet gateway should (including the proxy ARP for IP->DDP encapsulation that is the bulk of the gibberish in atalkatab files), AND has the options to boot its gateway code using BOOTP or TFTP. I liked it - nice big box, 4 LocalTalk + 1 Ethernet, Hypercard Stack to help you set it up, including generating an atalkatabb file. We tried one out as a possible replacement for our aging KFP-2 gateway; it was lots nicer than a KFP-4 (which is just as badly documented as the old box). A Gatorbbox has just arrived on test, but it will have to be good.... William Roberts (Any missing letter 'b's are entirely due to this terminal!) -- William Roberts ARPA: liam@cs.qmc.ac.uk Queen Mary College UUCP: liam@qmc-cs.UUCP AppleLink: UK0087 190 Mile End Road Tel: 01-975 5250 LONDON, E1 4NS, UK Fax: 01-980 6533
billkatt@caen.engin.umich.edu (billkatt) (09/06/89)
In article <31397@ames.arc.nasa.gov> medin@cincsac.arc.nasa.gov (Milo S. Medin) writes: > >In article <1989Sep5.192546.15473@caen.engin.umich.edu>, billkatt@caen.engin.umich.edu (billkatt) writes: >> >> Apple's Internet Router is a fantastic way to join LocalTalks to a backbone. >> You can join two LocalTalks and a combination of 6 EtherTalks and TokenTalks >> with one machine which can also function as an AppleShare server. So >> LocalTalks and FastPaths don't go hand-in-hand anymore. 40 FastPaths and >> no end in sight? I can see and end. You will have to split your network into >> multiple networks or stop expanding when you reach 64 networks. >> I am kind of worried about having to run around to re-configure our FastPaths >> but we simply have no choice. We can't use atalkad anymore. We have a >> FULL table. > >I'm sorry, Apple's Internet router is rubbish. How do you do net >management and control? SNMP? CMIP? Nothing is not an acceptable >answer! It doesn't perform IP gateway functions, so our NCSA Telnet >users can't talk to the rest of the systems on base though it. We have >major mail applications on base (MacPOP) that our management people >use to read mail that requires CAP interoperation. How does the Apple >IR do that? I'm sure it does a fine job of doing LocalTalk to Ethertalk. >That however, is a solution to a problem I don't have. And again, you >have to figure net management into the equation. Things occaisionally >do go wrong... :-) SNMP, CMIP? Those don't apply to the Internet Router, it doesn't do IP. (I know that isn't what you want to hear) Just for the record, you don't have to have as many FastPaths as LocalTalks. You can direct NCSA Telnet to use a FastPath in a different zone as a gateway to IP, and as long as you have one FastPath in each zone, you don't even have to do that. It will be used automatically from all networks in that zone. > >Run out at 64 nets? That's just a constant in the KIP code. Source >is great. Maybe KStar can't deal with it, but we don't run KStar... > >If you are looking for the mod, change NANETS to 96 or 128 or >whatever. Make sure the KIP code you use also can deal with it. >As I said, source code is great. It's in the UNIX tradition >of course, not the Mac tradition... I've tried it, have you? Look a little closer. The packets which FastPaths use to supply original routes aren't RTMP packets. It happens that with 64 routes, the packet used to supply routes to FastPaths is full. You will have to send additional packets to the routers, except reception of a packet causes the FastPath to clear out its current routes and replace them. Information the the source code would imply that there is a slightly different kind of packet you can send to supply additional routes, but atalkad never sends it and doesn't mention the format. So although 64 is a constant in the code, it isn't an ARBITRARY constant, and making it larger gains you nothing. Looking through the KIP source code seems to imply that KIP supports it, but I don't think its been tested too well. -Steve
billkatt@caen.engin.umich.edu (billkatt) (09/07/89)
In article <3745@helios.ee.lbl.gov> leres@helios.ee.lbl.gov (Craig Leres) writes: >Milo S. Medin writes: >> Now if we could only get >> the silly things to boot via TFTP or the like, we wouldn't need access to >> Macs on the Localtalk segment at all! > >Actually, my vote goes for bootp; but anything is better than having to >visit the localtalk segment (well, anything but ethertalk). bootp can't boot the boxes, only support information on where to boot from. Usually, a host uses BOOTP to find out where to boot from and what to boot, and then uses TFTP to boot. -Steve
billkatt@caen.engin.umich.edu (billkatt) (09/07/89)
In article <4727*kenw@noah.arc.cdn> kenw@noah.arc.CDN (Ken Wallewein) writes: > > I've been watching this discussion on IPTALK/UDPTALK with considerable >interest. We are a relatively small site, with a half-dozen K-box 4s and >maybe a couple of dozen TCP/IP nodes. We have the K-boxen set up to run >EtherTalk and IP/UDPTALK, and have interesting times getting uShare and >NCSA Telnet and PacerLink to coexist peacefully. We do not run CAP at all. > > So. Having established our interest in the matter, could somebody please >try to summarize what this argument has been about? There's been a lot of >assumption of context. As far as I can see, there's: > >Six good questions to answer... Answered below. > One of you went to all-IPTalk/UDPTalk, and one went to all-EtherTalk. It's >still not clear to me what constraints and capabilities prompted either >decision. For the sake of the less experienced among us: summarize, please. > > >/kenw Good idea. I'll try to summarize what we're arguing about and why I take my side. BTW, I went all EtherTalk. We have differences about which protocol to use as a backbone. There is EtherTalk, which is a close relative to LocalTalk with its use of broadcasts and the like. Another possibility is UDPTalk (or IPTalk, different names, same thing) which does things in a generally more IP-ish way. a) EtherTalk routers broadcast too often. Actually, all AppleTalk routers broadcast a lot. FastPaths even broadcast RTMP packets onto their Ethernet in UDPTalk. I agree with the statement that no one has proven this a problem. I would also like to note that I think there are a lot more NBP lookup broadcasts than RTMP broadcasts on any AppleTalk network. b) UDPTalk give better stats, agreed, but I don't agree that it scales better. I will say that it definitely doesn't scale worse. Scaling does matter in large installations, especially if ethernet is used as a backbone instead of something faster. We really don't need the stats, since our IP router can provide the info. We usually hear of flakey networks immediately, anyway. c) UDPtalk is quite flakier, especially around here. I'm not sure why. Theoretically, it should work as well as EtherTalk. I have no one to blame, since we are using atalkad with K*STAR, which Kinetics doesn't support. Most of our boxes stay up for months, but some don't. d) UDPTalk is a lot more expensive. I used to think it was such a big deal, since large installation have large budgets. Now I'm not so sure. The lower costs of EtherTalk can make it available to more Departments within the University here (see below for more info). It doesn't have commerical support, although Kinetics finally mentions atalkad in their manual for the first time in a recent revision. They still don't support it, though. e) Who cares who made the first box? Not me. They've progressed a lot since then, anyway. f) Routing, bridging, etc. This is a big subject. First, you can't mix and match. You can use EtherTalk/LocalTalk together freely unless you use UDPTalk as a routing medium (i.e. atalkad) You can run EtherTalk/LocalTalk and UDPTalk (with atalkad) together, but only in parallel. All networks and routes must be supplied by the administrative host (atalkad) if you have IP subnetting. Additional routes will not propagate, since RTMP (which is updated with new routes) broadcasts from boxes with additional (non-supplied) routes will not be received from across IP gateways. Because of this, every router must be a FastPath or GatorBox. In addition, atalkad has an inherent limitation of 64 total routes (networks). This becomes a big factor in large installations. There is a debate over wether atalkad could be modified to support more routes. I've looked into it, and it looks difficult, but could be possible. I'll let the fact that no one has done it speak for itself. I'll agree that some FastPaths are necessary, to allow LocalTalk machines to run NCSA Telnet (IP in AppleTalk to IP translation), but argue that using FastPaths exclusively is something to be avoided because of cost. As a side note, I figure Apple's internet router will support this translation soon. I'll try to outline the experience here with UDPTalk. We started out on UDPTalk because it was the only way to connect our LocalTalk networks together via our existing networks (and with any kind of speed). Now that we are using EtherTalk as our primary network medium for Macs (instead of LocaTalk), we are unhappy with the slow speed and restrictions. We currently have 61 networks (routes) on one of our two AppleTalk internets here at U of M. We are blocked from going any further because of atalkad, and would like to be able to use more cost-effective routers on our network. This had lead us to change our backbone to EtherTalk from UDPTalk. We still use UDPTalk for CAP, but it is no longer viable for us as a backbone. I would like to point out that we still use UDPTalk as our backbone for approximately two more months, until the software enabling us to run AppleTalk on our Proteon backbone becomes available. -Steve
meggers@orion.cf.uci.edu (mark eggers) (09/07/89)
In article <1989Sep6.165747.23972@caen.engin.umich.edu>, billkatt@caen.engin.umich.edu (billkatt) writes: > > SNMP, CMIP? Those don't apply to the Internet Router, it doesn't do IP. > (I know that isn't what you want to hear) Just for the record, you don't > have to have as many FastPaths as LocalTalks. You can direct NCSA Telnet > to use a FastPath in a different zone as a gateway to IP, and as long as you > have one FastPath in each zone, you don't even have to do that. It will be > used automatically from all networks in that zone. > > -Steve Management of network entities such as routers, servers, bridges, and gateways is a necessary part of running a well-maintained network. This includes timely resolution of net problems, planning for expansion (nice to have stats that back up usage to present to people who control the budget ;-) ), and of course finding problems before they affect your users. Any device that is an integral part of the network that doesn't support CMIP, CMOT, or SNMP increases the work load in network support. This means that I have less time to write software or provide services. There is actually a lot about SNMP that is not IP specific. While the ip, icmp, tcp, udp, and egp mibs are IP specific, the system, interfaces, and parts of the at mib are not IP specific. Then, there is always the enterprise subtree (1.3.6.1.4.1) where Apple could put in Apple-specific variables. It would be nice if I could monitor the health of the entire network from one workstation, upgrade areas before congestion impacts performance, and diagnose / fix problems before they seriously impact users. I have this same complaint about Novell, Banyan, 3Com, and the current crop of twisted pair Ethernet products as well. -- just my two cents -- /mde/
medin@cincsac.arc.nasa.gov (Milo S. Medin) (09/07/89)
> FastPaths use to supply original routes aren't RTMP packets. It happens > that with 64 routes, the packet used to supply routes to FastPaths is full. > You will have to send additional packets to the routers, except reception > of a packet causes the FastPath to clear out its current routes and replace > them. Information the the source code would imply that there is a slightly > different kind of packet you can send to supply additional routes, but > atalkad never sends it and doesn't mention the format. So although 64 is a > constant in the code, it isn't an ARBITRARY constant, and making it larger > gains you nothing. Well, I think I said that you had to have a KIP capable of dealing with more entries. If you support frag/reassembly, you don't need to change anything else. You get bigger packets. Granted, this method doesn't last forever, and the right thing to do is add incremental updates (you are aging routes anyway), but frag is needed anyways inside the things. We don't have problems hacking code inside the box, though I can understand why most sites wouldn't want to do it. Then again, most large sites would have the support staff necessary to do it. > > Looking through the KIP source code seems to imply that KIP supports it, but > I don't think its been tested too well. You are right, we haven't hacked in frag reassembly yet, though that's a fairly straightforward thing to do. You could fix it by adding incremental updates, but that's trickier (in my opinion) than hacking in reassembly. I'd be happier if we never had to support that much Appletalk, but that's how it goes... Thanks, Milo
rapatel@qbranch.rutgers.edu (Rocky) (09/07/89)
>All networks and routes must be supplied by the >administrative host (atalkad) if you have IP subnetting. Additional routes >will not propagate, since RTMP (which is updated with new routes) broadcasts >from boxes with additional (non-supplied) routes will not be received from >across IP gateways. Just one note, we use Hayes Interbridges (as both local bridges and remote bridges) with our KIP based Kboxes and I do not configure their routes/zones in atalkatab. The routes are updated within a few minutes (1 or 2) to all our kboxes. This includes the zone entry for a remote bridge. This zone entry normally only shows up when the modems are working. This implies that the kboxes use at least some routing update mechanism - RTMP or otherwise. By the way, I am forced NOT to make entries for the interbridges. This is because our interbridges decide to ignore the kboxes if the kboxes already advertise the route. Because of this and some other problem with the interbridges, sometimes an interbridge resets some how and ignores the kbox (since the kbox already thinks it knows how to route for the network the interbridge is bridging to, the interbridge believes the kbox is sending bogus routing info). The way to get around it is to shut down the interbridges on the localtalk and power cycle the kbox. The kbox just comes up with the pre-configured routes and the interbridges then believe its info. We also had PacerLink/PacerShare show up properly (Pacer runs a virtual bridge to run PacerShare<->ethertalk) using the ethertalk support from KIP. The Ethertalk support from KIP is buggy however, so the dept. is running the Kinetics ethertalk gateway code instead (until they can replace the KFPS-2 with a KFPS-4 running K*). So every entry does NOT need to be added into atalkatab - at least not for bridges. Rakesh Patel.
djh@cs.mu.oz.au (David Hornsby) (09/07/89)
In article <gZ1QTHG00UodQ9H0tL@andrew.cmu.edu> ("Steven L. Waldbusser") writes: > >> Excerpts from internet.info-appletalk: 6-Sep-89 Re: UDPTalk as a >> backbone billkatt@ucsd.edu (3104) > >> I've tried it, have you? Look a little closer. The packets which >> FastPaths use to supply original routes aren't RTMP packets. It happens >> that with 64 routes, the packet used to supply routes to FastPaths is >> full. > > At CMU we have achieved 100 routes from one atalkad host (we currently >use 93). There are two mechanisms behind this. There is another method, currently in use around here and working well. There is an otherwise unused (and zeroed by default) flags field (1 byte) in these AA packets. A simple protocol allows a gateway to obtain (theoretically) 256 routing packets or 256 * 64 = 16384 route tuples The protocol is trivial but requires modifications to both atalkad and the gateway code. I list it here with the packet types we use for your interest. Initially atalkad receives an aaROUTEI (2) request. If the number of routes is bigger than one packet, atalkad returns the first packet with the flags field set to the number of packets that are required to transmit the data. The gateway then continues by sending aaROUTER (33) requests with the flags field being set to the desired packet. atalkad returns a type aaROUTEM (32) packet with the desired data and the flag set to the packet number. This continues until all the data is transferred. There is a similar mechanism for aaPROXY packets. >This is no substitute for a cleanly engineered solution which is >needed in the long term. I feel that such a solution should come from >your favorite gateway vendor. It also needs the cooperation of all the other gateway vendors :-) Cheers, David Hornsby ...!uunet!munnari!djh Professional Officer djh@munnari.OZ.AU Department of Computer Science "The home of Multigate" +61 3 344 4044 The University of Melbourne, Parkville, 3052, Victoria, Australia.
djh@cs.mu.oz.au (David Hornsby) (09/07/89)
In article <1210@sequent.cs.qmc.ac.uk> (William Roberts) writes: >It's worth pointing out that the Webster Multigate does all of >the things a good AppleTalk-Ethernet gateway should (including >the proxy ARP for IP->DDP encapsulation that is the bulk of the >gibberish in atalkatab files), AND has the options to boot its >gateway code using BOOTP or TFTP. Thanks for the bouquet. I would like to make a minor correction and a couple of additions. Multigate uses FTP rather than TFTP to boot. It can also boot from Macs on EtherTalk or LocalTalk. It also now supports RIP. Regards, David Hornsby ...!uunet!munnari!djh Professional Officer djh@munnari.OZ.AU Department of Computer Science "The home of Multigate" +61 3 344 4044 The University of Melbourne, Parkville, 3052, Victoria, Australia.