LAT query

[Rich Jordan]

Running into a novel (for me) LAT issue. We have a site with a DS20 and a DECserver 708 with current software. LAT is used for a couple of faxmodem connections and one management terminal that still connects that way.

We are putting an emulator in to replace the alpha. The machine was setup offline, IP and DECNet address changed but we missed adding a service name parameter to the LAT startup so when it initially booted on the customer network, it also presented the same LAT service name as the actual Alpha. That was quickly corrected, the emulator rebooted, and the emulator now has its separate LT service name. The emulator and the alpha are on the same subnet/VLAN/switch with no filtering or load balancing or other possible known problem causers.

Now the DECserver keeps 'losing' the alpha and the emulator as services it will connect to. Only one of them shows up as an available service at a time, either 'alpha' or 'emu'. You cannot connect to 'alpha' when the DECserver sees 'emu' and vice versa. The services on both machines appear to be running normally. One day (or for several hours) one will be available, then for reasons unknown it switches to the other.

We can bounce the decserver if that is likely to help, but I don't recall ever seeing behavior like this before, albeit with older DECservers than the 708. Any ideas?

Thanks

[abrsvc]

The first thing that I would suspect is the service names. Are they unique within say the first 6-8 characters? Perhaps there is a limit on the "internal" naming that may come into play here? Try having the service names look like this: Alpha and LTAlpha.

I don't recall exactly when as it was many years ago, but there were naming conflicts when the service names were extremely close. This may have been with field test hardware too as I was involved in pre-announcement testing at the time.

Dan

[Volker Halle]

Rich,

the DECserver learns about the LAT services being offered from Multicast messages sent by the LAT server nodes and builds it internal table of known/available services. Maybe it got confused, because the service 'alpha' had been seen with 2 different MAC addresses and now the service 'emu' is seen with the same MAC address as one of the previous nodes offering LAT service 'alpha'.

Try to look at the services known to the DECserver: SHOW SERVICES ALL STATUS

Or try to reboot the DECserver.

Volker.

[[e-mail]]

Running into a novel (for me) LAT issue. We have a site with a DS20 and a DECserver 708 with current software. LAT is used for a couple of faxmodem connections and one management terminal that still connects that way.
We are putting an emulator in to replace the alpha. The machine was setup offline, IP and DECNet address changed but we missed adding a service name parameter to the LAT startup so when it initially booted on the customer network, it also presented the same LAT service name as the actual Alpha. That was quickly corrected, the emulator rebooted, and the emulator now has its separate LT service name. The emulator and the alpha are on the same subnet/VLAN/switch with no filtering or load balancing or other possible known problem causers.
Now the DECserver keeps 'losing' the alpha and the emulator as services it will connect to. Only one of them shows up as an available service at a time, either 'alpha' or 'emu'. You cannot connect to 'alpha' when the DECserver sees 'emu' and vice versa. The services on both machines appear to be running normally. One day (or for several hours) one will be available, then for reasons unknown it switches to the other.
We can bounce the decserver if that is likely to help, but I don't recall ever seeing behavior like this before, albeit with older DECservers than the 708. Any ideas?
Thanks

Rich,

LAT uses MAC addresses. DECnet resets the MAC address to a calculation based upon the DECnet node ID.

Etherpeek can be used to verify, but I suspect that your DECservers have effectively poisoned ARP caches.

Rebooting the servers will the ARP caches.

- Bob Gezelter, http://www.rlgsc.com

[Volker Halle]

Rich,

I don't have any DECservers to try, but LATCP on OpenVMS reports the remote node's MAC address and service name(s) as the result of the command: SHOW NODE nodename

Maybe worth a try...

Volker.

[Volker Halle]

Rich,

you didn't change the NODE name on the OpenVMS system running on the emulator ?

If not, you now have 2 nodes (named ALPHA) with the same name, which offer 2 different services 'alpha' and 'emu'.
Check with SHOW SERVICE alpha and SHOW SERVICE emu on the DECserver.

