more oddities from the swamp


Charles Hedrick (HEDRICK@RED.RUTGERS.EDU)
21 May 86 01:57:05 EDT


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.)

-------



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:33 GMT