Thanks to all the answers. The issue was resolved changing on VMware the
NIC type adapters from VMXNET3 to E1000.
It was the recommanded by EmuVM NIC type . I recommand, too :)
Thanks
Gérard Calliet
Le 21/02/2018 à 15:08, Timothe Litt a écrit :
I can't think of anything that would fail if the ROM address is the
same as the DECnet address (which is what you're setting up), but no
real hardware could ever have been configured that way. (It is
possible for software to obtain both, though only one goes on the
wire. One set by software overrides the ROM, which is globally unique.)
The VAX would not normally have a DECnet MAC address when doing a MOP
boot; the MAC address can't be determined until the SYSBOOT parameters
are read.
The normal flow would be that the interface announces its ROM MAC
address via MOP, and uses that address when sending LOAD requests.
The MAC address is changed when the cluster or DECnet driver takes over.
I'm not a VMware user, so they may use different terminology than the
following.
So VMware would need to understand that a MAC address can be changed -
more recent OSs don't set the MAC address, so it could be confused. I
wouldn't be surprised if it acted like a switch & tried to filter
"unneeded" packets.
You do need to make sure that VMware isn't modifying packets - that
is, you want a bridged configuration, not one where VMware is free to
modify packets (e.g. NAT). And that VMware isn't setup to isolate
VMs. "Bridged", "shared LAN", same VLAN - something like that is
what you want.
Also, DECnet uses several protocol types (a field in the ethernet
packet). You will need to make sure that VMware is passing all of
them. It, or some firewall, may block "unknown" protocol types.
DECnet (+MOP+VAXcluster's SCS) may be forgotten or blocked. The basic
DECnet protocol types are in the range 60-00 through 60-09; 80-38
through 80-41 & -48 are used by LAT, DTSS & a few others. Check the
Windows firewalls.
Of course, if you run IP, you also need IP, IPv6, ARP, etc - but I
wouldn't expect VMware to have a problem with them.
On 21-Feb-18 06:21, gérard Calliet wrote:
Hello Jean-Claude,
The MAC address of the emulated VAX machine has the value
AA-00-04-... which will be the result of the calculated DECNET
address, and it is the same address for the VMware NIC used.
Cordialement
Gérard Calliet
Le 21/02/2018 à 12:03, Jean-Claude Parel a écrit :
Hello, gerard
What is the MAC address of the VAX machine emulated by SIMH ? Is it
different from the MAC address of the VMware VM interface used by SIMH ?
Cordialement/Regards
------------------------------------------------------------------------
*Jean-Claude Parel* 21, Chemin De La Sauvegarde
OpenVMS Architect Ecully, 69132
458601 France
Global Business Services
Phone: +33-4-7218-4095
Home: +33-4-7558-3550
Mobile: +33-6.7171.0434
e-mail: jcpa...@fr.ibm.com
From: "gérard Calliet" <gerard.call...@pia-sofer.fr>
To: "simh@trailing-edge.com" <simh@trailing-edge.com>
Date: 21/02/2018 10:58
Subject: [Simh] VMware "internal network" and VAX mop frames
Sent by: "Simh" <simh-boun...@trailing-edge.com>
------------------------------------------------------------------------
Hello,
It's not specifically a simh question, but I hope someone had
experience
about the issue.
I have a VAX VMS on a SIMH on a Windows VMware instance which uses a
dedicated NIC for simh.
I have an OpenVMS on an AlphaVM emulator on another Windows VMware
instance (on the same VMware server) which uses another dedicated NIC
for the emulator.
(The dedicated NIC have no associated protocol (for example ip) ).
I try a network boot from vax vms simh, which could be served by the
emulated OpenVMS alpha emulated. I can see the mop broadcasted
frames on
the wire, outside on the VMware server, but they don't arrive at the
NIC
at the host instance of the alpha emulation.
I think something is filtered out inside the VMware server between its
instances. I don't know more.
Thanks,
Gérard Calliet
---
L'absence de virus dans ce courrier électronique a été vérifiée par
le logiciel antivirus Avast.
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.avast.com_antivirus&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=2AoVEMvcRW1lMiTIMmGiShO4dQKZolvsh1Oz2GpyULA&m=XJN-harnIlfiy6Nm-UhdbwliUFRRucDv2U-bzwbCYRQ&s=nz4R8EpTNJBF6xyv0wErluHvMAyk_Q0r9mG5k-b5P7o&e=
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.trailing-2Dedge.com_mailman_listinfo_simh&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=2AoVEMvcRW1lMiTIMmGiShO4dQKZolvsh1Oz2GpyULA&m=XJN-harnIlfiy6Nm-UhdbwliUFRRucDv2U-bzwbCYRQ&s=fET4HvAPyJKsZTmohu6n7eViPn81g7Dm1g00AnRnZdY&e=
------------------------------------------------------------------------
Avast logo
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
L'absence de virus dans ce courrier électronique a été vérifiée par
le logiciel antivirus Avast.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
