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.

[EdgarZamora_1]

What Hoff said!

No need to use a sledgehammer on your application when a decent network team can set up some network magic on their routers. The problem is getting them to do it.

[Richard Brodie_1]

If your networking team are not all hostile alien entities who can't be reasoned with it might be worth asking them if they can't make a non-geographical VLAN and put all your equipment on it.

[Ian Miller.]

Note bridging LAT can be done but the latency does increase and sometimes that is noticeable to your application.

LAT has some short timeouts.

[Steve Reece_3]

>>>If your networking team are not all hostile alien entities who can't be reasoned with it might be worth asking them if they can't make a non-geographical VLAN and put all your equipment on it.<<<

I've known some places where they are...

[Colin Butcher]

There are a few things to consider here:

"subnets" are a TCP/IP V4 entity at layer 3. They are used to break down a TCP/IP V4 address space into manageable pieces. TCP/IP V4 routing is used at layer 3 to exchange data between subnets. That routing mechanism at layer 3 is TCP/IP specific, so it won't pass data for any protocol other than TCP/IP.

"VLANs" are generally a layer 2 entity, so they function at ethernet packet level (layer 2), not at TCP/IP V4 protocol level (layer 3). Most layer 2 VLANs are port based. Packets moving in the infrastructure between switches and co-operating NICs use 802.1Q tagging to associate ethernet packets with the correct VLAN. Bridging is used at layer 2 to exchange data between VLANs and only some switches allow this - many don't, for a whole bunch of reasons. Ethernet packets carry all sorts of different protocols: TCP/IP, DECnet, LAT, MOP, SCS, etc. All those different protocol types are uniquely identified by information in the ethernet packet header or packet payload. RFC1700 has the list of assigned protocol types.

There isn't necessarily a one-to-one correspondence between a "layer 3 TCP/IP V4 subnet" and a "layer 2 VLAN". It often works out that way because frequently the only way to move data between VLANs is to route the packets in the switch. However, there's nothing to stop you having multiple TCP/IP V4 subnets per VLAN, nor is there anything to stop you having a single layer 3 TCP/IP V4 subnet spanning multiple layer 2 VLANs if you bridge between the VLANs at layer2.

As for the DECservers, it depends which type you have and which firmware they have. The early ones don't have BOOTP support for example.

In a non-TCP/IP environment DECservers use a number of on-the-wire layer 2 protocols:
- LAT for serial IO (including 'reverse LAT' for access to printers etc.).
- MOP for down-line loading (which is every time it boots if the DECserver doesn't have local flashRAM, or which is whenever you update the load image firmware if it doesn't have flashRAM, or perhaps when you swap it out due to failure).
- Remote Console Carrier for access to the internal console. Most people confuse this with MOP, but it's another entirely separate layer 2 protocol. It's what gets used when you do a "SET HOST/MOP or NCP CONNECT ".

Don't forget the second two - they're the ones that most people forget about, then find they can't boot, load or connect remotely to their DECservers after they're moved DECservers to a different VLAN.

In a TCP/IP environment DECservers use several TCP/IP sub-protocols:
- TELNET for serial IO (including TELNETSYM for access to printers)
- BOOTP for down-line loading (every boot or for firmware updates depending whether it has flashRAM)
- LPR/LPD for access to printers (I prefer TELNETSYM myself!)
- TELNET again for access to the internal console. However, think about access to the DECserver when it's not booted and running - you may still need Remote Console Carrier at layer 2 first in order to get to it.

If you're using a DECserver 90M or 900TM then V2.4 onwards works well. It's a bit more fiddly to set up TCP/IP (telnet listener etc.) on the DECserver than to set up LAT. Having a LAT connection at layer 2, along with the Remote Console Carrier at layer 2 is always useful. Don't end up with a VLAN layout that stops you doing this if you can avoid it.

Personally I prefer to segment a LAN infrastructure based on functionality that geographic location within a plant. That requires a bit of care to think through the VLAN design and which NICs connect to which VLANs. That's something else you might want to do - connect multiple NICs from the OpenVMS systems to the network infrastructure, with different NICs running different protocols into different VLANs.

If you want more information, there's a recording of the recent webinar about "Networking with OpenVMS", plus the slides, a Technical Journal article and a bunch of other stuff at http://www.xdelta.co.uk/seminars.

Cheers, Colin (http://www.xdelta.co.uk).

PS: All re-typed from scratch with a text editor after the ITRC system managed to lose everything I typed yesterday. Mutter. Grumble.

[Colin Butcher]

Another bit to think about:

At application level then if you're currently having your applications issue QIOs to LTA devices then you're definitely using LAT and you'll have to change the code to instead make TCP/IP connections to the IP address and TCP/IP port number that corresponds to the DECserver port number once yo've set up the TELNET LISTENER inside the DECserver.

For example, you'd connect to :2002 and typically (by default once you've set TELNET LISTENER up) that will map to DECserver physical port 2. You'll then need to set all the port characteristics inside the DECserver itself on the physical port.

Cheers, Colin.