DECnet-Plus
Problem Solving

6.7.3 Correcting Node Name Validation Problems

A failure occurring when the remote system attempts to validate a node name can cause an access control problem. Do the following:

Step	Action
1	Check that the information in the namespace is correct (see your naming service documentation). Use the cdi$trace program on the destination system to obtain additional information (see Section 6.10.1).
2	If a Phase IV system cannot connect to a DECnet-Plus system, and the DECnet-Plus system is using DECdns: Use the decnet_register tool to check that the backtranslation soft links exist. Check that the tower maintenance update is succeeding. Use the following NCL command: ncl>show node node-id* session control tower -* _ncl>maintenance fullname* all status* If the last failure reason status attribute shows no error, check that the namespace is being updated correctly (refer to your DECdns documentation).
3	Make sure that the correct protocol towers information exists for the Node module on the local system.
4	Check that the node name in the synonym directory is correct.

6.8 Correcting Insufficient Resource Problems

Do the following if you have insufficient Session Control resource problems on a local or remote node:

Step Action

1 Determine if the remote node is a Phase IV system or DECnet-Plus system.

2 If the problem occurs on a Phase IV system, use NCP to examine the maximum links (or maximum alias links). Use the following command:
ncp> tell node-id show executor characteristics
If the problem occurs on a DECnet-Plus system, use NCL to look at the Session Control ports. Use the following command:
ncl> show session control port * all

3 Look at links or ports currently in use on the remote system. You can increase the links if necessary. Look at the link activity and the operation of the application to determine if you need more links or ports. Otherwise, examine the application operation to ensure it is configured properly.

Step	Action
1	Determine if the remote node is a Phase IV system or DECnet-Plus system.
2	If the problem occurs on a Phase IV system, use NCP to examine the maximum links (or maximum alias links). Use the following command: ncp> tell node-id* show executor characteristics* If the problem occurs on a DECnet-Plus system, use NCL to look at the Session Control ports. Use the following command: ncl> show session control port all*
3	Look at links or ports currently in use on the remote system. You can increase the links if necessary. Look at the link activity and the operation of the application to determine if you need more links or ports. Otherwise, examine the application operation to ensure it is configured properly.

6.9 Correcting Timed Out Problems

If you receive occasional timed-out errors, it is possible that Session Control had to take extra time to locate a specified node address. In this case, retry the failed operation. If you receive frequent timed-out errors, do the following:

Step	Action
1	If making a connection to an OpenVMS system, see if the complete login.com file is executed. If the remote system executes the complete login.com file when it receives a connect request, edit the file so only the necessary command lines execute. If the login.com file is not causing a problem, go to step 2.
2	Look at the incoming and outgoing request timer values. Use the following NCL command: ncl>show session control all characteristics
3	If the timer values seem too low, reset the values. Use NCL commands similar to the following: ncl>set session control incoming timer seconds

6.10 Correcting Node Name Resolution Problems

This section describes how to monitor DECnet-Plus node name and address resolution and search path processing.

During DECnet-Plus configuration, the system administrator sets up one or more name services on each node. This setup procedure includes generation of an NCL startup script that contains the name service search path information for the node.

The name service search path describes the following information:

The order in which the name services are to be searched for node name and address information
One or more naming templates for each name service to determine how DECnet-Plus should interpret abbreviated node names entered by users

For more information on name service configuration and search paths, refer to DECnet-Plus Installation and Configuration for your system.

For more information on DECdns, refer to DECnet-Plus DECdns Management.

6.10.1 Monitoring Search Path Processing (OpenVMS Only)

You can use either the Common Trace Facility or the cdi$trace program to obtain naming trace information.

Use the following command to invoke the Common Trace Facility:

 $ Trace Start "SESSION CDI *"

Including the CDI parameter restricts trace facility output to node name and address resolution messages.

Use the following command to run cdi$trace, a program located in SYS$SYSTEM. For example:

 $ run sys$system:cdi$trace

You can use the following procedure to redirect cdi$trace output to a file:

