Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!JESSICA.STANFORD.EDU!morgan From: morgan@JESSICA.STANFORD.EDU Newsgroups: comp.protocols.appletalk Subject: Re: KIP Message-ID: Date: 4 Jan 89 18:15:20 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 94 I wrote: > K-Star is able to be statically configured, and is better [than KIP] > in other ways as well (though worse in some others . . .). By way of clarification (by popular demand), here are some True Facts As I Understand Them (errors are certainly due to Post-Holiday Depression): 1) KIP (any version, 0688 is the latest) runs only on KFPS-[123] models; it does not run on KFPS-4s or "upgraded" [123]s. Kinetics' K-Star, which is 99% equivalent to KIP in functionality, runs only on KFPS-4s and upgraded [123]s (known perhaps as KFPS-2U, -3U, etc). The "old" FastPath Manager program must be used to load and configure KIP; the FastPath Manager II program must be used to load and configure K-Star. 2) Things KIP and K-Star do the same: * support Mac/IP and NCSA Telnet, including static or dynamic IP address assignment in the "address-spoofing" (rather than separate-subnet) style; * support AppleTalk bridge (ie, router) functions between LocalTalk, AppleTalk-in-UDP (known to some as IPTalk, which may TM of somebody), and EtherTalk; * are able to download configuration info from an "atalkad" server running on a Unix host. 3) Things KIP and K-Star do differently: * KIP has fixed table sizes for many managed variables, including AppleTalk routes, zone names, etc. Large nets may bump into these limits, and suffer. K-Star uses some sort of dynamic scheme that may make it less likely to run out of room for these things, but how do you know? * KIP supports a kludgey but useful protection scheme for keeping Laserwriters or other servers from being visible between zones. K-Star does not. * KIP supports optional use of the newly-defined "official" UDP port assignments for AppleTalk functions (as does CAP). K-Star supports only the traditional port assignments. * K-Star, in addition to being an order of magnitude easier to configure since you don't have to edit hex fields in text files, is able to be configured for use entirely from FastPath Manager II, unlike KIP which must get configuration info from an atalkad server. 3) Why a KFPS-4 is better than a KFPS-[123]: * Much better performance. We observed that on busy Ethernets file service across two KFPS-[123]s was impossible. With KFPS-4s it's fine. Similarly a KFPS-[123] is marginal when translating EtherTalk-to-IPTalk (for a MacII to use Aufs, typically), but the -4 does fine. * More memory. In addition to meaning fewer dropped packets, presumably, it also means not running into table size limits like those in KIP that have forced us to partition our campus AppleTalk nets. * It can be loaded from the Ethernet side. Also, it remembers its Ethernet address. * I can't think of any reasons why a KFPS-[123] is better, except possibly that it can run KIP for those who need it. It's not clear how many of the KFPS-4 benefits are achieved by the upgraded KFPS-[23]U, however. 4) The KFPS-4 has had a number of PROM revisions. The first version we got, in August/September 88, was almost unusable in our environment because of a bug that prevented more than one box from being in a zone. I think this version was labelled "C0X5" on the chip but called itself "3.1" when viewed from the FastPath Manager. A second version, called (I think) "C0X7" on the chip and "4.0" in the FPM, solved that bug, but seemed to crash a lot. The current version (as far as I know) calls itself "4.1" in the FPM and I'm not sure what on the chip, and seems much improved all around. Each of these came, of course, with a new version of the Manager and of K-Star (currently 4.1 and 5.03, respectively). My impression is that most of the problems people report to the list sound like the ones caused by these earlier versions. Kinetics' handling of these multiple versions has been less than stellar (though it appears to have improved recently), and it sounds like others have had a worse time of it than we have. Disclaimer: Kinetics and Stanford have some sort of relationship. Call our lawyers if you're interested, then explain it to me if you understand it. - RL "Bob" Morgan Networking Systems Stanford University