Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!sdcsvax!brian
From: brian@sdcsvax.UCSD.EDU (Brian Kantor)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: routing problems?  Core gateways?
Message-ID: <4488@sdcsvax.UCSD.EDU>
Date: 14 Jan 88 17:52:29 GMT
References: <4481@sdcsvax.UCSD.EDU> <281@hub.ucsb.edu>
Reply-To: brian@sdcsvax.UCSD.EDU (Brian Kantor)
Organization: UCSD wombat breeding society
Lines: 43
Summary: at least we now know what the problem is...

Well, we're a little closer to the solution - at least we know what the
real problem is, although not the cause.

As I said, we're X.25 connected to our Milnet IMP.  That requires that
we have an X.25 virtual circuit for each separate host or gateway on the
Milnet that we want to talk to.  If we are the first person to send a
packet to that address, we open the VC in the range from 1 to 32.  If
the distant host is the first to send a packet to us, the IMP must open
the VC in the range 64-33.  If a VC is open already (no matter whether
the IMP or our interface opened it), it will be used.  If a VC is idle
for a configurable length of time (currently 60 seconds), the circuit
will be closed.

It seems that our problem is caused by the IMP not being able to open
VCs to us.  We CAN open outgoing VCs, but if the first packet from a
host or gateway on the Milnet is originated by them instead of us, then
the VC connection won't happen and things don't work.

Our problem with Seismo and other hosts is that they are on the far
side of gateways to the Arpanet, so that packets from them to us must
pass through a minimum of TWO gateways - one from them to Arpa, then one
of the Arpa-Milnet mailbridges - in order to get to us.  That
means that since the ICMP echo response (as well as all other traffic from
them to us) might well come to our host through a different mailbridge
than the one through which we send the packets to them, they might
indeed wind up seeing our packets but we won't see theirs, because the
X.25 VC from the IMP for that mailbridge couldn't be opened.

Clear as mud, eh?

We think it started after the IMP was reloaded after a power failure
last Saturday.  The NOC has somebody looking into it, they tell me.  In
the meantime, we're working around the problem by sending a single ping
packet to each of the seven mailbridges once every 45 seconds.  That's
sufficient to keep the X.25 virtual circuits active so people can get to
us.  It doesn't cure the problem, but it's a whole lot more livable this
way.

Deep gratitude to Mike Brescia of BBN who helped figure out what's going
on - or not going on, in this case.

	Brian Kantor	UCSD Office of Academic Computing
			Academic Network Operations Group  
			UCSD B-028, La Jolla, CA 92093 USA