kellow@ndcheg.cheg.nd.edu (John Kellow) (05/28/89)
I just recently started reading this group so maybe this has been discussed before, but here goes... We've been having problems in replacing a Fastpath 3 with a Fastpath 4. We're running a Sun 3/50 as a file server using CAP and we also print to a LaserWriter on the appletalk side ( we're also running lwsrv but don't use it that much since the LaserWriter is on the appletalk side). When we put in the Fastpath 4, it didn't work. I think someone from Kinetics told us that the new box couldn't use the ddpstartrange of 200 so we switched it back to 768. Now AUFS works, telnet from the macs to the sun works but lwsrv and printing from the sun doesn't work. Atlook doesn't return anything, not even from the ethernet side, and getzones returns an error. Atistest works. So what are we doing wrong? Should we just keep the Fastpath 3 and try to send the 4 back? Is there any great advantage to upgrading? John Kellow kellow@ndcheg.cheg.nd.edu
morgan@JESSICA.STANFORD.EDU (05/31/89)
John Kellow writes: > I just recently started reading this group so maybe this has been > discussed before, but here goes... We've been having problems in > replacing a Fastpath 3 with a Fastpath 4. We're running a Sun 3/50 as > a file server using CAP and we also print to a LaserWriter on the > appletalk side ( we're also running lwsrv but don't use it that much > since the LaserWriter is on the appletalk side). When we put in the > Fastpath 4, it didn't work. I think someone from Kinetics told us > that the new box couldn't use the ddpstartrange of 200 so we switched > it back to 768. Now AUFS works, telnet from the macs to the sun works > but lwsrv and printing from the sun doesn't work. Atlook doesn't > return anything, not even from the ethernet side, and getzones returns > an error. Atistest works. So what are we doing wrong? Should we > just keep the Fastpath 3 and try to send the 4 back? Is there any > great advantage to upgrading? We've been gaining a lot of experience upgrading many of our campus KFPS-[123] boxes to the KFPS-U, or whatever it's officially called, that runs K-Star (we have a lot of KFPS-4s too, but I'm not talking about those). Here are a few things we've found; maybe some of them apply to John's or other people's situations. 1. There's some difference with how the KFPS-U with K-Star responds to NBP lookups with * as the zone, compared to how KIP responds. Some of our users had trouble with CAP locating resources on LocalTalks behnd upgraded boxes. The solution in most cases so far has been to completely specify printer names (MyPrinter:LaserWriter@MyZone instead of MyPrinter:LaserWriter@*). You should also specify the zone name when using atlook, etc. 2. The KFPS-U seems unusually sensitive to busy Ethernets. On one very busy net the box would get stuck while loading K-Star from the LocalTalk. We tried disconnecting the Ethernet cable while loading and voila, it worked. This doesn't seem like a long-term solution, though . . . On the same net SU-Mac/IP failed on a LocalTalk-attached Mac, the KFPS-U having failed to respond to the IPGATEWAY lookup. We took a look with the Sniffer and found that each NBP lookup broadcast from the KFPS-U was getting back 12 messages (ICMP unreachables, ARPs for the broadcast address, etc) from misconfigured Unix systems on the net (which, alas, are not under our control, if anyone's). We redefined the zones so that the LocalTalk was a separate zone from the EtherTalk/IPTalk nets (they had all been one zone before), which eliminated the Ethernet broadcasts on NBP lookups, and Mac/IP commenced to work. (KIP, I might add, worked well enough on the un-upgraded KFPS-1 and -2 on this same busy net.) 3. I did a quicky performance test on the various KFPS models by using AppleShare on my Ethernet-attached MacII to copy a file to a CAP/Aufs server, and watching the packet flow with a Sniffer. Each packet in this case goes through the Kbox which translates it from EtherTalk format (which the MacII understands) to IPTalk format (which CAP understands). This should be a sort of worst-case test of Kbox performance, since handling LocalTalk packets should be much easier. The AppleTalk Transaction Protocol provides a nice performance picture as it marks the packets in a sequence which need retransmission. The tests were done on an Ethernet with a low (<10% max) level of background traffic. With a KFPS-4, all packets went through smoothly in both directions, so no retransmissions were required. A KFPS-2 consistently dropped every second packet from the MacII, thus requiring 15 packets to be sent from the MacII to get 8 successfully to the Aufs server (no Aufs responses were dropped). The KFPS-2U, curiously, consistently dropped the second, third and fourth packets of the 8-packet sequence on the initial blast, but handled the 3 retransmitted packets successfully, thus requiring only 11 packets to get 8 through. For this test, then, the KFPS-U was just about half-way in performance between the 2 and the 4. Other tests can and should be done, your mileage may vary, etc. My view is that even the KFPS-U's performance isn't really acceptable for doing file service across nets, but that the 4 will be OK in most cases. - RL "Bob" Morgan Networking Systems Stanford