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