Define a DCL foreign command symbol:
```
 $ cdi$trace == "$cdi$trace" 
```
Specify the name of the file to contain the cdi$trace output:
```
 $ cdi$trace trace.log 
```
The output file may occasionally be missing the last few records of the trace. This is a known problem.

Although cdi$trace has known problems when run during a LAT terminal session (on an LT device), a workaround is to issue the DCL spawn command first.

6.10.2 Tracing Node Name Resolution Problems (Digital UNIX Only)

You can trace DECnet-Plus node name and address resolution and search path processing on Digital UNIX systems by setting the environment variable CDITRACE to a non-zero number before using DECnet-Plus applications. For example,

 > setenv CDITRACE 2

6.10.3 Displaying Search Path Information

Do the following to display the forward translation (node name to address) and backtranslation (address to node name) search paths for a system:

To: Use This Tool or Command:

Display the forward translation search path. ncl> show session control naming -
_ncl>search path

Display the backtranslation search path. ncl> show session control backtranslation -
_ncl>search path

To:	Use This Tool or Command:
Display the forward translation search path.	ncl> show session control naming - _ncl>search path
Display the backtranslation search path.	ncl> show session control backtranslation - _ncl>search path

6.10.4 Identifying Namespace Consistency Problems

Using the decnet_register tool, you can verify that the reverse address mapping links and the synonym links for a node are set up properly in a name service.

The following decnet_register command reads the information for a node from a name service, checks the information for consistency, and prints messages describing any inconsistencies:

decnet_register>show node node-id full

6.11 Examining the DECnet-Plus Naming Cache (OpenVMS Only)

DECnet-Plus uses an in-memory naming cache to improve performance of name and address resolution for all supported name services. This naming cache supersedes the existing DECdns cache for storage of name and addressing information.

DECnet-Plus uses this naming cache rather than the DECdns cache, for name and address resolution requests for all three name services: DECdns, Local, and DNS/BIND.

The DECdns cache still exists and DECnet-Plus continues to use it to resolve the special namespace nicknames:, local:, and domain:. The prefixes local: and domain: on a node full name, indicate to DECnet-Plus the name service where the name and addressing information is stored.

Note that the DECdns cache continues to exist. Applications other than DECnet-Plus (for example, DFS) that use DECdns directly will continue to use the existing DECdns cache.

6.11.1 Managing the Naming Cache

Using NCL commands, you can manage two naming cache parameters, the checkpoint interval and the timeout period, and flush entries from the in-memory naming cache.

Refer to your network management guide for information on managing the in-memory naming cache.

6.11.2 Dumping the Naming Cache

Use the following procedure to dump the contents of the naming cache:

Checkpoint the cache to disk. One way to force a checkpoint is by setting the checkpoint interval. For example:
```
 $ MCR NCL Set Session Control Naming Cache Checkpoint Interval 8:0:0 
```
For improved performance, CDI checkpointing is deferred for up to 15 minutes after a checkpoint request. Wait to examine the file until the checkpoint actually occurs. If you monitor the CDI activity with cdi$trace, you will see the checkpoint occur.
Dump the on-disk checkpoint file by running cdi_cache_dump, a program located in SYS$SYSTEM.
For example:
```
 $ run sys$system:cdi_cache_dump 
```

Refer to your network management guide for information on managing the in-memory naming cache.

Chapter 7
Solving Transport Problems

If you determine that an application failure is neither an application-specific, Session Control, or naming service problem, the next area to examine is the Transport layer. For the DECnet-Plus product, this means a problem could exist with either the OSI transport or Network Service Protocol (NSP) software.

Topics In This Chapter

The topics in this chapter are:

Underlying Components (OpenVMS Only) (Section 7.1)
Underlying Components (Digital UNIX Only) (Section 7.2)
Symptoms of Transport Problems (Section 7.3)
Isolating Transport Layer Problems (Section 7.4)
Correcting Connection Problems (Section 7.5)
Correcting OSI Transport Over CLNS Connection Problems (Section 7.6)
Correcting OSI Transport Over CONS (X.25) Connection Problems (Section 7.7)
Troubleshooting RFC 1006 (Section 7.8)

