Path: utzoo!attcan!uunet!wuarchive!sdd.hp.com!decwrl!sgi!vjs@rhyolite.wpd.sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Reply to Re: Ethernet Address Uniqueness...
Summary: not a problem
Message-ID: <72094@sgi.sgi.com>
Date: 13 Oct 90 21:18:16 GMT
References: <9010092346.AA29384@ftp.com>
Sender: guest@sgi.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 24

In article <9010092346.AA29384@ftp.com>, jbvb@FTP.COM (James B. Van Bokkelen) writes:
> This is a standard gotcha of using protocols that change the address.
> There is no solution other than to make sure that DECNet is always
> started before anything else that cares about the Ethernet address.


I do not see the problem.  When our DECNET stuff changes the MAC address as
it starts, it tells the ethernet driver to call arpwhohas() again, just
as if the driver were starting from scratch.  The result is that the rest
of the IP network sees nothing stranger than if you had quickly taken your
system down, switched ethernet cards, and rebooted.  The general mechanism
can be encapsulated in an ioctl() so that all media can be wishywashy
about MAC addresses.  Changing ethernet MAC addresses using this ioctl()
works just fine on our systems.  I can't imagine anyone doing less
(for DECNET if not the ioctl()), so I'm sure Sun, DEC, and the other UNIX
DECNET vendors do the same or better.

It is true that bad things happen if you try to start DECNET on two
different boxes with the same node and area numbers, or otherwise try to
share a single MAC address with more than one machine.  However, this is
not much worse than assigning a single IP address to more than host.


Vernon Schryver,   vjs@sgi.com