Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!decvax!bellcore!ulysses!ucbvax!RED.RUTGERS.EDU!HEDRICK From: HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: more oddities from the swamp Message-ID: <12208373228.43.HEDRICK@RED.RUTGERS.EDU> Date: Wed, 21-May-86 01:57:05 EDT Article-I.D.: RED.12208373228.43.HEDRICK Posted: Wed May 21 01:57:05 1986 Date-Received: Thu, 22-May-86 01:23:31 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 64 Approved: tcp-ip@sri-nic.arpa I have come up with a somewhat better kludge for notifying my hosts about the gateway than using broadcast ICMP redirects. The machines I am worried about are normally configured to run routed as they come out of the box. It turns out that it is possible for a gateway to advertise via routed that network 0 is one of the destinations it can forward to. This will set up the gateway as a default gateway on the routed clients. This seems a more controlled way of doing what I want then unsolicited ICMP redirects, since routed is the protocol that gateways are supposed to use to announce themselves. However there is another interesting problem with either approach. They both require broadcasts, but it is not clear whether it is safe to do broadcasts on our networks. Our problem is that half of our hosts know about subnetting and the other half don't. We have to make our Pyramid and Sun kernels know about subnetting, because we have machines of both kinds with more than one interface. But we have lots of machines from other vendors that do not support subnets and do not supply source. Generally this is not a big deal. They can talk to each other. Routing entries have to be a bit different for the two classes of machines, since one thinks all of 128.6 is one network, whereas the other knows about 128.6.n. But our gateway can handle the ARP hack, so if a non-subnet machine ARPs a machine on a different subnet, the gateway handles it. The problem comes in when we send a broadcast. the only broadcast address that Unix will understand is network.0 (I think this is probably a bug. But it doesn't do me any good to send a broadcast which meets all the RFC's but nobody will receive. So I'm stuck.) The question is, what network number should I use. If I send to 128.6.0.0, the non-subnet machines accept it just fine. But the subnet machines all think I am trying to send a broadcast on subnet 0. Since that is not their subnet, they do not process the broadcast. For some reason that I don't quite understand, we get back a bunch of ICMP ttl exceeded messages. As far as I can tell, some of the machines try to forward the message to subnet zero, and get into a routing loop. If I send to 128.6.4.0, the subnet machines accept it just fine. But the non-subnet machines think I am trying to send to host 4.0 on network 128.6. They helpfullly attempt to forward it. Thus I suddenly get an ARP request from every non-subnet machine, asking for the address of 128.6.4.0. Our Arpanet gateway, which also does not know we have subnets, also thinks we are trying to get it to forward packets to 128.6.4.0. But it notices that this is on the same network, pronouces it an utterly bogus request, and sends back an ICMP redirect to the original sender, saying "do it yourself, idiot" [by the way, is this a standard use of ICMP redirect? What is a gateway supposed to do when a host asks it to forward a packet back onto the same network that it came in from? Intuitively, it seems reasonable that an ICMP redirect should occur, but it is not clear what gateway address one should use. Our Arpanet gateway uses the originator's address. This is somehow morally correct and esthetically satisfying, but no implementation that I know of knows what to do when given an ICMP redirect pointing back at itself.] The net effect of all of this is the any broadcast results in a flurry of other network traffic. This makes it seem unreasonable to use any protocol that requires a broadcast every 30 sec. By the way, this is not the worst symptom of networks containing a mix of subnet and nonsubnet machines. Now and then somebody brings up a Sun kernel that does not have the subnet patches. If you try to boot a diskless Sun on a network containing a mix of subnet and nonsubnet machines, the entire network comes to a halt for a period of a minute or so. (Actually to be fair, the only machines that come to a halt are other Suns and Celerities. Our Pyramids and DEC-20s seem unaffected.) -------