7.1 Underlying Components (OpenVMS Only)

Figure 7-1 shows the direct underlying components that the NSP and OSI transport components use on OpenVMS systems. Use this information as a guide when isolating transport problems.

Figure 7-1 Underlying Components (OpenVMS)

7.2 Underlying Components (Digital UNIX Only)

Figure 7-2 shows the direct underlying components that the NSP and OSI transport components use on DECnet-Plus systems. Use this information as a guide when isolating transport problems.

Figure 7-2 Underlying Components (Digital UNIX)

7.3 Symptoms of Transport Problems

If attempts to connect to a remote node fail or time out and you cannot find any problems in the upper layers, it is possible that a Transport layer problem is the cause of the failure.

7.4 Isolating Transport Layer Problems

If you cannot isolate an application failure at the Session Control layer, the problem could be at the Transport layer. Or, the problem could exist at the Network layer, but examining the Transport layer provides you with information that will help you isolate the problem in the Network layer.

7.4.1 Tools to Use

Use the following tools to isolate Transport layer problems:

Tool And Refer To:

NCL commands for the NSP and OSI transport modules NCL reference documentation

dts/dtr tests, with /transport qualifier (DECnet-Plus) Chapter 3

Common Trace Facility DECnet/OSI Common Trace Facility (CTF) Use

Tool	And Refer To:
NCL commands for the NSP and OSI transport modules	NCL reference documentation
dts/dtr tests, with /transport qualifier (DECnet-Plus)	Chapter 3
Common Trace Facility	DECnet/OSI Common Trace Facility (CTF) Use

7.4.2 Fault-Isolation Methodology

Use Figure 7-3 as a guideline for isolating Transport layer problems.

Figure 7-3 Fault-Isolation Methodology (Transport)

7.5 Correcting Connection Problems

If it is unclear where transport connection problems are occurring, look at the related ports and NSAP counters. You can also use the Common Trace Facility.

7.5.1 Checking Ports

If you check OSI transport and NSP ports, you can see whether logical links between systems are being established. Do the following to check the ports:

Step Action

1 Disable the Transport layer software that you are not checking. Use one of the following NCL commands:
ncl>disable OSI transport
ncl>disable NSP
If you disable either transport software, any connections that are currently using it are disconnected. The user can reconnect to the remote system (which then uses the other transport) if it supports the other transport and there are no other transport problems.

2 Initiate a connection to the target system.

3 Use the following NCL command to identify the transport port information for the Session Control ports in which you are interested (depending on which end of the connection you are checking, you specify direction as incoming or outgoing):
ncl> show session control port * all status, with -
_ncl>direction= value

4 Display the information for the appropriate Transport layer port with one of the following NCL commands:
ncl>show NSP port port-id all attributes
ncl>show OSI transport port port-id all attributes

5 Check that the local NSAP and remote NSAP information used in the connection refers to the expected systems. Another cause of failure is incompatible NSAPs. A DECnet-Plus system needs a Phase-IV compatible address to allow communication between the DECnet-Plus system and a Phase IV system.

6 Examine counter information (such as user PDUs received or user PDUs sent) to determine if port is actively in use.

7 Reenable the transport software that you disabled. If you could not identify any connection problems, repeat this procedure with the transport software that you previously disabled.

Step	Action
1	Disable the Transport layer software that you are not checking. Use one of the following NCL commands: ncl>disable OSI transport ncl>disable NSP If you disable either transport software, any connections that are currently using it are disconnected. The user can reconnect to the remote system (which then uses the other transport) if it supports the other transport and there are no other transport problems.
2	Initiate a connection to the target system.
3	Use the following NCL command to identify the transport port information for the Session Control ports in which you are interested (depending on which end of the connection you are checking, you specify direction as incoming or outgoing): ncl> show session control port all status, with -* _ncl>direction= value
4	Display the information for the appropriate Transport layer port with one of the following NCL commands: ncl>show NSP port port-id* all attributes* ncl>show OSI transport port port-id* all attributes*
5	Check that the local NSAP and remote NSAP information used in the connection refers to the expected systems. Another cause of failure is incompatible NSAPs. A DECnet-Plus system needs a Phase-IV compatible address to allow communication between the DECnet-Plus system and a Phase IV system.
6	Examine counter information (such as user PDUs received or user PDUs sent) to determine if port is actively in use.
7	Reenable the transport software that you disabled. If you could not identify any connection problems, repeat this procedure with the transport software that you previously disabled.

