Path: utzoo!mnetor!uunet!lll-winken!lll-crg.llnl.gov!casey From: casey@lll-crg.llnl.gov (Casey Leedom) Newsgroups: comp.dcom.lans Subject: Re: Latest news on our ether errors Message-ID: <4126@lll-winken.llnl.gov> Date: 23 Feb 88 22:10:51 GMT References: <8403@g.ms.uky.edu> <4097@lll-winken.llnl.gov> Sender: usenet@lll-winken.llnl.gov Reply-To: casey@lll-crg.llnl.gov.UUCP (Casey Leedom) Organization: Lawrence Livermore National Laboratory Lines: 30 Keywords: ARP broadcasts, 4.2BSD networking, x.x.255.255 broadcast packets Summary: Why x.x.255.255 packets cause ARP broadcasts from 4.2BSD networking I got the following reply to my question about why packets addressed to xxx.xxx.255.255 cause broadcast storms from 4.2BSD based networking implementations. Casey ----- Date: Tue, 23 Feb 88 07:25:13 PST From: Jim Warner In article <4097@lll-winken.llnl.gov> you write: > For my own and others' edification would someone explain exactly why > 4.2BSD based networking responds with gratuitous ARPs for packets > addressed to xxx.xxx.255.255, etc.? Thanks in advance. These packets were sent as ethernet broadcasts. They were received at the 4.2BSD hosts. When the IP layer opens the packet and looks at the destination address, it sees that the packet is not addressed to this host. It also does not recognize the 255.255 as being the IP broadcast address. It concludes (falsely) that there is a real host at address 255.255 which should have received this misdelivered packet. The host would like to deliver this packet to its proper destination. To do that, the host will need the ethernet address of the destination. An Address Resolution (ARP) request is issued. But there is no host at this IP address and there is no response. The ARP request is therefore repeated by each 4.2BSD machine once for misunderstood ethernet broadcast. Hope that answers your question. Jim Warner