Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!eos!labrea!agate!saturn!eshop
From: eshop@saturn.ucsc.edu (Jim Warner)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Ethernet Overload Problem
Message-ID: <2690@saturn.ucsc.edu>
Date: 6 Apr 88 16:46:32 GMT
References: <3736@dasys1.UUCP>
Reply-To: eshop@saturn.ucsc.edu (Jim Warner)
Organization: University of California, Santa Cruz
Lines: 23
Keywords: Ethernet, packet overload, Unix

You problem was described in a message from Tom Ferrin at UCSF:

+The ARP code for negotiating the use of trailers with another host
+is broken.  If the remote host cannot understand trailers, the
+algorithm can get stuck in a loop continually exchanging ARP_REPLY
+packets with the remote host.  This floods the ethernet with LOTS
+of packets for several minutes until the algorithm gives up trying.

+The scenario is as follows: 1) the local host tries to resolve a
+ethernet address that is not in it's arp table by sending out a
+ARPOP_REQUEST packet; 2) the remote host sends a ARPOP_REPLY with
+the ETHERTYPE_IP protocol field set indicating that it does
+not wish to receive trailers; 3) local host sends a ARPOP_REPLY
+announcing that it does wish to receive trailers; 4) remote host
+sends another ETHERTYPE_IP reply indicating it does not wish to
+send trailers either.  This reply is indistinguishable from #2
+above and the whole cycle repeats.

Tom goes on to describe mods to VAX unix to break the cycle.  
Revised code is now available, however, from E&S that fixes the
problem on the PS3xx end.  That is probably the preferable solution.
Contact E&S for an upgrade.

jim