Subject: Re: Reimplementing broadcast check for ARP
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: mark <mds@gbnet.net>
List: tech-net
Date: 10/02/1997 14:33:39
Would this be an Auspex?
It sounds like their ServerGuard feature and I think may be a special
case in that they have very great control over their network interfaces
at all levels and can do practically anything they want with them.
On Thu 2 Oct, 1997, der Mouse <mouse@Rodents.Montreal.QC.CA> wrote:
> > When building the new ARP system, I left commented out the test that
> > the reported linklevel address is not the broadcast address).
>
> > Problem was that the new ARP system can't know, per se, what the
> > broadcast address IS.
>
> This is also assuming that the broadcast cannot be legitimately used in
> an arp reply. I'm not sure whether I think this is true or not. BUT:
>
> > However, even multicast addresses should be inappropriate for ARP
> > entries:
>
> This is definitely false. I know of at least one system where it is
> crucial that a client accept a multicast Ether address in a ARP reply.
> (It's a redundant server system, with two or more machines which decide
> among themselves who will answer requests; when one dies, the rest
> decide who will take over - the reason it's transparent to clients is
> precisely that it works by answering arps for the server IP address
> with a multicast Ethernet address, one that all the servers set
> themselves to receive.)
>
> der Mouse
>
> mouse@rodents.montreal.qc.ca
> 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B