- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Decnet V question, (DecNet over IP).
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-03-2010 07:26 AM
тАО09-03-2010 07:26 AM
We have 4 standalone systems (Testing/Dev/etc) and a production cluster. The cluster is 3 blades + 1 Alpha (DS10 running OpenVMS 8.3, DecNet phase V and TCPWare 5.8.)
I am experiencing a problem with "Set Host" to/from the DS10 and any other cluster node.
Set Host To/from the DS10 to standalone nodes is fine.
Set Host To/From Blade to Blade within the cluster is fine.
The only place there is a problem is when Setting Host from a cluster blade to the DS10 (also a cluster member), or from the DS10 to another cluster member (i.e. a blade).
When a "Set Host" command is executed, it succeeds, however it takes 40-50 seconds to connect (in either direction)
note: The blades are in c7000 enclosures. The standalone blades are in a different location (which is the reason for DECnet over IP).
The 3 cluster blades are in a different enclosure and the ds10 is connected directly to a port on the Ethernet interconnect, which provides the path for SCS.
Can anyone suggest a reason why DecNet should be so sluggish to/from a cluster blade and the DS10.
Note: This problem is with DECNet only, Telnet works fine to/from all nodes.
thanks
Dave.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-03-2010 08:21 AM
тАО09-03-2010 08:21 AM
Re: Decnet V question, (DecNet over IP).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-03-2010 11:30 PM
тАО09-03-2010 11:30 PM
Re: Decnet V question, (DecNet over IP).
Do all of the clustered blades/DS10 have all of their addresses in the local address databases and towers or are they looking for DNS translation for the IP addresses? Do all of the DNS servers return the IP addresses? (i.e. what happens if you do a TCPIP SHOW HOST ?)
The magic incantation that sometimes helps is the one for clearing cached names/addresses:
MC NCL FLUSH SESSION CONTROL NAMING CACHE ENTRY "*"
Bear in mind that DECnet Plus keeps the cache of addresses (the naming cache) and maintains this across reboots. The cached addresses may still be in cache and causing DECnet to "go there" first rather than the real address where they've been updated.
Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-07-2010 05:30 AM
тАО09-07-2010 05:30 AM
Re: Decnet V question, (DecNet over IP).
I would make sure that in DECNET_REGISTER on the node on which you issue SET HOST that the TP4 addresses are defined first and the NSP address are defined second (or not at all).
You can attempt to connect specifically to a phase IV or phase V address, to see if this is an issue, using
SET HOST NET$
The address ending in "20" is phase IV and the address ending i "21" is phase V. For example:
SET HOST NET$490028AA0054A021 will connect using a phase V address.
David Williams
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-07-2010 06:08 AM
тАО09-07-2010 06:08 AM
Re: Decnet V question, (DecNet over IP).
If I do a "set host XX.XX.XXX.XXX" the connection is created immediately.
If I do a "set host 1.7", the result is the same as using the hostname, i.e. 30-40 sec delay.
The "magical incantation" had no effect.
I have attached the output from DECNET_REGISTER for both the blades and the DS10.
I tried connecting to the net$... addresses with the following result
from BUD (Blade) to SPEEDY (DS10)
Bud:System>set host net$490001AA000400070420
%SYSTEM-F-UNREACHABLE, remote node is not currently reachable
Bud:System>set host net$490001AA000400070421
%SYSTEM-F-LINKEXIT, network partner exited
from BUD (Blade) to CITIUS (Blade)
Bud:System>set host net$490001AA000400230420
TESSCO Technologies - Unauthorized use is prohibited
Username: Exit
Bud:System>set host net$490001AA000400230421
TESSCO Technologies - Unauthorized use is prohibited
Username:
So this works between blades, but not between blade and DS10.
I think this is something to do with the setup of Decnet Phase V host resolution in the TCPWARE environment on the DS10.
Does this information and the attachment shed any new light on the problem??
thanks
Dave.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-07-2010 07:07 AM
тАО09-07-2010 07:07 AM
Re: Decnet V question, (DecNet over IP).
ncl show session control naming search path
ncl show session control back search path
ncl show session control transport Precedence
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-07-2010 07:15 AM
тАО09-07-2010 07:15 AM
Re: Decnet V question, (DecNet over IP).
As stated before, I would redefine the order in DECNET_REGISTER so that the :21 address is first before :20. this way connections should try phase V first before attempting to use phase IV.
After making the change, you may have to clear the naming cache to correct this using:
MCR NCL FLUSH SESSION CONTROL NAMING CACHE ENTRY "*"
David Williams
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-07-2010 07:31 AM
тАО09-07-2010 07:31 AM
Re: Decnet V question, (DecNet over IP).
I have attached the output from the three commands executed on the blade and on the DS10. As far as I can see, the output looks the same.
David
I was not able to set host to the DS10 from the blade, using either the Phase IV or the Phase V address. Both methods took a significant length of time, however they returned different errors.
Phase IV: %SYSTEM-F-UNREACHABLE, remote node is not currently reachable
Phase V: %SYSTEM-F-LINKEXIT, network partner exited
This was the result for both Incoming and Outgoing "set host" to/from the DS10.
Just as a reminder, the "set host" command always works, eventually. The problem is that it takes an inordinately long time to connect. I currently have a ticket in with Process Software because I believe that there is a problem related to host name resolution and our implimentation of TCPWARE.
I need to go offline now for ~3 hours, however I will respond to any new suggestions when I return.
thanks
Dave.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-07-2010 08:51 AM
тАО09-07-2010 08:51 AM
SolutionWhen you connect by name using DECnet, there is an order that addresses are tried. The address lookups occur first, and the information is cached in CDI. If you have 3 addresses configured for the remote node, then the connection order is DECnet OSI (21 selector address), DECnet over IP, and then DECnet using NSP (Phase IV style connection and the address has a 20 selector).
If DECnet protocol is being blocked between the source node and target node, we have to time out the connection for the DECnet OSI address (which is about 40 seconds or so) and then we will try the DECnet over IP connection (which appears to work for you). This could quite well explain the delay you are seeing trying to connect by name, but quick response to the ip$nnn.nnn.nnn.nnn address (which forces DECnet over IP).
If this is the case, you should remove the DECnet addresses for the target node from the source node in DECNET_REGISTER and then flush the source node's CDI cache using the command $ MCR NCL FLUSH SESSION CONTROL NAMING CACHE ENTRy "*".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-07-2010 09:19 AM
тАО09-07-2010 09:19 AM