DEC servers and VAX machines on different subnets

[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.