Bowman@SCIENCE.UTAH.EDU (Pieter) (06/06/89)
Greg,
I suspect you can answer these questions, but if you want to tell
me to look else where that's fine as well.
I'm addressing this to info-appletalk as well for the question
about large institutions.
I believe that with a FastPath 2 running KIP the number of entries
available in the routing tables is 64. What is the number for a
FastPath 4 running either KIP or K-STAR?
We've currently got a hodge-podge of people running their own KFPS
boxes here and are trying to consolidate the administration under the
guise of connectivity. However, the University of Utah is large
enough that we'll eat up all 64 entries fast (we've already got
somewhere around 30-40 net numbers).
What are other large institutions doing to resolve this problem?
Also, are the routes cached? Does every bridge have to know about
every other bridge all the time, or can there be more nets than
entries in any one box's routing table?
Thanks in advance,
Pieter
bowman@science.utah.edu
-------rapatel@qbranch.rutgers.edu (Rocky) (06/06/89)
This is one of the things I ran into here at rutgers last year... We had exceeded the number of characters allocated for zone name space since we used long zone names. I got around the problem by generating a new KIP gw.srec which supports 128 routes, 64 zones, and has a 1024 character buffer size for zone names. We are currently using about 60 network numbers, and 22 zones. This gateway code works on our KFPS-3s and KFPS-4s. K* supposedly uses dynamically allocated tables, so it should be fine, however I haven't tested it since I am awaiting the new version that supports the NIC assigned UDP ports. There are however may be some side effects. This may not be due to the gateway code, but with atalkad running under SunOS 4.0, however it is worth mentioning anyway. Atalkad may hang all the Kboxes if you attempt to push around the configuration and routing info using "atalkad boot". You can get a kbox to re-take the config info by either powercycling it or using the fastpath manager and using the "restart" option. I am hoping it will be possible to get around the limitations of KIP by switching to using Ethertalk routing using our Cisco gateways. I haven't has a chance to test this out yet since I am still awaiting the new K* code. Maybe I need to make 20 phone calls in one day to get someone there to ship it immediately :-) Anyone else tried it yet? Rakesh Patel.
morgan@JESSICA.STANFORD.EDU (06/06/89)
Pieter: > I'm addressing this to info-appletalk as well for the question about > large institutions. I won't answer for Greg, but there's a big institution around here somewhere . . . > I believe that with a FastPath 2 running KIP the number of entries > available in the routing tables is 64. What is the number for a > FastPath 4 running either KIP or K-STAR? KIP is KIP, no matter what hardware it's running on, so it's always 64. (Limits for other resources are described in the kip/doc/limits file in the KIP distribution.) For K-Star, the answer I've always heard is "many". > We've currently got a hodge-podge of people running their own KFPS > boxes here and are trying to consolidate the administration under the > guise of connectivity. However, the University of Utah is large > enough that we'll eat up all 64 entries fast (we've already got > somewhere around 30-40 net numbers). What are other large > institutions doing to resolve this problem? At Stanford we discovered we had 63 nets in our main atalkatab a year ago, and went into serious head-scratching mode. We ended up coercing various elements of the U into running their own atalkads, thus creating multiple non-intercommunicating AppleTalk Internets (ATIs). We now have about 150 Kboxes on campus. This partitioning has its pluses and minuses. We partitioned off the student Mac clusters into their own ATI, which made various administrators feel more comfortable about their LaserWriters. On the other hand, our publications office would like their fancy phototypesetter to be Chooser-accessible campus-wide, and it cain't be done, much to their upset. We do in any case keep our AT net numbers consistent across the campus (mostly . . .) by assigning them automatically via our host registration database. We generate the atalkatabs automatically from the database, too. > Also, are the routes cached? Does every bridge have to know about > every other bridge all the time, or can there be more nets than > entries in any one box's routing table? Sadly, every route to every net in the ATI has to be present in every router (bridge in AppleSpeak). In a large ATI boxes can spend quite a bit of time just keeping one another up to date. Looking at RTMPs and ZIPs on our nets with a Sniffer, as I've been doing recently, seems to be a good introduction to Chaos Theory. We've been having weird trouble recently with routes that, despite being properly defined in the atalkatab and having nice healthy Kboxes at their ends, simply fade away. ZIP requests for the affected net numbers zoom madly about campus. Zones disappear, users complain, network managers go home early . . . *8^)* - RL "Bob" Morgan Networking Systems Stanford
rapatel@qbranch.rutgers.edu (Rocky) (06/06/89)
By the way, you will still have a limit of being able to only configure about 64 routes via atalkatab even if you use our gateway code. Atalkad is set up to send it all in one packet, which is limited to the max size of a lap packet - somewhere around 600 bytes or so. Also, when transfering the routing table between kboxes, the same limits exist. That is another reason I want to switch to using Ethertalk routing instead of KIP routing. If we replaced our KFPS-2s with KFPS-4s and gatorboxes, inidividually configure them without using atalkad, and use Cisco's Ethertalk routing, we avoid any limitations of KIP. Providing that 1) the Gatorbox like the K* uses dynamically allocated tables, that 2) they can operate on the same networks, and that 3) it all works correctly, I believe it might be possible to avoid any real limitations other than memory on the Gatorbox, KFPS-4, and Ciscos. Of course this is purely theoretical... Rakesh Patel.
minshall@KINETICS.KINETICS.COM (06/07/89)
Pieter (and all), > I believe that with a FastPath 2 running KIP the number of entries > available in the routing tables is 64. What is the number for a > FastPath 4 running either KIP or K-STAR? There is a size limit for packets containing the atalkad information (extracted from atalkatab). That comes out to something like 64 entries for an older FastPath 2 or 3. With the FastPath 4, that limit could be increased. There are two things to consider here. First, all the FastPath's would need to be FastPath 4's. A older FastPath 2 would not be able to communicate with atalkad if the packets were too large. Second, neither Kip nor K-STAR supports IP reassembly of datagrams addressed to the FastPath. So, if the packet is large enough that it gets fragmented, it will be dropped. We have thought quite a bit about how to configure large networks to run "IP talk". We have come up with a reasonable scheme which won't involve any changes to atalkad, but will allow for "arbitrary" sized networks to be configured. We will be doing the engineering work to verify that our scheme works over the next several months. Once we know that the scheme works, we will share the details with the general community. Our plan is to have this capability available by the end of this calendar year. > Also, are the routes cached? Does every bridge have to know about > every other bridge all the time, or can there be more nets than > entries in any one box's routing table? No, the routes aren't cached. Every bridge needs to know about every other bridge. This really is reasonable; *most* routing protocols need to know all their immediate neighbors. Greg Minshall 1-415-947-0998 minshall@kinetics.com Kinetics, a division of Excelan, Inc.