From lindahl@violet.berkeley.edu Tue Jul 7 10:11:22 1992 Received: from violet.Berkeley.EDU by cats.UCSC.EDU with SMTP id AA27962; Tue, 7 Jul 92 10:11:25 -0700 Received: by violet.berkeley.edu (5.61/1.32) id AA09041; Tue, 7 Jul 92 10:11:22 PDT Date: Tue, 7 Jul 92 10:11:22 PDT From: lindahl@violet.berkeley.edu (Ken Lindahl 642-0866) Message-Id: <9207071711.AA09041@violet.berkeley.edu> To: warner@cats.UCSC.EDU Subject: Re: FastPaths and Kstar Status: R Jim, With respect to your comments about Berkeley's AppelTalk network and atalkatab: > 1. KIP (Appletalk in IP) nets are defined on all subnets > with FastPaths. Berkeley defines these nets with H > entries because directed subnet broadcasts are not > supported by the P4200 gateways. Right. > 2. Some subnets do not have EtherTalk enabled [e.g. 128.32.128.x] > 3. Berkeley has no phase I EtherTalk. Sort of. Some subnets do not have EtherTalk Phase 2 (ET2) enabled. However, all FPs currently have EtherTalk Phase 1 (ET1) enabled but not configured, a situation I inherited from my predecessor. (Apparently this was necessary at some time in the past in order to make CAP work properly. Consequently, FPs with ET2 enabled are "transition routers." My plan is to make certain that the current version of CAP is compatible with ET2-only FPs and then to begin transitioning to ET2-only. I want to keep this as simple as possible so I am tyring to keep "transition" routers to a minimum. At this time, I am enabling ET2 only on subnets where I know there is a need for it. When I get past the transition to ET2-only, I will probably enable and configure ET2 on every subnet. > 4. On subnets with more than one FastPath, you "seed" one > only one of them. What I can't tell is whether that FP is > the only one with EtherTalk enabled, or you allow the other > FPs to learn the net number from the seed bridge. Not really. I configure all FastPaths from atalkatab. Due to a bug in K-Star, this isn't always possible for FPs supporting ET2 nets. (I think we discussed this bug on the phone.) In these cases, I configure the ET2 interface in the FP using Shiva Net Manager. None of the FPs "learn" network numbers from other routers except by "accident." By the way, the "other routers" to date are mostly accursed Novell servers, occasionally another FP with ET2 enabled, and in one instance, a previously undetected Shiva TeleBridge (despite the name, these are actually half-routers). >How do you coordinate assignment of Etalk net numbers to Novell >servers? Are you the net number czar? I am the AppleTalk net number czar. The campus has a site license for Novell that provides substantial savings if the software is purchased through our Workstation Support Services Group. I have interjected myself into that process. To date, there is only one (known) instance of a depart- ment purhasing the software on their own; in that instance, the administrator was very willing to accomodate my demands, errr... suggestions. >I gave some thought to the problem of overloading of the tftp >server, and also the problem of redundancy. ... I think your concern here is that some FastPaths may "learn" their network numbers and zones from other FastPaths (or other routers) before completion of the TFTP and atalkatab parsing. Therefore, you would like to restart all of your FPs simultaneously. "Learning" of network numbers hasn't proven to be a problem here. I think I understand this: this will only occur where several FPs are on the same subnet AND one of them has ET2 enabled. There are only a few subnets that meet those criteria, at this time. (Note: although all of the FPs have ET1 enabled, they are specifically configured NOT to send RTMP. This is option 5 in K_Star. Still, your idea for a simultaneous TFTP server is interesting. > For redundancy, >since PCs and E-net cards are cheap, it would be easy to have a >duplicate setup ready to deploy if the first PC went toes-up >for any reason. I actually have a redundant Unix machine that I could use in this case. It would simply need to be configured to use the appropriate IP address. But I still think K-Star should have an "alternate TFTP host" configuration. If it times out on the first host, it should try the second. Then, the switch to the alternate machine would be transparent, except for the timeout period. Ken From warner@cats.UCSC.EDU Wed Jul 8 01:35:33 1992 Received: from sasha.UCSC.EDU by cats.UCSC.EDU with SMTP id AA08177; Wed, 8 Jul 92 01:35:33 -0700 From: warner@cats.UCSC.EDU (Jim Warner) Received: by sasha.ucsc.edu (5.65/4.7) id AA03753; Wed, 8 Jul 92 01:35:33 -0700 Date: Wed, 8 Jul 92 01:35:33 -0700 Message-Id: <9207080835.AA03753@sasha.ucsc.edu> To: lindahl@violet.berkeley.edu Subject: Re: FastPaths and Kstar Cc: warner@cats.UCSC.EDU Status: R Thanks for the answers to my questions. My strategy here is to hide the information that transition mode is even an option. Once the early morning crews have the 9.1 PROMs fully deployed, I'm going to start moving subnets to phase II directly. The reason is that there's a general principal around here: Never offer any service temporarily that you aren't willing to offer forever. If you want to try something interesting, telnet to cowell-g.ucsc.edu Our "low security" password is "sorry". Apple-talk phase I is enabled between two of the interfaces on this router [but not on the backbone]. The interesting commands are: show apple route show apple zone Most of the campus routers are running software versions too far down-rev to be able to route even appletalk phase-I. Cowell-g is an obvious exception. [This will change in about a month]. I'll probably do more of this. It sure beats spending $1.5K for a FastPath in areas that are pure Ethertalk (no localtalk). And the difference between configuring a Cisco versus a FastPath is the difference between a ten-speed bicycle and a tricycle. You were going to find out (from Monica?) the reason and the fix for FPs that wouldn't take the PROM upgrade directly and had to be returned to shiva. We just shipped off one FP that had that problem to shiva. Cheers -jim From lindahl@violet.berkeley.edu Thu Jul 9 17:28:22 1992 Received: from violet.Berkeley.EDU by cats.UCSC.EDU with SMTP id AA03662; Thu, 9 Jul 92 17:28:26 -0700 Received: by violet.berkeley.edu (5.61/1.32) id AA01001; Thu, 9 Jul 92 17:28:22 PDT Date: Thu, 9 Jul 92 17:28:22 PDT From: lindahl@violet.berkeley.edu (Ken Lindahl 642-0866) Message-Id: <9207100028.AA01001@violet.berkeley.edu> To: warner@cats.UCSC.EDU Subject: Re: FastPaths and Kstar Status: R Thanks for the answers to my questions. My strategy here is to hide the information that transition mode is even an option. Once the early morning crews have the 9.1 PROMs fully deployed, I'm going to start moving subnets to phase II directly. The reason is that there's a general principal around here: Never offer any service temporarily that you aren't willing to offer forever. A principle we try to adhere to as well. I don't consider transition routing an option, rather a necessary evil. I don't advertise transition routing, but when it comes up in a conversation, I don't avoid it either. My exper- ience so far is that the people who participate in those conversations are knowledgable enough that they recognize transition routing as a disadvantage. They're more interested in how quickly we can get away from it, rather than whether I'll keep it alive. (If anyone asks, the answer is "no"). Do you have user workstations running Phase 1 EtherTalk? How are you going to coordinate them switching to Phase 2 at the right time? If you want to try something interesting, telnet to cowell-g.ucsc.edu Our "low security" password is "sorry". Apple-talk phase I is enabled between two of the interfaces on this router [but not on the backbone]. The interesting commands are: show apple route show apple zone Interesting. What are the Phase 1 routers, FastPaths? You were going to find out (from Monica?) the reason and the fix for FPs that wouldn't take the PROM upgrade directly and had to be returned to shiva. We just shipped off one FP that had that problem to shiva. I've sent her mail. She has been on vacation for a couple weeks and is due back sometime next week I think. I'll let you know as soon as I hear from her. Irony: Tuesday morning I replied to your mail in which you described your idea for a very fast, PC-based TFTP server that could handle the situation where large numbers of FastPaths tried to boot at the same time. Tuesday afternoon we experienced a short (75 seconds), campus-wide power-outrage. Guess what my 100+ FastPaths did. Guess what my TFTP server did. Now, please don't tell me any more of your ideas -- I'm beginning to question cause-and- effect here. :-) Interestingly enough, all but two FastPaths eventually booted without intervention. Of the two that didn't: One (pubs1fp.Pubs.berkeley.edu, 192.101.42.2) is on the other side of several UCOP routers; apparently some of those routers were also affected. When routing was restored, the FastPath had lost its mind and needed a new K-Star and configuration. The other Fast- Path is at the far end of a leased serial line that we have been having problems for a couple weeks. Overall, I'd say the FastPaths recovered pretty gracefully. Ken