Can't communicate between Decnet Plus and Decnet IV

[Miguel Ward]

Hi:

Have configured a new Vms cluster 8.3 and chose to install DecnetPlus (not a good idea since have never gone this way before).

I have it working (I can for instance do a dir node:: to myself or other cluster node), using LOCAL database and at one stage managed to communicate with other Vms clusters running Decnet IV in both directions with no problem.

After having booted the cluster I am no longer able to reach any IV node (I get, after a couple of minutes, -SYSTEM-F-UNREACHABLE, remote node is not currently reachable at local node whilst in netserver.log on IV I have a request for object "SYS$COMMON:[SYSEXE]NML.EXE" with no errors).

So as not to complicate further: Can I simply install Decnet IV on top of Plus or is there someway to uninstall/disable Plus using official method (have checked manuals but could not find any mention to this alternative) and then install IV?

If not possible to revert to IV what suggestions do you give me to start checking (I have been trying to understand the 17 DecnetPlus manuals and have just got into a meltdown situation with my brain trying to figure how to do a simple debug or what to look for).

Thanks

Miguel

[Hoff · Accepted solution]

To revert, boot the distro CD or DVD, remove the DECnet-Plus product, install the DECnet Phase IV product, and off you go.

[Joseph Huber_1]

Before You revert to phase IV, check if the problem is not simply a naming tower entry of the node: if the node runs phase IV, there must be no entry in the OSI naming tower (TP4):
use decnet_register, menu entry 1 (show), for the node in question, full listing: the entry must only have NSP transport, no TP4.

And then flush the CDI naming cache with
ncl flush session control naming cache entry "*"

[Jiri_5]

Only small question: How do you configure Decnet Osi (decnet over IP)? Decnet IV dosn't suport decnet over IP.

[Colin Butcher]

Hi,

Having had extensive experience with both, I generally prefer Phase V as you can get more information out of it and you can also use "DECnet over IP" for DECnet over an IP only WAN (or indeed LAN / VLAN / VPN / whatever). Another advantage of Phase V is that in a true dual-rail LAN you get load balancing over all available paths for the price of an end-nod licence.

The most likely problem is that by default Phase IV enables all NICs with the same MAC address and by default Phase V only enables the first NIC it finds with the Phase IV compatible MAC address.

Most machines come with more than one NIC these days. You're probably not using the first one it found for DECnet.

Fix this with NET$CONFIGURE and change the address format for the NICs to be Phase IV compatible.

However, knowing the network configuration and the type of systems involved would be pretty useful first. You don't want to end up with duplicate MAC addresses on the same LAN (or VLAN). A diagram would help a lot.

If you have time for lighter reading than the Phase V doc set, try here: http://www.downloads.xdelta.co.uk/vmstjv5%20feb2005/decnet%20article%20vms%20tj%20v5%20feb2005.pdf and here: http://www.downloads.xdelta.co.uk/bootcamp%20jun2005/i220_decnet-plus_issue_1-1_10jun2004.pdf

Try to get to the "bootcamp" if you can: http://h71000.www7.hp.com/symposium/index.html?jumpid=symposium - based on all the DECnet questions of late in the ITRC I'll see if it's possible to re-run the DECnet session.

Good luck!
Cheers, Colin (www.xdelta.co.uk).

[Joseph Huber_1]

To answer Jiri:
> Only small question: How do you configure >Decnet Osi (decnet over IP)?

In addition to adding DOMAIN to the namespace (in net$configure), the TCPIP services (UCX) PWIP driver has to be configured/startet:
@tcpip$config > 4 (optional components) > 1 (PWIP driver).

And by the way, OSI is not only decnet over IP, it is the whole addressing and protocol stack.

> Decnet IV dosn't suport decnet over IP.
Exactly, and therefore You can't configure it.

[Colin Butcher]

To add to Joseph's comments on "DECnet over IP":

Having started the PWIP driver and set the naming to be "local,domain", use "127.0.0.1" as the address for the TCP/IP DNS nameserver. By doing so you ensure that the name resolution is done locally, which will then use either the local HOSTS database, or will go off to the list of DNS nameservers that you configured for TCP/IP services.

Be careful which names you look up from the DECdns namespace (DECNET_REGISTER - usually the LOCAL DECdns namespace) and which names you look up from he TCP/IP HOSTS database and DNS servers.

If you're running DECnet over IP through a firewall make sure you enable ports 102 and 399 for the RFC1006 and RFC1869 (1006-Plus) traffic.

What fun it all can be...

Cheers, Colin (www.xdelta.co.uk).

[Miguel Ward]

Thanks for replies, still no luck:

Cluster is a ds20 and a AS800 (will replace soon...) with local installation of vms 8.3 on local disks (plus shared msa-1000).

Both have only one network card each thus should not be an issue with IV.

All my Vms computers running on same LAN (6.2-1h3 cluster plus 7.3-2 cluster plus this new cluster).

When originally I configured new cluster I got everything working (for example I transferred full directories, etc using node:: sintax), only after boot I was no longer able to communicate from plus to IV. It would seem something did not start up or got lost in boot. I can communicate between plus nodes.

Same scenario with both nodes of cluster.

Checked decnet_register, IV nodes only with NSP. To keep things simple I am only using LOCAL dabatase.

Should I define nodes also in NCP? (have tried both ways).

By the way in NCP I can actually do a
TELL NODE SHOW EXEC CHAR where NODE is a IV node so that would mean that communication with IV is working.

Any log I can look at, debug to enable? operator.log shows nothing.

Thanks

Miguel

[Colin Butcher]

Can you communicate by specifying the node addresses rather than the names? eg: SET HOST 51.42

