[HECnet] Same MAC address on different nodes

[Mark Pizzolato - Info Comm]

On Sunday, May 25, 2014 at 10:14 AM, Johnny Billquist wrote:
On 2014-05-25 19:04, Hans Vlems wrote:
Huh? With ethernet, communication with adjacent nodes works without
involving any routers anyway. And if you need to talk with anything beyond,
you're going to go through the router on the way there anyway.
Really, unless you actually have several interfaces, there is no gain in running
a router compared to an endnode. However, running a router definitely use
up more resources, which is a disadvantage.

Anyway, i'd stop using the same 08-00-2B address on two nodes, shutdown
the simulators the VM host and the real iron.

Would still not make any difference, which I have pointed out several times
now, and also what Jean-Yves have been observing the last two days.

Really. There is no black magic here. I can explain every bit of it if someone
needs more convincing.

Essentially, the MAC address in the actual ethernet controller (or the MAC
address set before boot in simh) is irrelevant. Once DECnet starts running,
that MAC address is not used anymore. It is just a trivia piece of information
so that you can know what the hardware MAC address from the factory is. It
is not used by anything, especially not anything related to network
communication.

The VM host in turn cares even less, since whatever MAC address simh plays
around with is fully local to simh, and does not affect the VM host.

Any questions?

Actually depending on the timing, having multiple nodes on the same LAN with the same hardware MAC address WILL cause an error in a simh configuration.   

A little background here is appropriate:

VMS (and presumably other DECnet capable DEC Operating Systems) have logic in the network device driver which attempts to assure that no other node on the LAN has the same MAC address whenever an application or protocol stack attempts to set the Physical Address on the network card.   The validation step uses the Loopback protocol to send a packet to (and from) the MAC address which the software is trying to set the Physical Address to and if a response is actually received, the attempt to set the Physical Address is rejected.   This is intended to detect duplicate DECnet addresses on a LAN segment.

The process of sending loopback packets like this (and correctly getting answers when the problems they are designed to detect were there) caused some interesting structural design issues in the sim_ether layer way back when the XQ device was first being developed.

As it turns out, the process described above was designed BEFORE learning bridges and other switches which are fundamentally part of networks today were in use.   The initial simh Ethernet device implementations reflected the hardware behavior.   The hardware behavior first set the Physical MAC address to the new value and then sent the loopback packet, but on switched networks this didn't actually detect the problem it was originally designed to detect.   The detection problem is due to the fact that learning bridges AND most switches running some form of spanning tree protocol generally don't forward the first packet they see from a particular address.   They may not forward packets from a particular address for a good number of seconds while they potentially learn about changing topologies.   The 'right' approach to implement this test would be for the loopback packet to be sent from the current Physical MAC address BEFORE it is changed.   This approach works on learning networks (presuming that the current Physical MAC address had already been learned on that LAN due to other traffic).

The current simulated approach to this problem does several things: 1) it detects the send to self loopback attempt and before actually transmitting anything changes the source address of the loopback packet to be the current physical address of the host system's lan interface.   2) it temporarily enables capture of a potential loopback response to the host system's MAC address in the pcap filter in effect. 3) it then sends the packet.   If a response is received, it is reformatted to look like what the original hardware response would have been if a duplicate MAC address had been found and then passes that up into the simulated system.

This approach effectively detects duplicate DECnet addresses on today's LANs.

As I mentioned above, the VMS driver actually performs this loopback test ANY time the Physical MAC address is changed, not just by DECnet or cluster software.   The original logic in sim_ether only had examples with DECnet addresses so it the tests to detect this presumed DECnet format MAC addresses.   Once I realized that a complete solution involved any address, I generalized the check.   After I generalized the check, I realized that DECnet Phase V systems don't change their LAN interface MAC addresses.   Given the potential of multiple simulated systems existing on the same LAN with potentially conflicting MAC addresses, I leveraged the already existing logic to verify that the Hardware MAC address wasn't already in use on the LAN by executing the above mentioned loopback test when a simh LAN device is attached to a network segment.

So, if you've got 2 simh VAX systems on the same LAN segment and you don't change the MAC address of the LAN interface:

System 1:
      sim> show xq
      XQ           address=20001920-2000192F, no vector, MAC=08:00:2B:AA:BB:CC
                      type=DELQA-T, mode=DELQA, polling=disabled, sanity=OFF
                      DEQNALock=OFF, leds=(ON,ON,ON)
                      not attached
      sim> attach xq eth0
      WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008)
      Eth: opened OS device \Device\NPF_{A6F81789-B849-4220-B09B-19760D401A38}
      sim>

System 2:
      sim> show xq
      XQ           address=20001920-2000192F, no vector, MAC=08:00:2B:AA:BB:CC
                      type=DELQA-T, mode=DELQA, polling=disabled, sanity=OFF
                      DEQNALock=OFF, leds=(ON,ON,ON)
                      not attached       sim> attach xq eth0
      WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008)
      Eth: opened OS device \Device\NPF_{A6F81789-B849-4220-B09B-19760D401A38}
      XQ: MAC Address Conflict on LAN for address 08:00:2B:AA:BB:CC, change the MAC address to a unique value
      Eth: closed \Device\NPF_{A6F81789-B849-4220-B09B-19760D401A38}
      Unit not attachable
      sim>

This functionality exists for all LAN devices on the supported simulators (XQ and XU in the Qbus and VAX family simulators) in the latest simh codebase.

Depending on the timing of various actions, the above collision wouldn't be detected if one of the nodes is running a network stack which changes the physical address.   It will then be up to the simulated OS to potentially detect address collisions.

- Mark