If the DECserver connects to the 'node' asking for a specific 'service', it may fail to find the service, as it's not available on that node. LAT service announcements are sent from those 2 nodes every 'multicast timer' seconds (default: 60), so they may - over time - appear in different order on the DECserver.

Volker.

[Volker Halle]

Rich,

this is an example from an IRIS trace of a LAT service announcement (advertisement) message (from 11-DEC-2000) :

** Summary for frame 13 **

13 +1s LAT_Svc_Adv <-AA0004007FC9 LAT Adver Node=TINTTI Srv=TINTTI
DLL DIX PType=60-04

** Detail for frame 13 **LAT:
LAT: - - - - - Local Area Transport - - - - -
LAT:
LAT: Message type / flags = 28
LAT: 001010.. = Adver
LAT: ......0. = From host
LAT: .......0 = No response requested
LAT: Server circuit timer (10ms) = 8
LAT: High protocol version = 5
LAT: Low protocol version = 5
LAT: Current protocol version = 5
LAT: Current protocol ECO = 3
LAT: Message incarnation = 147
LAT: Change flags = 255
LAT: .......1 = Node group codes have changed
LAT: ......1. = Node descriptor has changed
LAT: .....1.. = Service names and/or number of name has changed
LAT: ....1... = Service ratings have changed
LAT: ...1.... = Service descriptors have changed
LAT: ..1..... = Service classes have changed
LAT: 1....... = Other parameters have changed
LAT: Maximum message size = 1500
LAT: Multicast timer = 60
LAT: Node status = 2
LAT: .......0 = Node is accepting new sessions
LAT: Number of group code bytes = 1
LAT: 0 1 2 3 4
LAT: 01234567890123456789012345678901234567890123456789
LAT: 0 X-------
LAT: Node name = TINTTI
LAT: Node description = DEC 3000 VMS V7.1 (ALa)
LAT: Number of services = 1
LAT:
LAT: - - - - Service 1 of 1 - - - -
LAT: Service rating = 63
LAT: Service name = TINTTI
LAT: Service description = DEC 3000 VMS V7.1 (ALa)
LAT:
LAT: Number of service classes supp = 1
LAT: Supported service class = 1


You see that the node name appears first in that protocol message and then the service name. So the DECserver will store the node name together with the src node mac address together with the service name. When asked to connect to that service, it will connect to the NODE, then ask for the SERVICE.

Problem explained ?

Volker.

[Volker Halle]

Rich,

so rebooting the DECserver will most likely NOT help in this situation.

In a traditionally configured OpenVMS/DECnet/LAT network, you don't expect to find 2 nodes with the same nodename (SCSNODE). Cloning systems and actively connecting them to the same network is not without problems - and you've seen and fixed some of them.

Volker.

[[e-mail]]

Running into a novel (for me) LAT issue. We have a site with a DS20 and a DECserver 708 with current software. LAT is used for a couple of faxmodem connections and one management terminal that still connects that way.
We are putting an emulator in to replace the alpha. The machine was setup offline, IP and DECNet address changed but we missed adding a service name parameter to the LAT startup so when it initially booted on the customer network, it also presented the same LAT service name as the actual Alpha. That was quickly corrected, the emulator rebooted, and the emulator now has its separate LT service name. The emulator and the alpha are on the same subnet/VLAN/switch with no filtering or load balancing or other possible known problem causers.
Now the DECserver keeps 'losing' the alpha and the emulator as services it will connect to. Only one of them shows up as an available service at a time, either 'alpha' or 'emu'. You cannot connect to 'alpha' when the DECserver sees 'emu' and vice versa. The services on both machines appear to be running normally. One day (or for several hours) one will be available, then for reasons unknown it switches to the other.
We can bounce the decserver if that is likely to help, but I don't recall ever seeing behavior like this before, albeit with older DECservers than the 708. Any ideas?
Thanks

Rich,

There are two distinct issues here:

- MAC Addresses of DECnet nodes are based upon the DECnet node number. Two different machines cannot have the same DECnet address on the same network. Doing otherwise will be confusing. Also ARP will not work correctly if two machines on the same Ethernet have identical MAC addresses.

