ehrlich@shire.cs.psu.edu (Daniel R. Ehrlich) (04/27/89)
Hans van Staveren <cs.vu.nl!sater@rutgers.uucp> writes: >Contrary to every law in the Ethernet world Sun has decided to give >both boards the same Ethernet address. Although this is illegal I have >not been able yet to think of a scenario where this would lead to problems. Try this one. We have a single coax on which we run two different class B networks, 128.118 and 130.203. As far as I know this is perfectly OK. Here is were the trouble starts. Assume I have a Sun with three ethernet interfaces that I would like to use as a gateway between the two class B nets (remember these are both on the same physical wire) and a third class B net. Common sense would seem to indicate that I could connect two interfaces to the same coax as long as they had different IP network numbers (possibly even the same network number if subnetting is used). >From the way I understand the ARP protocol to work, it expects a UNIQUE mapping between IP addresses and Ethernet physical addresses. Well, with Sun setting all three interfaces to the same Ethernet address this assumption is not valid. Next, some other machine on the net issues an ARP broadcast for one the the IP addresses. Someone answers with an Ethernet address. The requesting machine stuffs this into the destination address of the Ethernet packet and shoves the packet out onto the wire. Things should get interesting here. As there are two interfaces listening for the same Ethernet physical address, both should recieve the packet. They both try to process it. I haven't taken the time yet to peruse the code but I do not believe that this would do good things inside the kernel. Can someone at Sun address this? I spoke with someone from the hotline (it only took ten days) <pravin@sun.com> and he was sort of in agreement that this scenario may not work. >If anyone can think of one we can have them sued or so :-) Unfortunately it isn't clear from reading "The Ethernet - A Local Area Network Data Link Layer and Physical Layer Specifications, Version 2.0, Nov 1982" if setting all interfaces to the same address is a violation of the specification. The specification speaks (in section 6.2.1) of a `station' having a uniquie 48 bit Ethernet address. The glossary in Appendix A defines a `station' as: "A single addressable site on the Ethernet, generally implemented as a computer and appropriate peripherals, and connected to the Ethernet via a controller and a tranciever." Appendix A defines a `controller' as: "The implementation unit which connects a station to the Ethernet, typically comprising part of the Physical Layer, much or all of the Data Link Layer, and appropriate electronics for interfacing the station." But, also in Appendix A is the following definition of a `physical address': "The unique address value associated with a given station on the network. An Ethernet physical address is defined to be distinct from all other physical addresses on all Ethernets." So it is not at all clear that what Sun is doing violates the letter of the specification. It appears to me that they are violating the spirit of the specification though. Dan Ehrlich <ehrlich@shire.cs.psu.edu> The Pennsylvania State University Department of Computer Science University Park, PA 16802
steve@uunet.uu.net (Steve Nuchia) (05/08/89)
ehrlich@shire.cs.psu.edu (Daniel R. Ehrlich) writes: >Try this one. We have a single coax on which we run two different class B >networks, 128.118 and 130.203. As far as I know this is perfectly OK. >Here is were the trouble starts. Assume I have a Sun with three ethernet >interfaces that I would like to use as a gateway between the two class B >nets (remember these are both on the same physical wire) and a third class There is an undocumented ifconfig option that overrides the ethernet address of the interface. Sun uses this in their Sunlink DNI (DECnet compatiblity software) product. My guess is you can use it to make the boards have whatever address you want. Choosing a good address is left as an excersize. :-) The only documentation I've seen is in the installation scripts for DNI, and all that stuff is at a client site that I can't get to anytime soon, but the hint should help. Suggest you get your Sun contact to dig up the details for you. Another thing to check is to see if you can find where they are setting the addresses. I'd guess that the boards have unique addresses burned into them and they are having the default address loaded into them in one of the boot scripts. Steve Nuchia South Coast Computing Services uunet!nuchat!steve POB 890952 Houston, Texas 77289 (713) 964 2462 Consultation & Systems, Support for PD Software.
stpeters@dawn.crd.ge.com (05/09/89)
<cs.vu.nl!sater@rutgers.uucp> writes:
Contrary to every law in the Ethernet world Sun has decided to give
both boards the same Ethernet address.
<ehrlich@shire.cs.psu.edu> comments:
Here is were the trouble starts. Assume I have a Sun with three ethernet
interfaces that I would like to use as a gateway between the two class B
nets ... [description of expected dire consequences]
Ethernet boards with hard-wired Enet addresses went out of fashion long
ago. Modern Enet interfaces are software configurable. The default
Ethernet address assigned to a Sun is stored in a PROM on the cpu board,
and the Enet interface is configured to that address at boot time. (This
lets you change Enet interface boards without losing your Enet address.)
For when you have more than one board, ifconfig lets you configure
them to different Enet addresses:
/etc/ifconfig ie0 8:0:20:1:9b:3a ...
/etc/ifconfig ie1 8:0:20:1:9b:3b ...
Obviously, a gateway also has to have a different IP address on each IP
network. Further, it has to have a different hostname (a hostname is just
a symbolic IP address). Assign each interface its IP address with
ifconfig.
It helps to use related hostnames, so people can recognize that they refer
to the same machine.
--
Dick St.Peters
GE Corporate R&D, Schenectady, NY
stpeters@dawn.crd.ge.com
uunet!steinmetz!dawn!stpeters
GE would charge for opinions if it could find any. These are mine.