Decnet V question, (DecNet over IP).

[The Brit]

Walt,
It seems like you have hit the nail on the head.

I was able to test this from one of my standalone nodes, by adding the DS10 to the DECNET_Register DB on that node. Note, there was no entry for the DS10 node in DecNet_Register on the standalone, and "SET HOST" to/from the DS10 was previously working fine. Also, since the standalone node is in another building, on a different vLAN, then both the Phase V and IV connectivity are not available anyway, however DecNet over IP should still work.

After entering the DS10 into DECNET_REGISTER on the standalone, and clearing the naming cache, I am now experiencing the ~40 sec delay connecting to the DS10 from the standalone. However SET HOST from the DS10 to the Standalone is still working fine (it has no entry in Decnet_Register for the standalone node)

So it seems like that issue might be resolved.

Anyway, A Question!! Where is the DECNET_REGISTER information stored?? Specifically, in a cluster, do the nodes share the same DB/File??

Dave.

[Ian Miller.]

doing
ncl set session control transport precedence {nsp,osi}

can help too

[The Brit]

Ian,
will this cause DECNet-over-IP to be attemped first??

Dave

[Walt McGaw]

Hello Dave,

Changing the transport precedence will not help in this case. DECnet over IP is considered an OSI application connection, not NSP. The best thing is to remove the 21 tower and 20 tower information from decnet_register for any remote nodes that you only have DECnet over IP capability.

The decnet register database is called NET$LOCAL_NAME_DATABASE.DAT and resides in the SYS$SYSTEM: directory. Typically this is in sys$common, so it is shared across a cluster. If you remove the :21 and :20 addressing information for each remote node that is only reachable via DECnet over IP, you can then issue the NCL> FLUSH SESSION CONTROL NAMING CACHE ENTRY "*" command on all cluster nodes and the connection should then work quickly.

Best regards,
Walt

[The Brit]

Finally figured out what was causing the problem in the first place. (We didnt have this problem a few months ago)

The solution jumped out when testing Walt's solution above. I was going to test between my TEST system an the DS10. It crossed my mind that this was not quite like the problem in my cluster since this was a different building/network that DECNet addressed (phase IV or V) would not work anyway. The test/development systems use DECNet-over-IP by default, and do not have references to any other systems in their respective DECNET_REGISTER's.

I induced the timeout delay on my TEST system by creating an entry in DECNET_REGISTER for the DS10, and then clearing the naming cache. The delay was removed by reversing this action.

I then re-examined the cluster situation again and the light went off. A couple of months ago we set about moving all of the cluster nodes to a new VLAN. After the move, everything was fine except that we were having a problem with Advanced Server. As a result, the DS10 was rolled back to its old address (but the blades remained on the new). Now that the DS10 and the Blades were on different VLAN's, then by default, the Phase V lookup would be blocked and at that point we would begin to incur the timeout delay.

Because this node is dedicated to a few specific apps, and because "set host" to this node is very rare (usually telnet), the problem was not observed until about 10 days ago.

My thanks to everyone who contributed. It greatly helped me understand some fundamental DECNet Phase V issues.

Dave.