cpw%sneezy@LANL.GOV (C. Philip Wood) (11/26/88)
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 eshop@saturn.ucsc.edu (Jim Warner) (11/26/88)
In article <8811251901.AA04669@sneezy.lanl.gov> cpw%sneezy@LANL.GOV (C. Philip Wood) writes: > Note, it does not send a redirect cause its forwarding on a > default route. I am not aware of such a rule. Is it possible that your gateway B is a Sun? Our Suns *never* send redirects. I think such a rule would be a bad idea. Hosts should be dumb and gateways should be smart, and all that stuff. How's a dumb host supposed to find out where to send packets if not for redirects? I set up a situation similar to yours by pinging from Stanford to a nonexistant Santa Cruz subnet. This is against the flow of the default path. All I get back is a single destination unreachable message. It appears that Proteon routers do not share your problem. To route the packet from A, B should first apply the class C net mask, ff.ff.ff.00 to the destination address. It determines this matches one of its nets. It then applies the subnet mask for this net, ff.ff.ff.e0 in your case. It doesn't find a matching subnet route. If it has a default subnet route the packet can be forwarded in that direction. I claim that it should not use the default *NET* route as a sort of poor substitute for a missing subnet default route. jim warner