SIMH re-vamp

Tonight I turned my thoughts to SIMH, after the usual random internet surfing including an excellent article on winter cycling from Dabeaz [python guru]). I’ve spent the last six months getting fit, primarily by riding a road and mountain bike, and have the same issues he does keeping warm, albeit a typically less-continentally extreme form of winter. I have ridden through snow at the top of Kirkstone Pass once this year so far and don’t expect it to be the last. Once I’ve got the frozen feet situation sorted I should be a lot more comfortable.

HP Microserver

Anyway, back on subject. ever since I upgraded my HP Microserver to Ubuntu 14.04 (or another event that purely coincidentally was at the same time and that I don’t remember) I’ve had issues with my SIMH VAX emulator.

This emulator normally serves my hecnet info page and VMS related software archive. It is still functioning in this capacity. However, it also connects via DECnet to other computers in a worldwide DECnet network, called unsurprisingly hecnet. The connection between nodes in the DECnet network is made using a piece of software that acts as a bridge between defined nodes in the network. Unfortunately since the Ubuntu upgrade my current network configuration for the SIMH instance has not worked correctly. I experience dropouts where adjacencies between the SIMH instance and other router nodes are continuously dropped and reconnected. I’ve done all sorts of diagnosis together with the owner of the other node but to no avail. Nothing looks wrong but clearly there is something not right. It appears to be related to the SIMH networking configuration rather than the bridge configuration.

So having tried every combination of configuration for the current setup I’ve decided to reconfigure the simulator to use tap network interfaces. The HP Microserver has two network cards and previously I’ve had a simple configuration using libpcap to use the second network card exclusively for the SIMH instance. I’m going to reconfigure network to use tap interfaces and bridge on that second card – an extra level of complexity not strictly necessary but worth a try.

The first serious hurdle was to remember that the VAX/VMS Decnet Phase IV configuration required that the machine was set up to be an Area Router IV. I noted that when I had a real AlphaServer 1000A running that took over area routing tasks and everything seemed to hang together nicely – no drops in adjacency.

Unfortunately having swapped to tap-based interfaces and reconfigured VMS I was still in the same boat – periodic adjacency dropouts.