Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ucla-cs!zen!ucbvax!CCV.BBN.COM!brescia
From: brescia@CCV.BBN.COM (Mike Brescia)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Chrenobyl revisited
Message-ID: <8707031752.AA22798@ucbvax.Berkeley.EDU>
Date: Fri, 3-Jul-87 13:53:59 EDT
Article-I.D.: ucbvax.8707031752.AA22798
Posted: Fri Jul  3 13:53:59 1987
Date-Received: Sat, 4-Jul-87 13:51:09 EDT
References: <8706300222.a002889@Huey.UDEL.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 31


Beginning sometime on Tuesday, apparent (very real, in fact) meltdown of
routing seems to have been caused by:

1. frequent making and breaking of egp neighbor connections, due to

2. frangible egp neighbor-alive procedures or parameters, shattered by

3. long queues (or short queues and many dropped packets) on interfaces
connected to the arpanet, because of

4. changes in arpanet topology and delay characteristics.


Each change in neighborliness leads to routing changes in EGP which propogate
at one hop per 2(?) minutes, and in GGP (the core routing) cause burgeoning of
traffic as the protocol scurries to get the routing settled again.

The core gateways were being rejected (EGP cease message sent) by many of the
neighbors on the arpanet, and then later acquired again.  This may have been
caused by long queues on the sending end toward the core gateway, or by the
long queues frequently observed in the core gateways.

Thursday afternoon, the arpanet problem was cleared up.  I think the routing
explosion has settled to a dull roar after that.

I expect that the arpanet analysts will have a description of the problem and
its solution after the holiday.

    Mike Brescia
    (Gateway group)