fillmore@emrcan.BITNET (10/10/90)
In my recent message about DECNET Ethernet address non-uniqueness I should have mentioned that my site works in a mixed DECNET - TCP/IP environment (plus Appletalk, etc.). Problems arise in VAXes which run both DECNET and TCP/IP on the same Ethernet interface - the Ethernet address used in ARP responses depends on whether DECNET was started before or after TCP/IP, because DECNET changes the Ethernet address in the interface hardware (in RAM memory). If the TCP/IP software uses the modified DECNET Ethernet address then there might be address duplication because IP addresses are connection oriented, not node oriented. ________________________ Bob Fillmore, Systems Software & Communications BITNET: FILLMORE@EMRCAN Computer Services Centre, BIX: bfillmore Energy, Mines, & Resources Canada Voice: (613) 992-2832 588 Booth St., Ottawa, Ontario, Canada K1A 0E4 FAX: (613) 996-2953
jbvb@FTP.COM (James B. Van Bokkelen) (10/10/90)
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. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (10/14/90)
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
oberman@rogue.llnl.gov (10/16/90)
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. This is getting a bit far afield from tcp-ip, but the above is not quite true. By setting the SYSGEN value for SCSSYSTEMID to the value ((DECnet area*1024) + node), the order in which products are started in no longer significant as the MAC address of the Ethernet cards is rewritten before any layered software is run. 48.168 would yield an SCSSYSTEMID of 49320, (48*1024)+168. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything.