Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ucla-cs!zen!ucbvax!UDEL.EDU!Mills From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Chrenobyl revisited Message-ID: <8707040011.a014183@Huey.UDEL.EDU> Date: Sat, 4-Jul-87 00:11:55 EDT Article-I.D.: Huey.8707040011.a014183 Posted: Sat Jul 4 00:11:55 1987 Date-Received: Sat, 4-Jul-87 17:22:50 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 45 Mike, I'm not sure I agree with your comment that the non-core EGP gateways are terminating associations with the core gateways; in fact, I believe it's the other way around. Following is a summary of data collected over a 36-hour interval from old fuzzball EGP slugger dcn-gw, which ordinarily sustains associations with all three core EGPspeakers ISI [10.3.0.27], BBN2 [10.7.0.63] and PURDUE [10.2.0.37]. As specified in the initial dialog, the hello interval is 60 seconds, while the poll interval is 180 seconds. The table below shows the events and actions of the state machine for each peer as specified in RFC-904. A Cease event represents a termination on the part of the core gateway, while a Cease action represents a termination on the part of dcn-gw, almost always as the result of an extended period when no messages whatsoever have been received. As can be seen, the core gateway terminates the association between two and four times as often as dcn-gw. Hello interval 60 Poll interval 180 Neighbor -> [10.3.0.27] [10.7.0.63] [10.2.0.37] Tally Event Action Event Action Event Action -------------------------------------------------------------- Request 0 65 0 8 0 36 Confirm 29 0 5 0 19 0 Refuse 2 0 0 0 0 0 Cease 26 9 3 1 16 4 Cease-ack 4 26 1 3 2 16 Hello 0 2172 0 2284 0 2232 I-H-U 1568 0 1904 0 1735 0 Poll 699 609 829 741 750 667 Update 532 669 656 824 604 736 Down 221 52 123 Bad sequence 151 129 148 Note the rather high incidence of Down events. Using the j,k parameters suggested in RFC-904 and the 60-second hello interval, a Down event would occur if three out of four reachability indications during the last four minutes were lost. This sounds rather extreme. Note also the rather high incidence of Bad sequence events, which occur when a reply to a hello message has incorrect sequence number and is discarded. There is a strong argument for ignoring the sequence-number check, since the order of reachability events is seldom meaningful. It may be useful in the present regime of positive network void coefficents to do that to avoid further meltdown. Dave