Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mcvax!cernvax!lid
From: lid@cernvax.UUCP (lid)
Newsgroups: comp.sys.apollo
Subject: TCP problem
Message-ID: <533@cernvax.UUCP>
Date: Thu, 10-Sep-87 18:22:36 EDT
Article-I.D.: cernvax.533
Posted: Thu Sep 10 18:22:36 1987
Date-Received: Sat, 12-Sep-87 15:34:52 EDT
References: <8709091529.AA02747@ELI.CS.YALE.EDU>
Reply-To: lid@cernvax.UUCP ()
Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland
Lines: 43


We are experiencing a lot of problems with TCP/IP here and I would like to
know if someone else out there has seen/solved similar problems.

We have an Apollo ring with 2 TCP/IP gateways (Interlan NM10 + dsp[89]0)
that connect to our Ethernet, all the machines on Ethernet know about both
gateways just like all non-gateway Apollo do.
Without a specific reason from time to time some ethernet hosts become
unreachable from non-gateway Apollos (but they still work from the gateways),
the message we get on the Apollos is "destination timed out".
The routing information on Apollo is OK, some other ethernet hosts are still
reachable.
We almost always have problems with Wollongong TCP/IP on VAX/VMS and with
Wiscnet TCP/IP on IBM/VM systems, never (almost) with Ultrix.
It seems to me that the Apollo side is OK, I monitored a "ftp vaxvms" and
saw:
	a) the request went thru the Apollo gateway,
	b) reached the vax (found out with Wollongong's netstat),
	c) the vax knew about both Apollo gateways,
	d) but the ftp'ing Apollo never got an answer.

TCP/IP on the Vax was working just a couple of minutes before and nobody
of the system people was working on it during that time.
Just note that the Vax was still able to reach other ethernet hosts,
including the Apollo gateway.

Does all this resemble something you've already seen ?
Any suggestion about what the problem can be ?

It seems to me that when we only had 1 gateway things were working
better, but I wouldn't bet on this because the TCP/IP usage is steadily
growing on our site, so may it was working better just because of the
smaller amount of traffic...

As far as Apollo hosts are concerned the thing works as you would expect:
if the first gateway in the routing table of the Apollo does not answer,
the second one is used, providing automatic fall back for Apollo users.
All the exercise started to provide more reliable and continued
operations of TCP/IP !!!

Thanks to all who can give me some hints.

	Achille Petrilli