DEC servers and VAX machines on different subnets

[Kivanc_1]

Our network team plans to divide production areas into different subnets, vlans. This means that DEC servers and VAX OpenVMS servers will NOT be on the same subnet.
For example VAX OpenVMS servers will reside on A.B.C.X network and Assembly Shop DEC servers will be on D.E.F.X subnet (all dec servers ip addresses needs to be changed).
Network team will route dec servers subnet to VAX OpenVMS servers subnet but network communication between VAX OpenVMS servers and DEC servers is not TCP/IP protocol, it is LAT and as i know LAT is non-routable protocol.

Is this network infrastructure applicable ? Is there any infrastructure with this kind of network configuration ?

[Joseph Huber_1]

You correctly noted LAT will no longer work in such a configuration.
But also "(all dec servers ip addresses needs to be changed).", i.e. the decservers are of the newer type supporting TCPIP, so LAT can be replaced by TELNET protocol.
Depending on the specific applications, this can be more or less transparent. If the applications use specific LAT QIOs, then they need change, otherwise "terminal" I/O for both LAT and TELNET are the same.

[Volker Halle]

Kivanc,

if you communicate using the LAT protocol between your OpenVMS VAX systems and the DECservers, those two MUST reside in the same 'LAN segment' or the 'LAN segments' must be bridged together regarding the LAT and MOP (DECserver software load) traffic.

There are DECservers, which also do support the TCPIP stack. If you have those or change to those, you should repalce LAT with TCPIP, but this requires changes in your application !

Volker.

[Joseph Huber_1]

Also booting of the DECservers software needs attention:
If they do not boot from flash memory, but via MOP from the VMS servers, then this has also to be changed to using a different method, namely TFTP. Since the decservers support TCPIP, I also assume they can do TFTP loading. (I only have Lantronix terminal servers, they do TFTP).

[Steve Reece_3]

Kivanc,

It may help if you were to give the model of the DECservers that you're using and that need to reside on a different subnet. Different models have different features and can have different options (A DECserver 700 can have a flash card installed and (IIRC) can use TFTP or BOOTP to downline load their image, for example.)

Steve

[Kivanc_1]

We have 90M+ dec servers

[Volker Halle]

Kivanc,

DECserver 90M+ should support TCPIP for load via BOOTP/TFTP and for communication with the OpenVMS VAX systems.

You now have to research, whether and how you could change your use of the LTA devices and see, if you can change your applications to use TELNET (TNA devices) to talk to the DECservers.

Volker.

[Thomas Ritter]

We have a similar problem years ago. All of our systems have a common network somewhat live a common bus. We call it the backend network and the front end networks exits for all external to host communications. You really want to avoid dealing with corporate managed networks controlling key aspect of the way your cluster functions.

For example, our four node cluster has two nodes at each site with a seperate front end networks or vlans. The bankend is common to all hosts.

Some advice. Licensing on some cisco model switches prevents even non-routable protocols from passing requests to joined switches. This is where one has two physical swithces joined using say an ethernet port.

[EdgarZamora_1]

If you wish to continue using LAT ask your network team to look into setting up IP helpers. We did this successfully until we finally got rid of our DECserver 700s a year or so ago.

[Hoff]

While it is true that LAT is non-routable, that's actually not strictly true in modern network stacks with modern network switches, and most any experienced networking team should know how to route (bridge) LAT and other protocols over IP. LAT, SCS and other protocols are regularly bridged over IP. When correctly implemented, bridging is transparent.

And FWIW, the terminal server protocol migration discussed in previous topics is quite correct but also has one big caveat I've not seen mentioned: your software might not work without some updates, as there are low-level differences between LAT and its APIs and telnet and IP and its APIs. Given you're working in a factory floor, it's reasonably likely that you have this code and (having implemented factory floor code, and having done LAT and IP networking and migrations) IP is not necessarily a drop-in replacement for LAT.