7.5.2 Checking NSAP Counters

Do the following to get information about connections between two systems:

Step

Action

Determine the local NSAPs for the system you want to examine. Use one of the following NCL commands:

ncl>show nsp local nsap * name

ncl>show osi transport local nsap * name

Each transport can have up to three NSAPs.

Determine the remote NSAPs for the system you want to examine. You need to examine all combinations of local and remote NSAPs. Use one or both of the following NCL commands:

ncl> show nsp local nsap nsap-address -
_ncl>remote nsap * name

ncl>show osi transport local nsap nsap-address -
_ncl>remote nsap * name

Check the counters on the source system. Use one of the following NCL commands:

ncl>show nsp local nsap nsap-address -
_ncl>remote nsap nsap-address all attributes

ncl>show osi transport local nsap nsap-address -
_ncl>remote nsap nsap-address all attributes

Try to establish a connection to the target system. If you cannot connect to the target system, check the remote system or try to reach the remote system from a different node.

Check the counters on the source system.

If:	Then:
The Connects Sent counter increments, the source node initiated a connect request to the target node.	Do one or both of the following: Check the target node for incoming connections. See step 6 of this procedure. A network problem can exist. See Chapter 8.
The Connects Sent counter does not increment, either a problem exists on the source system which prevents the system or application from attempting the connection, or a naming service problem exists.	Do one of the following: Check the application. Check naming service operation. See your naming service documentation.

If the source node is sending outgoing connect requests, check the counters on the target system.

If:	Then:
The Connects Received counter increments but connection fails, there is a problem on the target node.	Examine the remote node to determine the problem.
The Connects Received counter does not increment, a network problem may exist on either system that prevents the connections.	Do any of the following: Perform network reachability tests (see Chapter 3). Trace a path from the source node to the target node to determine if all systems in the expected path are available. Check the appropriate routing circuits and data links (see Chapter 8).

If you disabled transport entities, re-enable them, after checking the transport connection, with one of the following NCL commands:

ncl>enable nsp

ncl>enable osi transport

7.6 Correcting OSI Transport Over CLNS Connection Problems

Do the following to correct transport problems if you are running OSI transport over CLNS connections:

Step	Action
1	Check the outgoing OSI connection. Use the following NCL command to identify the OSI transport template and network service (CONS or CLNS): ncl> show osi transport template all attributes*
2	Check to see if the source node is sending connect requests. Do the following: Use CTF to trace OSI transport for outgoing connect requests. Check the OSI transport local and remote NSAP counters before and after attempting the connection. If connect requests are not being sent, check the application or the Network layer of the source node. If connect requests are being sent, go to the next step in this procedure.
3	Check to see if the destination node is receiving incoming connect requests: Use CTF to trace OSI transport for incoming connect requests. Check OSI local and remote NSAP counters for connects received before and after the connect attempt. If incoming requests are not received, trace the network path between the source and destination node, and check the appropriate routing circuits or data links. If incoming requests are received, go to the next step in this procedure.
4	Check the remote node to determine if an application on the destination node is available to receive connect requests. For OSI applications such as FTAM or Virtual Terminal, refer to the application documentation to check that the application is defined correctly. For other applications, use the NCL command show session control application application-id* all. For example, to verify the application definition for system operations on an OpenVMS system, enter the following command: ncl>show session control application fal all* Check that the node synonym characteristic is set to true, the image name is sys$system:fal.exe, and the address is 17. If these values are incorrect, use NCL commands to correct them.

