jmvogtle@ICARUS.CNS.SYR.EDU (John M. Vogtle) (11/01/88)
Here at Syracuse University we're running KIP and K-STAR with very
good results - too good as a matter of fact. The Appletalk nets on
campus are growing rapidly and we can see the KIP atalkad 64 entry
limit quickly approaching.
I seem to remember someone on the net having similar problems some
time ago but I can't remember how the situation was resolved. Does
anyone know if the 64 entry limit can be broken??? If not, what are
people doing to get around it?
Any and all help would be appreciated. Thanks.
___
( > / John M. Vogtle
\_/______/_ ____ Systems Programmer
/ / (_) / /_/ / <_ Syracuse University
<_/ Internet: jmvogtle@icarus.cns.syr.EDU
AT&T Net: (315) 443-5772
"One planet is all you get." Snail Net: 221 Machinery Hall
Syracuse University
Syracuse, New York 13244-1260morgan@JESSICA.STANFORD.EDU (11/02/88)
John Vogtle writes: > Here at Syracuse University we're running KIP and K-STAR with very > good results - too good as a matter of fact. The Appletalk nets on > campus are growing rapidly and we can see the KIP atalkad 64 entry > limit quickly approaching. > > I seem to remember someone on the net having similar problems some > time ago but I can't remember how the situation was resolved. Does > anyone know if the 64 entry limit can be broken??? If not, what are > people doing to get around it? There are a number of limits in KIP that might be a problem in large installations. They are listed in a file called "limits" in the KIP documentation. Herewith: > o Space taken by ALL zones names: 256 bytes (256, azonenames, > glob.h). Every zone name is stored as a pascal string so each one > takes strlen + 1 bytes of storage. > > o Number of zones: 32 (NAZONES, azone, gw.h) > > o Number of dynamic IP addresses: 32 (NIPDAD, ipdad, NIPDAD) > > o Number of routes: 64 (NAROUTE, aroute, gw.h). This includes all > routes configured from atalkatab and all acquired routes. Here at Stanford, with a recent large-scale dorm installation complete, we're up to somewhere around 120 Kboxes on campus. At one LocalTalk-AppleTalk network per Kbox, and some substantial number of both IP-encapsulated-Atalk (is IPTalk a common term for this? Is it trademarked?) and EtherTalk networks, there's probably over 200 AppleTalk networks on campus. We had our "64 crisis" in May of this year, I think. Our way of dealing with it was to encourage organizations that could to run their own atalkad servers, creating what I have come to call "separate AppleTalk universes" (is there some more widely-used term?). We now have seven or so, the largest with about 50 networks listed. Each universe is theoretically incommunicado with all others, since they don't know routes, zones, etc. Some people like this "security" feature. However, if two universes agree on network numbers and zone names, and a particular network (that is, Kbox, IPTalk, or Etalk net) is listed in both universes's atalkatabs, a server device (LW, AppleShare server, CAP, etc) will be able to be located and used by stations from either of the universes. This might be used to set up one or more nets that act as a central point of contact between all the universes, but we haven't done this yet. One likely future hazard is the growing use of EtherTalk. If two Kboxes from different universes share the same Ethernet cable, and both use EtherTalk, they will see each others' RTMP broadcasts, and all routes, etc will flow between them, possibly exceeding KIP table limits. And there's really no way for us to prevent it or tell when someone's about to do it (this is the dark underside of plug-and-play). It seems that K-Star, unlike KIP, doesn't use fixed table sizes for routing tables and such, so it's hard to find out the corresponding numbers to those critical KIP limits. It's anyone's guess whether a large network made entirely of KFPS-4s running K-Star would run into implementation-based limits, or would expose inherent AppleTalk limits, or just work fine. There are certainly rumbles that changes/extensions to AppleTalk are in the works at Apple to address these and other issues. - RL "Bob" Morgan Networking Systems Stanford