Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!husc6!hao!ames!ucbcad!ucbvax!UDEL.EDU!Mills From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Chrenobyl revisited Message-ID: <8706300222.a002889@Huey.UDEL.EDU> Date: Tue, 30-Jun-87 02:22:54 EDT Article-I.D.: Huey.8706300222.a002889 Posted: Tue Jun 30 02:22:54 1987 Date-Received: Sat, 4-Jul-87 18:44:49 EDT Sender: usenet@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 91 Folks, Alerted by an increasing incidence of timewarps (unexpectedly large excursions in measured time discrepancies between Internet time servers) I found that the core gateway system seems to have lost its marbles. Faithful old fuzzsoldier macom1 (10.0.0.111) squawks EGP with purdue, bbn2 and isi gateways, so presumably those gateways should have a reasonably consistent and stable routing data base. Following is a sample of the routing tables in these three gateways: purdue UP: macom1 10.0.0.111 (Arpanet) (EGP or indirect via EGP) upenn 128.91 4 hops (ext) via macom1 10.0.0.111 (Arpanet) Washington 192.5.8 1 hop (ext) via macom1 10.0.0.111 (Arpanet) cpw-psc 192.5.146 4 hops (ext) via macom1 10.0.0.111 (Arpanet) bbn2 UP: macom1 10.0.0.111 (Arpanet) (EGP or indirect via EGP) upenn 128.91 4 hops (ext) via macom1 10.0.0.111 (Arpanet) cpw-psc 192.5.146 4 hops (ext) via macom1 10.0.0.111 (Arpanet) isi UP: macom1 10.0.0.111 (Arpanet) (EGP or indirect via EGP) Washington 192.5.8 1 hop (ext) via macom1 10.0.0.111 (Arpanet) cpw-psc 192.5.146 4 hops (ext) via macom1 10.0.0.111 (Arpanet) Network Washington (since retired, now macomnet) is directly connected to macom1, so should indicate 1 hop, while networks upenn and cpw-psc are indirectly connected via NSFNET and should indicate 4 hops. All three of these networks should be reachable by macom1; however, the above data indicate some of the gateways are reachable only by other gateways. Clearly the core gateways do not have consistent routing tables. This would not be so bad if the tables were stable and did not oscillate with time. Unfortunately, the tables are bobbing like corks, as shown by the following sample made a few minutes after the previous: purdue UP: macom1 10.0.0.111 (Arpanet) (EGP or indirect via EGP) upenn 128.91 4 hops (ext) via macom1 10.0.0.111 (Arpanet) cpw-psc 192.5.146 4 hops (ext) via macom1 10.0.0.111 (Arpanet) bbn2 UP: macom1 10.0.0.111 (Arpanet) (EGP or indirect via EGP) upenn 128.91 4 hops (ext) via macom1 10.0.0.111 (Arpanet) Washington 192.5.8 1 hop (ext) via macom1 10.0.0.111 (Arpanet) cpw-psc 192.5.146 4 hops (ext) via macom1 10.0.0.111 (Arpanet) isi UP: macom1 10.0.0.111 (Arpanet) (EGP or indirect via EGP) cpw-psc 192.5.146 4 hops (ext) via macom1 10.0.0.111 (Arpanet) Gateway macom1 happens to be the primary entry point for macomnet (192.5.8), so one might ask how the core system thinks it might be reached. Alas, the three gateways have curious, inconsistent ways of reaching it, some quite bizarre: purdue 192.5.8 1 hop (ext) via macom1 10.0.0.111 (Arpanet) bbn2 192.5.8 4 hops (ext) via psc.psc.edu 10.4.0.14 (Arpanet) isi 192.5.8 1 hop (ext) via macom1 10.0.0.111 (Arpanet) Well, even that might not break the bank, except for the fact the tables are oscillating like crazy. Here is a sample recorded a few minutes after the above: purdue 192.5.8 2 hops (ext) via ISI 10.3.0.27 (Arpanet) bbn2 192.5.8 1 hop (ext) via macom1 10.0.0.111 (Arpanet) isi 192.5.8 2 hops (ext) via BBN2 10.7.0.63 (Arpanet) The last time I saw this behavior bugs were found in the core gateway code and subsequently fixed. The present behavior is at least as bad as I have ever seen and suggests very serious instabilities have recurred. In fact, the logs on macom1 and other fuzzballs I can reach out and touch indicate intermittent loss of connectivity and general flakiness consistent with the above observations. To add to the fun above, I discovered that gateway ngp.utexas.edu (10.0.0.62) is mercilessly beating on macom1 as the gateway to host brl-aos (192.5.22.82), probably the domain nameserver there. Poor macom1 has been returning several thousand ICMP Redirect messages to what it thinks is a broken host (how would it know differently?). Gateway ngp.utexas.edu presumably discards redirects as messages from the Devil. The routing data base of all three core EGP speakers, not to mention the poor fuzzballs, clearly states network 192.5.22 is reachable only by the ARPANET/MILNET gateways, not macom1. I can't raise the ngp keepers on hf, vhf or space relay to correct this nonsense. Can somebody drop something heavy on their heads? Finally, it would be fun to find out why so much traffic is sloshing by macom1 for the NSFNET swamps, in spite of the fact that very little traffic is destined for the nets it advertises. I suspect some j-random ARPANET hosts have a very sticky gateway table that locks on to a gateway that happens to volunteer reachability when times are bad and doesn't have sense enough to backtrack to the good guys when times are good. This isn't necessarily a fault on the part of the hosts; however, an EGP gateway may not know that, although it can reach a network, other EGP gateways are a better choice. More thought needed on that. Comments from the gateway crew at BBN would be highly prized. Dave