7.7 Correcting OSI Transport Over CONS (X.25) Connection Problems

Do the following to correct transport problems if you are running OSI transport over CONS connections:

Step	Action
1	Check that the source node is using a CONS template. Use the following NCL command: ncl> show osi transport template all attributes*
2	Check that the CONS template exists. Use the following NCL command: ncl>show x25 access template template_id* -* _ncl>all characteristics If the template does not exist, create the appropriate template (see your DECnet-Plus network management documentation). If the template does exist, go to the next step.
3	Check to see if the source node is sending connect requests. Do one of the following: Use CTF to trace OSI transport for outgoing connect requests. Look at the OSI transport local and remote NSAP counters before and after attempting the connection. If connect requests are not being sent, check the application or the network layer of the source node. See your X.25 documentation for information. If connect requests are being sent, go to the next step in this procedure.
4	Check to see if the destination node is receiving incoming connect requests: Use CTF to trace OSI transport for incoming connect requests. Look at the OSI transport local and remote NSAP counters for connects received before and after the connect attempt. If incoming requests are not received, trace the network path between the source and destination node and check the appropriate routing circuits or data links. If incoming requests are received, go to the next step in this procedure.
5	Determine if an application on the destination node is available to receive connect requests. Do the following: For OSI applications such as FTAM or Virtual Terminal, refer to the application documentation to check that the application is defined correctly. For other applications, use the NCL command show session control application application-id* all. For example, to verify the application definition for system operations on a Digital UNIX system, enter the following command: ncl>show session control application fal all* Check that the node synonym characteristic is set to true, the image name is usr/sbin/fal, and the address is number=17. If these values are incorrect, use NCL commands to correct them.

7.8 Troubleshooting RFC 1006

Some general techniques for RFC 1006 troubleshooting include:

Run the rfc1006d daemon in -debug mode to obtain printed information messages about the daemon's activities.
Use the example programs to help you isolate the application behavior that is causing the problem. Use them to test RFC 1006 connectivity with a remote node or the local node.
During RFC 1006 application debugging, use the example programs as a way to test your assumptions about the behavior of XTI for RFC 1006 and to supplement the documentation.

RFC 1006 is layered on TCP/IP. Refer to your TCP/IP operational information for details.

7.8.1 Common Problems

While troubleshooting, you may encounter these problems:

rfc1006d appears to exit as soon as you run it
Note that rfc1006d obeys standard UNIX daemon conventions; therefore, you will see a shell prompt immediately after running the program, even if rfc1006d is still running, because rfc1006d will run itself as a background process even if not explicitly directed to do so.
To see if it is still running, use this command:
```
# ps -aef | grep rfc1006d 
```
If you start an rfc1006d process while another rfc1006d is already running, an error message will be written into the syslog file. The number in square brackets is the process ID. The following is an example of such an error message:
```
Jul 20 16:25:12 itsdoa rfc1006d[408]: t_bind: errno=Address already in use, 
t_errno=System error 
```
rfc1006d is not running
Under normal conditions, rfc1006d is started up at system boot time by a shell script named /sbin/rc3.d/S28.70rfc1006. Make sure that script is present. Run it and see whether rfc1006d stays running. Check the system log file for error messages from rfc1006d. (Check both daemon.log and kern.log.)
Client cannot connect to server
Determine if the remote node can be reached by any TCP application. If it cannot, use TCP/IP network troubleshooting techniques.
If the remote node can be reached by a TCP application, make sure that the remote RFC 1006 has a daemon running and listening to the TCP port to which the local node is connected. This port should be port 102 under normal conditions.
Next, make sure that the server application is running and listening for the TSAP-ID in the client's destination RFC 1006 address.

Previous | Next | Contents | [Home] | [Comments] | [Ordering info] | [Help]
```
  PS_PROFILE_007.HTML
  OSSG Documentation
   2-DEC-1996 12:34:23.97
```
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

Legal

DECnet-PlusProblem Solving