If that works then it points to a problem with the naming. Always worth flushing the Phase V naming caches too (MCR NCL FLUSH SESSION CONTROL NAMING CACHE ENTRY "*").

If that doesn't work then it points to a problem with the NICs and the MAC addresses. MCR SHOW CSMACD STATION * ALL might help. So might SDA> SHOW LAN /FULL to see which protocols and which multicast addresses are used by each NIC.

Cheers, Colin (www.xdelta.co.uk).

[Joseph Huber_1]

Not much more ideas,
just: NCP I think is forcing phase IV addressing, and works.
This lets me still believe that a SET HOST is using OSI addressing. Did You flush the naming cache as suggested ?

[Dean McGorrill]

Miguel,
see if you can set host via nsp or osi.
I'm including decnet.txt, some dcl I wrote
years ago to produce nsaps, sysid etc.
rename to decnet.com. give it your phase
iv destination address. eg of use...



$ @decnet 1.24

Scsid is 1048
Phase IV Decnet address is 1.24
NET$ is NET$490001AA000400180420
Phase IV Compatible NSAP is 49::00-01:AA-00-04-00-18-04:20
Ethernet address is AA-00-04-00-18-04


Node Volatile Summary as of 28-MAR-2007 10:55:59

Executor node = 1.24 (FOOBAR)

State = on
Identification = DECnet-OSI for OpenVMS


...OK you can use the nsap above to connect
via nsp or osi changing the selector at the
end. eg
$ set host NET$490001AA000400180420 !nsp

Welcome to OpenVMS (TM) Alpha Operating System, Version V7.2-1

Username: Exit
Error reading command input
End of file detected
%REM-S-END, control returned to node LOCAL:.FOOBAR::
$ set host NET$490001AA000400180421 !osi tra

Welcome to OpenVMS (TM) Alpha Operating System, Version V7.2-1

Username: Exit
Error reading command input
End of file detected
%REM-S-END, control returned to node LOCAL:.FOOBAR::

you can check either transport this way

Dean

[Colin Butcher]

Hello Dean,

Nice idea. Well done.

Cheers, Colin.

[Miguel Ward]

Thanks to all for input.

After fixing a mistake at my end (net$proxy had been copied from 7.3 to 8.3 but not converted) I can now, from vms 6.2 or 7.3 do a dir 8.3node:: and, for example copy to/from this node, always from IV version.

I still cannot do the opposite, ie on 8.3/Plus do either a dir, mail, phone to 7.3node:: or 6.2node::

I have always been able to do a 'set host' (sorry did not clarify this before) from 8.3 to 7.3 or 6.2.

Output of dir from 8.3 to 6.2:

$ show time
29-MAR-2007 14:04:32
$ dir pm1::
%DIRECT-E-OPENIN, error opening PM1::*.*;* as input
-RMS-E-FND, ACP file or directory lookup failed
-SYSTEM-F-UNREACHABLE, remote node is not currently reachable
$ show time
29-MAR-2007 14:07:18
$

I tried Dean's procedure with following output but not sure what to make out of it:

@decnet 2.1

Scsid is 2049
Phase IV Decnet address is 2.1
NET$ is NET$490002AA000400010820
Phase IV Compatible NSAP is 49::00-02:AA-00-04-00-01-08:20
Ethernet address is AA-00-04-00-01-08


Node Volatile Summary as of 29-MAR-2007 14:14:23

%NCP-W-UNRCMP, Unrecognized component , Node

$
Using the NET$ is the same as using real node name, ie can do a set host but not dir

My main interest (at present) is copying files from old installation to new one without having to revert to ftp, etc. Since now I am able to do that I can carry on configuring new cluster and perhaps 'discover' what is wrong over the course of the days (must be some stupid mistake which I cannot see at present).

Thanks to all with help.

Miguel from Patagonia, Argentina

[Dean McGorrill]

Miguel,
you can do a set host pm1 right? I would
have expected..
%DIRECT-E-OPENIN, error opening xxx::*.*;* as input
-RMS-E-FND, ACP file or directory lookup failed
-SYSTEM-F-INVLOGIN, login information invalid at remote node

not unreachable ? try another object ie.

$ mail/sub="test" nl: pm1::_system

see if that makes it.

[Miguel Ward]

Dean:

Yes, had tried mail:

$ mail/sub="test" nl: pm1::_system
%MAIL-E-LOGLINK, error creating network link to node PM1
-SYSTEM-F-UNREACHABLE, remote node is not currently reachable
$

Contrary to what I said before PHONE does in fact work (had to update password on phone$server in pm1):

$ phone pm1::mward
(I can answer, etc.)

Rather weird...

[Daniel Fernandez Illan]

Miguel
You need modify proxy format on Decnet V, using
sys$system:CONVERT_PROXY.EXE or another procedure, because on Decnet IV proxies are similar to:

node::remote_user localuser

and on V are:

LOCAL:.node::remote_user localuser

(see differences between name of remote node witch includes previously directory service and IV version does not occurs).

You can also remove old proxies and add news using SYSUAF (on Decnet V you does not need include directory service on command, it is added)

i.e.

UAF>add/proxy N2::pepe */d
UAF>sho/proxy N2::pepe
Default proxies are flagged with (D)

LOCAL:.N2::PEPE
* (D)

Saludos.
Daniel

[Daniel Fernandez Illan]

Miguel

See you
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=992091
for more info.

Saludos.
daniel.

[Miguel Ward]

Daniel:

Don't think its a proxy issue, the error I get is -SYSTEM-F-UNREACHABLE, remote node is not currently reachable.

Just in case I reran the conversion and also deleted one of the proxies and recreated from scratch to triple check but, as expected, no change.

Thanks

Miguel