Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!SOLBOURNE.NYSER.NET!schoff
From: schoff@SOLBOURNE.NYSER.NET ("Marty Schoffstall")
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Troubleshooting routing problems
Message-ID: <8907141733.AA03524@solbourne.nyser.net>
Date: 14 Jul 89 17:32:59 GMT
References: <1823@ucsd.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 70

I wish the problems were only routing, the reality of many situations
is that they are caused by a myriad of problems:

	1) the diameter of the Internet continues to grow, Ultrix systems
	out of the box which are configured with a
	"low" TTL's are having lots of problems right now since there are
	10's of gateway hops now between many facilities.  This is especially
	true during a failure where the redundant multiple path capability
	kicks in, but over a much "longer" path.  This week within NYSERNet
	a T1 failed in NYC and for two days RockefellerUniv communicated
	with CUNY (both in NYC) through upstate NY.

	2) networks break for periods of time and the word doesn't really
	get out.  For instance both the NYSERNet and Merit/NSFNet NOCs saw
	truelly horrible reachability problems into the MILNET this week.
	Why?  We don't know.

	3) networks run out of bandwidth, almost nothing gets through to
	some very important hosts like SRI-NIC.ARPA with its ARPANET and
	MILNET only connections during much of the day.

	4) our backup connections are mere straws in comparison to the
	fire hoses we normally use.  A T1 connection to NEARNET (of which
	CSNET has connectivity through) has been very flakey of late,
	when it doesn't work traffic backs off onto 56kbps ARPANET.

	5) and then there is routing:  string, chewing gum, glue and people
	pushing ISO "solutions"..

Good Luck, just don't lay the blame on one cause or one group.  We're all
at fault.


Marty
--------------------
    Occasionally we here at UCSD seem to suffer from connectivity problems
    that I think are a result of lost routing information.  The symptoms are
    that we stop being able to reach some networks or they us.

    To be more specific about it, our campus Ethernet is connected via a
    Proteon router to the San Diego Supercomputer Center's Ethernet and to
    several other networks around California - "CERFnet".  We rarely have
    trouble reaching those networks.  However, from time to time, some
    networks don't seem to be reachable from our campus network, but can be
    reached from machines on the SDSC Ether or from other CERFNet members.

    For example, right at this moment I can't ping any machines on the
    192.31.103 network where RELAY.CS.NET and its nameservers live, nor can
    we ping anything on the Purdue campus.  Yet both are quite reachable
    from SDSC.  The NIC was unreachable for more than a day, and we haven't
    been able to get info from the UK nameservers for more than a week. 
    I don't get network unreachable ICMP messages.

    Our routing table consists of a few subnet entries and a default route
    to the SDSC Proteon.

    SDSC has recently lost their network guru, and whilst they are trying
    quite hard to help, they're not quite up to speed just yet.

    What I think is happening is that the reachability information for the
    UCSD network isn't getting propagated as well as it might be.  I suspect
    that my outgoing pings are probably reaching their destinations, but
    that the return ping response can't find a route back to our network.

    How can I test this from here (or elsewhere)?

    	Brian Kantor	UCSD Postmaster
    		UCSD Office of Academic Computing	(619) 534-6865
    		UCSD C-010, La Jolla, CA 92093 USA	fax: 619 534 7018
    		brian@ucsd.edu	BRIAN@UCSD ucsd!brian