Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 4/15/85; site ucbvax.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!tcp-ip
From: tcp-ip@ucbvax.ARPA
Newsgroups: fa.tcp-ip
Subject: Re: Gateway re-directs.
Message-ID: <8584@ucbvax.ARPA>
Date: Fri, 28-Jun-85 11:26:36 EDT
Article-I.D.: ucbvax.8584
Posted: Fri Jun 28 11:26:36 1985
Date-Received: Sat, 29-Jun-85 03:14:42 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 26

From: Mike Brescia 


	(... 26.0.0.57 sending packets to BRL-TGR starting with 26.0.0.106)
	the MIL-ARPA gateway sent redirects to the MINET gateway (26.1.0.40).
	The MINET gateway, in turn, then sent back redirects to the BRL gateway.

The reason for this is, while MILARPA and BRL are both gateways on the MILNET,
MILARPA does not know about BRL, because BRL uses exterior gateway protocol
(EGP) to pass around routing information, but the only gateways on MILNET
which have EGP are MINET and AERO (26.8.0.65).  The protocol used between
'core' gateways (e.g. MILARPA, MINET, AERO) does not carry the neighbor
information about BRL from MINET to MILARPA, only the fact that the net is
reachable.

Current plans include putting EGP in some of the MILNET-ARPANET gateways so
that routes from the ARPANET can reach local area nets off the MILNET without
taking an extra hop through MINET or AERO.

You should not have too much to worry about in your case, because when the
redirects settle down, you do have the shortest route to BRL-TGR.  It just
takes 1 or 2 extra packets to get the (TCP) connection established.  If your
host were to save this information around between connections, you could
eliminate even the first redirect in most exchanges.

	Mike Brescia