- LAT service names default to being based on the SCS Nodename. One can change this in two ways:
o If the DECnet configuration is correct, and both machines have different MAC Addresses, DECnet/SCS nodenames, then the automatic mechanisms will work as intended.
o If nodename does not work, one can modify SYS$MANAGER:LAT$SYSTARTUP.COM as appropriate.

- Bob Gezelter, http://www.rlgsc.com

[Volker Halle]

Rich,

looks like you can define the LAT host node name as a parameter in LATCP> SET NODE [node-name], it will default to SYS$NODE (which typically matches SCSNODE).

$ @SYS$STARTUP:LAT$SYSTARTUP "EMU" "EMUNODE" "..."

Should use 'EMUNODE' as the LAT host node name and 'EMU' as the service name. This should provide a workaround for your problem.

Volker.

[Hans Bachner]

Rich,

Post by Rich Jordan
Running into a novel (for me) LAT issue. We have a site with a DS20 and a DECserver 708 with current software. LAT is used for a couple of faxmodem connections and one management terminal that still connects that way.
We are putting an emulator in to replace the alpha. The machine was setup offline, IP and DECNet address changed but we missed adding a service name parameter to the LAT startup so when it initially booted on the customer network, it also presented the same LAT service name as the actual Alpha. That was quickly corrected, the emulator rebooted, and the emulator now has its separate LT service name. The emulator and the alpha are on the same subnet/VLAN/switch with no filtering or load balancing or other possible known problem causers.

Did you configure the emulator to use the same MAC address as the
physical DS20? This must be avoided if they are in the same LAN
(specifically: same broadcast domain). Different DECnet addresses
should/might hide this problem, but it's better to avoid that in the
first place.

Post by Rich Jordan
Now the DECserver keeps 'losing' the alpha and the emulator as services it will connect to. Only one of them shows up as an available service at a time, either 'alpha' or 'emu'. You cannot connect to 'alpha' when the DECserver sees 'emu' and vice versa. The services on both machines appear to be running normally. One day (or for several hours) one will be available, then for reasons unknown it switches to the other.
We can bounce the decserver if that is likely to help, but I don't recall ever seeing behavior like this before, albeit with older DECservers than the 708. Any ideas?
Thanks

Make sure LAT is started after DECnet during system startup. On the
running system, stop LAT ($ MC LATCP SET NODE /STATE=OFF if LAT is not
actively used by some process) and restart it with
$ @SYS$STARTUP:LAT$STARTUP

If this does not help, please post the results of the following commands:

- on both physical and emulated Alpha:
$ MC LATCP SHOW NODE
$ MC LATCP SHOW SERVICE <service-offered-by-this-node>
$ MC LATCP SHOW LINK /FULL

- on the DECserver:
Local> show node <ds20>
Local> show service <service-on-ds20>
Local> show node <emulated>
Local> show service <service-on-emulated>

Thanks regards,
Hans.

[Hans Bachner]

Post by Hans Bachner
Rich,

Running into a novel (for me) LAT issue.  We have a site with a DS20
and a DECserver 708 with current software.  LAT is used for a couple
of faxmodem connections and one management terminal that still
connects that way.
We are putting an emulator in to replace the alpha.  The machine was
setup offline, IP and DECNet address changed but we missed adding a
service name parameter to the LAT startup so when it initially booted
on the customer network, it also presented the same LAT service name
as the actual Alpha.  That was quickly corrected, the emulator
rebooted, and the emulator now has its separate LT service name.  The
emulator and the alpha are on the same subnet/VLAN/switch with no
filtering or load balancing or other possible known problem causers.

Did you configure the emulator to use the same MAC address as the
physical DS20? This must be avoided if they are in the same LAN
(specifically: same broadcast domain). Different DECnet addresses
should/might hide this problem, but it's better to avoid that in the
first place.

Now the DECserver keeps 'losing' the alpha and the emulator as
services it will connect to.  Only one of them shows up as an
available service at a time, either 'alpha' or 'emu'.  You cannot
connect to 'alpha' when the DECserver sees 'emu' and vice versa.  The
services on both machines appear to be running normally.  One day (or
for several hours) one will be available, then for reasons unknown it
switches to the other.
We can bounce the decserver if that is likely to help, but I don't
recall ever seeing behavior like this before, albeit with older
DECservers than the 708.  Any ideas?
Thanks

