Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!LANL.GOV!cpw%sneezy
From: cpw%sneezy@LANL.GOV (C. Philip Wood)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  Echo on undefined subnet mystery (solution)
Message-ID: <8811251901.AA04669@sneezy.lanl.gov>
Date: 25 Nov 88 19:01:34 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 60


	From: warner@ucscc.ucsc.edu (99809000)
	Message-Id: <8811231745.AA16251@ucscc.UCSC.EDU>
	To: cpw@beta.LANL.GOV
	Subject: Re:  Echo on undefined subnet mystery
	Status: RO

	I'll bet you have a routing loop.  128.165.4.10 and 128.165.4.4 both
	think that the best route to the nonexistant subnet is via the other
	one. 
Actually, they both pointed to 128.165.4.16 who had an interface for
192.5.16 (but not 192.5.16.1)
	
 	If you inspect the TTL field in the echo packets, I'll bet
	you see them counting to zero.
Yep.

	As to what caused the loop, do you have a default route?  That is
	probably the link that completes the loop.  I'll bet that 128.165.4.4
	is your default gateway.
Yep. (128.165.4.16 had the default route entry).

	If I'm right, then your example stands as a proof that gateways
	should not use the network default route (0.0.0.0) to route to
	unknown subnets of a network for which they know the subnet mask
	(i.e. a network on which they have an interface).  
Yep. (Would you suggest, that all gateways with knowledge of subnet mask
for unknown subnets acquire all routing entries, or, that those kind of
gateways not route to defaults for subnets they do not know about?)
	jim warner


Jim Warner,

Thanks for your help. I looked further and figured the following:

	1. Client A (128.165.4.10) with one interface has routing entry
	   for 192.5.16 -> 128.165.4.16, and sends an icmp echo packet
	   with ttl of 255 there.
	2. Gateway B (128.165.4.16) with connections only to networks 
	   192.5.16.32 and 192.5.16.64 and a default routing entry pointing 
	   to Gateway C (128.165.4.4) decrements ttl, sends the echo on to C.
	   Note, it does not send a redirect cause its forwarding on a
	   default route.
	3. Gateway C has routing entry for 192.5.16 -> B, decrements ttl,
           sends the echo to B and redirect to A.
	4. Client A gets 1 redirect and B gets the echo back.
	5. I guess at this point we repeat until ttl goes to zero.
	
The end result is:

	A sends 1 echo to B
	B receives 128 echos forwards 127 echos to C
	C forwards 127 echos to B and sends 127 redirects to A.

So, I guess its back to the old gated.conf scratch pad.  I sure hope I
have enough mbufs for the 1177 networks currently defined at SRI.

Actually, the current count on my default gateway is 590.
	
Phil Wood,  cpw@lanl.gov