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