Make sure LAT is started after DECnet during system startup. On the
running system, stop LAT ($ MC LATCP SET NODE /STATE=OFF if LAT is not
actively used by some process) and restart it with
$ MC LATCP SHOW NODE
$ MC LATCP SHOW SERVICE <service-offered-by-this-node>
$ MC LATCP SHOW LINK /FULL
Local> show node <ds20>
Local> show service <service-on-ds20>
Local> show node <emulated>
Local> show service <service-on-emulated>
Thanks  regards,
Hans.

Btw, it should not be a problem for the DECserver to see the same
service offered by multiple nodes. In fact, this is a feature of LAT
which helps to achieve load balancing and failover.

Hans.

[Rich Jordan]

Post by Hans Bachner

Post by Hans Bachner
Rich,

Running into a novel (for me) LAT issue. We have a site with a DS20
and a DECserver 708 with current software. LAT is used for a couple
of faxmodem connections and one management terminal that still
connects that way.
We are putting an emulator in to replace the alpha. The machine was
setup offline, IP and DECNet address changed but we missed adding a
service name parameter to the LAT startup so when it initially booted
on the customer network, it also presented the same LAT service name
as the actual Alpha. That was quickly corrected, the emulator
rebooted, and the emulator now has its separate LT service name. The
emulator and the alpha are on the same subnet/VLAN/switch with no
filtering or load balancing or other possible known problem causers.

Did you configure the emulator to use the same MAC address as the
physical DS20? This must be avoided if they are in the same LAN
(specifically: same broadcast domain). Different DECnet addresses
should/might hide this problem, but it's better to avoid that in the
first place.

Now the DECserver keeps 'losing' the alpha and the emulator as
services it will connect to. Only one of them shows up as an
available service at a time, either 'alpha' or 'emu'. You cannot
connect to 'alpha' when the DECserver sees 'emu' and vice versa. The
services on both machines appear to be running normally. One day (or
for several hours) one will be available, then for reasons unknown it
switches to the other.
We can bounce the decserver if that is likely to help, but I don't
recall ever seeing behavior like this before, albeit with older
DECservers than the 708. Any ideas?
Thanks

Make sure LAT is started after DECnet during system startup. On the
running system, stop LAT ($ MC LATCP SET NODE /STATE=OFF if LAT is not
actively used by some process) and restart it with
$ MC LATCP SHOW NODE
$ MC LATCP SHOW SERVICE <service-offered-by-this-node>
$ MC LATCP SHOW LINK /FULL
Local> show node <ds20>
Local> show service <service-on-ds20>
Local> show node <emulated>
Local> show service <service-on-emulated>
Thanks regards,
Hans.

Btw, it should not be a problem for the DECserver to see the same
service offered by multiple nodes. In fact, this is a feature of LAT
which helps to achieve load balancing and failover.
Hans.

THanks for all the replies and sorry for taking so long to respond.

The emulator was brought up on a separate network. Before it was moved to the production network (for testing and to make DECnet available between it and the current server), its SCSNODE, SCSSYSTEMID, DECnet nodename, DECnet address, IP address, IP nodename were changed to EMU and available addresses. The SCSSYSTEMID is compatible with the DECnet address. So the MAC, post DECnet, is definitely unique on the production net.

I just forgot about LAT so it kept calling itself Alpha (even after all of the above were updated).

I will try rebooting the emulator this weekend and changing the startup to have both service and nodenames specified as EMU and see what happens. The customer doesn't want to reboot the DECserver unless absolutely necessary; turns out is is also used for actual remote sites dialing in still at all hours though they don't connect to the VMS system.

Getting on the DECserver shortly to review all teh other info suggested. Thanks!

Rich

[Rich Jordan]

Post by Rich Jordan

Post by Hans Bachner

Post by Hans Bachner
Rich,

