[comp.protocols.appletalk] Routing problems with KFPS-4

doug@seismo.gps.caltech.edu (Doug Neuhauser) (06/15/90)

I am having intermittant problems with routing on a network with several 
KFPS-4s.

CONFIGURATION:

Ethernet # 1:
1.	3 KFPS-4s, each routing a separate Localtalk network to Ethernet #1.
	Each KPFS-4 has 4.1 Proms, and is running K-Start 7.0 (loaded with
	Fastpath Manager II Ver 5.0), 2 out of 3 upgraded to Rev J.
	Each Localtalk has its own zone (e.g.: LT1, LT2, LT3).
	Localtalk contains Macs and lasewriters (and a few PCs with Localtalk
	interfaces).
2.	Several Unix boxes (running CAP)
Ethernet # 2:
1. 	Several Unix boxes (running CAP).
2.	One Unix box which is the ATALKAD host for the above network.
The 2 ethernets are connected via a Cisco router that has IP and Ethertalk
routed between the 2 networks.  The 2 ethernets both SHARE 2 zones:
IP1 and ET1 (separate zones for IP-talk and Ether-talk).

PROBLEMS:

1.  The first problem that I have is that the KFPS-4s seem to occasionally
lose routing information.  Initially, all CAP software works (I can print
from any Unix host to any laserwriter on any Localtalk), but occasionally
one of the KFPS-4s will apparently lose its routing information.  Running 
	atlook @LT1
will show ONLY the IPADDRESS for the KFPS-4 itself - nothing in the 
Localtalk zone LT1.  This can apparently be fixed by running the Chooser on
a Mac in the LT1 zone, or by issuing an "atalkad route" command.  CAP
printing will start up again, and the atlook command will show all services
on the Localtalk network.

2.  The second program is related to the IP address administration and
routing of IP packets, using NCSA Telnet (with or without Mac/TCP) or
Stanford MacIP package.  Each KFPS-4 is set up to administer 19 dynamic and 0
static IP addresses.  The intermittant problems that occur are:
a.  A Mac "thinks" it has an IP address (atlook shows it), but the Mac will
not respond to a "ping" from a host on the Ethernet.
b.  The Mac cannot connect to any IP address on the Ethernet.

QUESTIONS:

1.  Has anyone else experienced problems such as these?  Kinetics is finally
"looking into" problem 1, but maintains that problem 2 is an "application"
problem, NOT a Fastpath routing problem.  Any solutions?

2.  Is the use of dynamic instead of static addresses causing or
exacerbating problem #2?  

3.  I have discovered that some users run NCSA Telnet (with built-in IP
code) under Multifinder, and then place it in the "background" for hours at
a time.  Does this cause problems with either dynamic or static address
resolution or mapping within the Fastpath?  Kinetics couldn't provide me any
information about how dynamic addresses are dispensed and deallocated in
K-Star, but if it is the same as KIP0688 (is it?), this looks as though it
might cause the Fastpath to think a dynamic IP address is no longer in use.
(Would this cause problems with static IP addresses too?).

4.  Any suggestions as to how to further diagnose and/or solve these
problems?

I will gladly summarize any information that I receive.
----------------------------------------------------------------------------
Doug Neuhauser			Div. of Geological and Planetary Sciences
doug@seismo.gps.caltech.edu	California Institute of Technology
818-356-3993			MS 252-21, Pasadena, CA  91125