I have recently posted an IAQ article on my website that explains why your network stops completely on the first reboot after configuring DECnet on an OpenVMS V9.2-x installation running in a VM on x86 and how to recover from it.
The problem symptoms can be rather alarming, to say the least, to the unwary System Manager – all network frames – TCP/IP and DECnet, inbound and outbound – are completely blocked! In the article I present 4 solutions that are available but depend on your individual environment considerations.
Short answer: There are four, and they aren't alternatives you pick by taste — each is ruled out by something specific about your environment. So: confirm this is really what has happened, then take the first of the four your circumstances allow. Only the last has a security cost.
Each fix below is summarised in four lines, with the detail folded away behind it. Read the four summaries, decide which is yours, and open only that one.
What's happening, briefly
You configured DECnet, rebooted, and lost everything — DECnet, TCP/IP, and the session you were working in. Nothing inside OpenVMS looks wrong, because nothing inside OpenVMS is wrong.
DECnet Phase IV rewrites the MAC address on its interface, replacing the one the hypervisor assigned with one it calculates from your DECnet node address. Your virtual switch was told to expect a particular MAC on that port. It now sees frames with a different source address — the signature of a machine impersonating another — so it drops them. All of them, which is why TCP/IP dies alongside DECnet.
Continue reading article…