aks@hydra.ucsb.edu ( ) (09/20/88)
I would like to understand why (apparently both) KIP and K-Star do not support the ability to treat the Localtalk network as an IP subnet AND provide the directed, encapsulated IP feature? It seems that you can treat the Localtalk network as an IP subnet, while not having the capability of encapsulating Localtalk packets and directing them to another Kbox across a router, *or* you can treat the Localtalk network as an extension of the SAME subnet on which the Kbox resides (with either static or dynamic, serialized IP address assignment), while obtaining encapsulated Localtalk packets. Is this a correct assesment? Here's a grahic example of a small piece of our network: Enet 254 ------------------------ | | [gw] [gw] | | | --------- | | | [gw] ENet 24 | ENet 88 | -------- --------- | | [Kbox1] [Kbox2] | | ========== =========== | | | | | | Mac Mac LW Mac Mac LW As you can see, Kbox1 and KBox2 are seperated by several gateways and subnets; also, (it's not evident but) Enet 24 is very crowded -- we don't want the Mac's in ATNet 26 to be part of ENet 24 -- our host address are named, centrally administrated and statically allocated. Similarly, the Macs in ATNet 90 do not really need to be in ENet 88. Yet, if we want to make the two Zones "see" each other, we must run the KIP or KStart software which doesn't allow the two modes to mix. Or am I wrong (I hope, I hope)? You see, if you are trying to fit one or more potentially large Localtalk networks into some fairly well-occupied subnets, it is very difficult to find blocks of sequential addresses to assign to each Localtalk network. Moreover, once you accomplish this, it becomes very difficult to then later expand the Localtalk networks with more IP addresses. To me, the ideal would be to have each Localtalk network treated as a subnet, with its own host address range, yet also very desireable to be able to direct encapsulated Localtalk packets to another Kbox. I realize there is a "klugey" way of accomplishing my goals: I can use ARP subnetting, which is where a gateway (or host running "proxyarp") is defined with multiple interface addresses, such that the same physical media is carrying two subnets, thus logically separating the machines. It is true that I have done this with one of our Localtalk networks, in order to "test" the KStar software, which we seem to have running sucessfully. However, I do not find it at all desireable to continue this practice, nor can I really recommend it to other campus departments as they may not have gateways as configurable as ours, nor proxyarp, nor have the technical expertise to keep it running happily. I would really like to have both features. Does anyone else consider this to be a problem also? Does anyone know if there is a "fix" planned, or knows how one can be made? I can hack the code myself, if given a pointer. Thanks for any sympathy or advice. Alan Stebbens Manager, CCSE University of California, Santa Barbara ARPA: aks@hub.ucsb.edu UUCP: ucbvax!ucsbcsl!aks 805-961-3221 Alan Stebbens (aks@hub.ucsb.edu)
ddl@husc6.harvard.edu (Dan Lanciani) (09/21/88)
In article <858@hub.ucsb.edu>, aks@hydra.ucsb.edu ( ) writes: > I would like to understand why (apparently both) KIP and K-Star do not > support the ability to treat the Localtalk network as an IP subnet AND > provide the directed, encapsulated IP feature? I made some changes to KIP to allow the LocalTalk segment to be an ip subnet rather than an extension of the ethernet that the Kbox is on. The ip address of the subnet is read from the atalkatab database in one of the "spare" fields. There are some limitations. First, the KIP code seems to like 8 bits of host and I made no attempt to fight this trend. If you have a net mask of other than 255.255.255.0 you will have problems. Second, I didn't fix ip routing itself to understand subnets, so proxy arp from other gateways on a backbone would still be required. (I think someone else has fixed this, but it was unnecessary for us since our gateways need to do proxy arp anyway.) The Kbox will, in turn, do proxy arp for its own subnet. If this isn't clear, think of the Kbox as a gateway that knows the subnet of its LocalTalk cable but assumes that all other subnets are directly connected to its ethernet interface. Third, I did not add a RIP process to KIP (and it may well not fit) so you need to run a RIP spoofer on some other host so that hosts that *do* understand subnets will route to the Kbox. If this sounds useful given all the stated restrictions, I will make it available. Dan Lanciani ddl@harvard.*
minshall@kinetics.UUCP (Greg Minshall) (09/26/88)
From article <858@hub.ucsb.edu>, by aks@hydra.ucsb.edu ( ): > I would like to understand why (apparently both) KIP and K-Star do not > support the ability to treat the Localtalk network as an IP subnet AND > provide the directed, encapsulated IP feature? It seems that you can > treat the Localtalk network as an IP subnet, while not having the > capability of encapsulating Localtalk packets and directing them to > another Kbox across a router, *or* you can treat the Localtalk network > as an extension of the SAME subnet on which the Kbox resides (with > either static or dynamic, serialized IP address assignment), while > obtaining encapsulated Localtalk packets. Is this a correct assesment? It is true that with K-STAR (and KIP), one uses up IP address space from the ethernet side of the FastPath in order to provide IP addresses for Macs on the LocalTalk side. This is somewhat of a problem in certain cases (such as yours). The thing that makes it hard to do what you want in the FastPath 4 (and this problem essentially correlates to engineering hours) is that K-STAR does not provide all the functions of an IP router. In particular, K-STAR does not have any means of sharing with other hosts and routers that it is a path to IP subnet "X". (If K-STAR were to do this, it would probably use RIP, the protocol which Berkeley 4.x machines speak [as well as a substantial number of other entities including most "real" IP routers].) Since we don't tell anyone how to get to IP subnet "X", an installation need to set up default routes (or at least one) to IP subnet "X". This capability IS on a list of things to do to the K-STAR code, but there is no specific date or time associated with it. Your best bet is to inform your sales rep at Kinetics (or the dealer you purchase through) about your needs. Greg Minshall ...ucbvax!unisoft!kinetics!minshall (415)947-0998
jwk@SCRIPPS.EDU ("Two Sheds" Kupec) (09/01/89)
Una pregunta: I want to run CAP, among other things. For such a purpose, are KIP and K-Star 7.0 essentially the same? Which would you recommend? I haven't seen- especially in the FastPath 4 docs- what exactly K-Star 7.0 can do for me. I am using K-Star 7.0 right now in my FastPath 4 but I'm simply using NCSA Telnet 2.3 on the LocalTalk side for telnet/ftp between Mac's and Ethernet hosts. Any and (almost all) comments will be appreciated. Thanks in advance, John W. Kupec (jwk@scripps.edu) Programmer/Analyst Scripps Research Foundation Dept. of Molecular Biology