Running into a novel (for me) LAT issue. We have a site with a DS20
and a DECserver 708 with current software. LAT is used for a couple
of faxmodem connections and one management terminal that still
connects that way.
We are putting an emulator in to replace the alpha. The machine was
setup offline, IP and DECNet address changed but we missed adding a
service name parameter to the LAT startup so when it initially booted
on the customer network, it also presented the same LAT service name
as the actual Alpha. That was quickly corrected, the emulator
rebooted, and the emulator now has its separate LT service name. The
emulator and the alpha are on the same subnet/VLAN/switch with no
filtering or load balancing or other possible known problem causers.

Did you configure the emulator to use the same MAC address as the
physical DS20? This must be avoided if they are in the same LAN
(specifically: same broadcast domain). Different DECnet addresses
should/might hide this problem, but it's better to avoid that in the
first place.

Now the DECserver keeps 'losing' the alpha and the emulator as
services it will connect to. Only one of them shows up as an
available service at a time, either 'alpha' or 'emu'. You cannot
connect to 'alpha' when the DECserver sees 'emu' and vice versa. The
services on both machines appear to be running normally. One day (or
for several hours) one will be available, then for reasons unknown it
switches to the other.
We can bounce the decserver if that is likely to help, but I don't
recall ever seeing behavior like this before, albeit with older
DECservers than the 708. Any ideas?
Thanks

Make sure LAT is started after DECnet during system startup. On the
running system, stop LAT ($ MC LATCP SET NODE /STATE=OFF if LAT is not
actively used by some process) and restart it with
$ MC LATCP SHOW NODE
$ MC LATCP SHOW SERVICE <service-offered-by-this-node>
$ MC LATCP SHOW LINK /FULL
Local> show node <ds20>
Local> show service <service-on-ds20>
Local> show node <emulated>
Local> show service <service-on-emulated>
Thanks regards,
Hans.

Btw, it should not be a problem for the DECserver to see the same
service offered by multiple nodes. In fact, this is a feature of LAT
which helps to achieve load balancing and failover.
Hans.

THanks for all the replies and sorry for taking so long to respond.
The emulator was brought up on a separate network. Before it was moved to the production network (for testing and to make DECnet available between it and the current server), its SCSNODE, SCSSYSTEMID, DECnet nodename, DECnet address, IP address, IP nodename were changed to EMU and available addresses. The SCSSYSTEMID is compatible with the DECnet address. So the MAC, post DECnet, is definitely unique on the production net.
I just forgot about LAT so it kept calling itself Alpha (even after all of the above were updated).
I will try rebooting the emulator this weekend and changing the startup to have both service and nodenames specified as EMU and see what happens. The customer doesn't want to reboot the DECserver unless absolutely necessary; turns out is is also used for actual remote sites dialing in still at all hours though they don't connect to the VMS system.
Getting on the DECserver shortly to review all teh other info suggested. Thanks!
Rich

And thanks, that did it. Stopping LAT, restarting it specifying both the service name and the node name made the decserver happy again.

Thats going in the checklist for the final transition when it happens.

Rich

[Volker Halle]

Rich,

LATCP is defaulting to the translation of SYS$NODE, when starting LAT. If you've changed all the DECnet and SCS system parameters, how could SYS$NODE still translate to ALPHA ?

What's the current translation of SYS$NODE on system EMU ?

Volker.

[Rich Jordan]

Post by Volker Halle
Rich,
LATCP is defaulting to the translation of SYS$NODE, when starting LAT. If you've changed all the DECnet and SCS system parameters, how could SYS$NODE still translate to ALPHA ?
What's the current translation of SYS$NODE on system EMU ?
Volker.

Because I brain-farted. Changed SCSSYSTEMID but not SCSNODE so the entire queue database didn't need to be redone. So SCSNODE was still ALPHA. Per my old FAQ info the DECnet node name can be different from SCSNODE even if that is not best practice, and this is a temporary test environment.

Once the final transition occurs, all of the node and address items will remain unchanged on the emulator and the real Alpha will either be permanently segregated, shut down, or be renamed and re-addressed itself if it ever needs to be alive on the same subnet again.