Re: Mysterious ARP behavior on a tcp-ip ethernet


Charles Hedrick (HEDRICK@RED.RUTGERS.EDU)
1 Aug 86 01:24:02 EDT


It is fairly common to get large-scale ARP'ing when there are confusions
on your network about hosts. In general, I agree with Jeff Mogul.
However this is common enough that I'd like to add a bit of detail. I
also have some suggestions to allow you to improve things without
getting every vendor to fix their implementation immediately.

First, let's get clear about what is happening. One of your hosts is
sending a broadcast. Since your network number is apparently
192.12.120, it is using 192.12.120.255. This is the new standard: To
make a broadcast address, stick all ones in the host field. (255 is all
ones.) Unfortunately, you have hosts on your network that believe that a
broadcast address should be made by sticking a zero in the host field,
i.e. 192.12.120.0. When they see the packet addressed to
192.12.120.255, they think you are trying to address some specific host
with that address. Since they are not that host, they decide to be nice
and forward the packet to the host. In order to forward the packet,
they need the Ethernet address of 192.12.120.255. Thus they issue an
ARP request for it. The entry in the ARP table marked with ? means that
they have issued an ARP request but not yet gotten a response.

In my opinion, the simplest solution is to continue using the old
convention on all machines until the new convention has been implemented
everywhere. As Jeff points out, new implementations are being designed
to accept either. Most new implementations allow you to set the
broadcast address that they will emit. So my suggestion is that you try
to get up to date implementations as soon as possible, but until you do,
set all the new implementations to use 192.12.120.0 as their broadcast
address. Once everything is updated, then change over to using the new
convention on all your machines.

There is one more point. It is really a mistake for normal machines to
forward packets that are intended for other machines. This is happening
because almost every IP implementation has the potential for acting as a
gateway between two networks. Such a gateway is expected to forward
packets from one network to the other. Most of the code simply checks
to see whether the packet is for it, and if not, sends it on to the
destination. This isn't a terribly clever approach, and real gateways
are generally more careful. But when your machines isn't acting as a
gateway, forwarding packets at all is a bad idea. It can gain nothing,
and when confusion occurs, things like you observed happen. Most
implementations allow you to disable this forwarding. In 4.2, you
simply set a variable ipforwarding to 0. This can be done in adb even
if you don't have source. Even this isn't ideal, because your machine
will send an error message back to the source of the packet telling it
that the packet couldn't be delivered. We disable forwarding more
drastically. In routine ip_forward, we simply discard the packet.
(There is a test at the beginning of the routine checking whther the
packet is a broadcast. If so, it is thrown away. Just make that test
always succeeed.) But even if you don't do this, turning off
ipforwarding will be a big help. Every time the system sees a stray
packet, it will send back an error to the sender, rather than issuing an
ARP. An ARP is a broadcast, so it clogs up everybody. The error will
just clog up the guy who is causing the problem.

Note, by the way, that the Applitek bridge in effect turns the whole
set of Ethernets that it connects into a single logical Ethernet.
Depending upon how you have allocated Internet addresses, you may hve
to make sure that every host on every Ethernet connected via the
Applitek system is doing things consistently.
-------



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