HP OSI Troubleshooting Guide HP 9000 Networking Edition 6 32070-90031 E0597 Printed in: United States © Copyright 1997 Hewlett-Packard Company. All rights reserved.
Legal Notices The information in this document is subject to change without notice. Hewlett-Packard makes no warranty of any kind with regard to this manual, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Hewlett-Packard shall not be held liable for errors contained herein or direct, indirect, special, incidental or consequential damages in connection with the furnishing, performance, or use of this material. Warranty.
This software is based in part on the Fourth Berkeley Software Distribution under license from the Regents of the University of California. ©copyright 1980, 1984, 1986 Novell, Inc. ©copyright 1986-1992 Sun Microsystems, Inc. ©copyright 1985-86, 1988 Massachusetts Institute of Technology ©copyright 1989-93 The Open Software Foundation, Inc. ©copyright 1986 Digital Equipment Corporation ©copyright 1990 Motorola, Inc.
Contents 1. Interoperability Testing Testing FTAM Interoperability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 FTAM Interoperability Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 FTAM Pre-Test Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 FTAM Interoperability Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 FTAM Connectivity Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents Running LAN Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Interpreting LAN Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Testing X.25 Interoperability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 X.25 Pre-Test Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Running X.25 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents Common Configuration Mistakes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65 ots_dests Common Mistakes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65 ots_subnets Common Mistakes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65 ots_parms Common Mistakes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 local_app Common Mistakes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 remote_app Common Mistakes . . . . . . . . . . . .
Contents Updating OTS: otsupdate . . . . . . . . . . . . . . . .84 Dynamic Routing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . End System Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intermediate System Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . ES/IS Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Route Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Printing History The manual printing date and part number indicate its current edition. The printing date will change when a new edition is printed. Minor changes may be made at reprint without changing the printing date. the manual part number will change when extensive changes are made. Manual updates may be issued between editions to correct errors or document product changes. To ensure that you receive the updated or new editions, you should subscribe to the appropriate product support service.
1 Interoperability Testing Processes for verifying and troubleshooting communication between your local HP node and another node on the network.
Interoperability Testing Testing FTAM Interoperability Testing FTAM Interoperability Use the following procedures to test FTAM Interoperability. FTAM Interoperability Testing 1. Log on as root. 2. Perform the pre-test checklist. 3. Create a result file. 4. Perform FTAM tests. 5. If osidiag cannot find a default local application title, perform “Specifying Application Titles.” 6. Interpret errors.
Interoperability Testing FTAM Pre-Test Checklist FTAM Pre-Test Checklist Check the following before attempting to run the FTAM tests. Figure 1-1 FTAM Pre-Test Checklist Is the local stack running over the appropriate link? No Start the local stack. No Start FTAM. No Start the remote stack. No Start FTAM on the remote. No Start logging.
Interoperability Testing FTAM Interoperability Testing FTAM Interoperability Testing This procedure invokes FTAM through osidiag to provide as much information as possible about errors that might occur. FTAM Connectivity Test The steps below describe how to test FTAM connectivity between the local and remote node. 1. From root, type osidiag and select “FTAM TESTS.” 2. Create a result file. 3. Select “Connect” from the FTAM menu. 4.
Interoperability Testing FTAM Interoperability Testing FTAM File Transfer Test After a successful FTAM connect test. Follow the steps below to do an FTAM file transfer. 1. From the FTAM menu, create a new result file. 2. Select “Low Level Transfer.” 3. The initiator ID parameters are displayed. a. Leave first ID set to local login. b. Set first password to your local password. c. Leave second set unchanged. d. Press Done. 4. Leave source Presentation address unchanged. Press Done. 5.
Interoperability Testing Interpreting FTAM Errors Interpreting FTAM Errors Table 1-1 may help you to find what caused your FTAM test to fail. 1. Check the field labeled “Diagnostic”. If this field is present, look for a text string labeled “further details” for the cause. 2. Look at the line after “FAILED”. The operation that failed is listed. Table 1-1 FTAM Call Errors FTAM Call ft_aeactivation() ft_connect() ft_select() 16 Reason Corrective Action FTAM not correctly installed.
Interoperability Testing Interpreting FTAM Errors FTAM Call Reason Corrective Action ft_create() Permission problem or incorrect directories were specified in the path for the destination file name. Check the permissions and the directories specified. ft_sdata() Transfer file too large. (Error code 101 Buffer too large error). Rerun the test with a smaller file or use the High Level Transfer test.
Interoperability Testing Testing APRI Interoperability Testing APRI Interoperability The steps below describe how to test the ACSE/Presentation and ROSE (APRI) layer connectivity between the local and remote node. Use this only if you are developing APRI programs and wish to verify connectivity at this layer. 1. Log on as root. 2. Perform the pre-test checklist. 3. Perform APRI test - Client Mode. 4. Perform APRI test - Server Mode (optional). 5.
Interoperability Testing APRI Pretest Checklist APRI Pretest Checklist Check the following before attempting the APRI Interoperability tests. Figure 1-2 APRI Pre-Test Checklist Is the local OTS stack up? No Type otsstart to bring up the system. No Start the remote stack. Yes Is the stack up on the remote system? Yes Do you have the No Remote Presentation Address? Get it from the Remote System Worksheet.
Interoperability Testing Running APRI Tests (Client Mode) Running APRI Tests (Client Mode) The following steps verify APRI connectivity and interoperability with a remote node. If the remote is not capable of receiving connections, or you want to test the remote’s ability to establish connections, follow the instructions in “Running APRI Tests (Server Mode)” on page 21. 1. From root, type /opt/ots/bin/osidiag and select “ACSE/Presentation or ROSE Tests.” 2. Create a result file. 3.
Interoperability Testing Running APRI Tests (Server Mode) Running APRI Tests (Server Mode) If the remote is not capable of receiving connections, or you want to test the remote’s ability to establish connections, follow these instructions. 1. From root, type /opt/ots/bin/osidiag -w 300 (the -w 300 allows 300 seconds to get the client ready once the server is started), and select “ACSE/Presentation or ROSE Tests.” 2. Create a result file. 3. Select “Server...” from the Test Case menu. 4.
Interoperability Testing Interpreting APRI Errors Interpreting APRI Errors Table 1-2 describes possible errors and corrective actions if an error occurs during a call to APRI. Table 1-2 APRI Call Errors APRI Call Reason Corrective Action ap_open() Incorrect installation or OTS stack is not up. Run otsstat to see if OTS stack is up. Run otsstart to start OTS stack. ap_set_env() Incorrect address specified. (parameter ap_my_psap) Recheck the value of ap_my_psap.
Interoperability Testing Interpreting APRI Errors APRI Call Reason Corrective Action ap_rcv(A_ASSOC_CNF) Your connect request arrived at the remote, but the remote did not like one of your proposed values or it is not available to service connections. The confirmation carries three pieces of information: the result, the source (if rejected), and a diagnostic code. Examine the diagnostic code for the course of action. ro_bind() The values you specified are not compatible with those negotiated.
Interoperability Testing Testing Session Interoperability Testing Session Interoperability The steps below describe how to test the session layer connectivity between the local and remote node. Use this only if you are developing session programs and wish to verify connectivity at this layer. 1. Log on as root. 2. Perform the pre-test checklist. 3. Perform Session tests - Client Mode. 4. Perform Session tests - Server Mode (optional). 5.
Interoperability Testing Session Pre-Test Checklist Session Pre-Test Checklist Figure 1-3 Session Pre-Test Checklist Is OTS stack up? No Start OTS using osistart. No Start the remote stack. No Get the address made up of S-Sel, T-Sel, and Network Address. No Start FTAM on the remote. No Is the remote HP? Run osidiag as server on the remote.
Interoperability Testing Running Session Tests (Client Mode) Running Session Tests (Client Mode) Normally you use this list of steps to verify connectivity and interoperability with a remote node. If the remote is not capable of receiving connections, or you wish to test the remote’s ability to establish connections, follow the instructions in “Running APRI Tests (Server Mode)” on page 21. 1. From root, type /opt/ots/bin/osidiag and select “Session Tests.” 2. Create a result file. 3.
Interoperability Testing Running Session Tests (Server Mode) Running Session Tests (Server Mode) If the remote is not capable of receiving connections, or you wish to test the remote’s ability to establish connections, follow these instructions. 1. From root, type /opt/ots/bin/osidiag -w 300 (the -w 300 allows 300 seconds to get the client ready once the server is started), and select “Session Tests”. 2. Create a result file. 3. Select “Server...” from the Test Case menu. 4.
Interoperability Testing Interpreting Session Errors Interpreting Session Errors Table 1-3 describes possible errors and corrective actions. The list is sorted by the name of the function producing the error. The names are displayed by osidiag on the line immediately after the test status. Table 1-3 Session Call Errors Session Call Reason Corrective Action osi_init() Usually lack of available swap space. Add swap space as necessary. osi_rgr_rq() osi_rgr_cf() Possibly stack is not up.
Interoperability Testing Interpreting Session Errors Session Call Reason Corrective Action ses_uabort_id() Used to decode incoming abort indication. Indicates the application on top of the Session layer detected some problem. Examine the output of the remote application for further information as to why the abort was sent. ses_connect_rf() Called to decode a refusal to connection request.
Interoperability Testing Testing Transport Interoperability Testing Transport Interoperability The steps below describe how to test Transport layer connectivity between the local and remote node. 1. Log on as root. 2. Perform the pre-test checklist. 3. Perform Transport tests. 4. If osidiag reports “FAILED”, see “Interpreting Transport Errors” on page 33.
Interoperability Testing Transport Pre-Test Checklist Transport Pre-Test Checklist Figure 1-4 Transport Pre-Test Checklist Is the OTS stack up? No Yes Is the remote stack up? No Start OTS using otsstart. Start remote stack. Yes Do you have the remote Network Address and T-Selector? No Get the address from the S-Sel, T-Sel, P-Sel, and Network Address. Yes Do the Transport Interoperability Tests.
Interoperability Testing Running Transport Tests Running Transport Tests 1. From root, type /opt/ots/bin/osidiag and select “Transport Tests.” 2. Create a result file. 3. Make sure a server application is running on the remote, then select “Connect” from the Transport Tests menu. 4. Enter the destination Transport Selector and Network Address when prompted. NOTE: osidiag will display the local address by default. The default P, S, and T selectors are given in ASCII surrounded by double quotes.
Interoperability Testing Interpreting Transport Errors Interpreting Transport Errors The following are possible situations you may currently find yourself in. Transport problem corrected. If you have made a change that corrected your Transport problem, then return to the Service Layer test that originally failed and try again. Configuration or other change required.
Interoperability Testing Testing LAN (802.3 or FDDI) Interoperability Testing LAN (802.3 or FDDI) Interoperability The steps below describe how to test connectivity at the Link level (either 802.3 or FDDI LAN) between the local and remote node. 1. Log on as root. 2. Perform the pre-test checklist. 3. Perform LAN test. 4. If osidiag reports “FAILED,” see “Interpreting LAN Errors” on page 37.
Interoperability Testing LAN Pre-Test Checklist LAN Pre-Test Checklist Figure 1-5 LAN Pre-Test Checklist Is the local LAN card up? No Start the LAN using osiadmin. Yes Is the remote card up? No Start remote card. Yes Do you have the Media Access Control Address for the remote? No Get the address by selecting "LAN Tests," then "Status" menu. The MAC address is labelled "LAN Physical Address.
Interoperability Testing Running LAN Tests Running LAN Tests 1. From root, type /opt/ots/bin/osidiag and select “LAN Tests.” 2. Create a result file. 3. Select “Test Frames.” 4. Enter the interface name to issue the test from (lan0, lan1, etc.). The default from the ots_subnets file can be used unless you have multiple I/O Cards. 5. Enter the value previously retrieved for the remote MAC address in hexadecimal (always 6 bytes - 12 hex digits). Do not include the leading “0x” if present. 6.
Interoperability Testing Interpreting LAN Errors Interpreting LAN Errors The following are possible situations you may currently find yourself in. LAN problem corrected. If you have made a change that corrected your LAN problem, then proceed to the OTS layer tests. Configuration change required. If the corrective action in the following sections require you to change a configuration parameter, then do so and rerun the LAN test. Problem persists.
Interoperability Testing Interpreting LAN Errors Error Reason Action getmsg (DL_TEST_CON) getmsg (DL_UNITDATA_ACK) Receives information from the remote either on Receive or Test Frame operation. Usually means time out. Check MAC address specified, and cabling between the two systems. If neither is true, check to see if remote supports IEEE 802.3 TEST frames. putmsg (DL_TEST_REQ) The local system is not configured to use IEEE packets. Check and correct as necessary using the lanconfig(1M) command.
Interoperability Testing Testing X.25 Interoperability Testing X.25 Interoperability The steps below describe how to test connectivity at the Network Layer for nodes connected via X.25. 1. Log on as root. 2. Perform the pre-test checklist. 3. Perform X.25 test. 4. If osidiag reports “FAILED,” see “Interpreting X.25 Errors” on page 42.
Interoperability Testing X.25 Pre-Test Checklist X.25 Pre-Test Checklist Figure 1-6 X.25 Pre-Test Checklist No Is the local card up? (Use x25stat to check.) Start X.25 using osiadmin or x25init. Yes No Is the remote card up? Start remote card. Yes Is the remote stack up? No Start the remote stack. Yes Do you have the X.121 Address for the remote OSI stack? No Type x25stat -c to display the address. No From osiadmin, select "OTS", "View Configuration", and "OTS Subnetwork".
Interoperability Testing Running X.25 Tests Running X.25 Tests 1. From root, type osidiag and select “WAN X.25Tests.” 2. Create a result file. 3. Select “Connect.” 4. Enter the value for the remote X.121 address. This value is both the address for the remote card and any subaddress concatenated into a single decimal number. 5. Leave the X.25 Interface name unchanged. 6. For CONS change the protocol ID to the value 03010100. For CLNS, change the protocol ID to 81. Press Done. 7.
Interoperability Testing Interpreting X.25 Errors Interpreting X.25 Errors The following are possible situations you may currently find yourself in. X.25 problem corrected. If you have made a change that corrected your X.25 problem, then proceed to the Transport layer tests. Configuration change required. If the corrective action in the following sections require you to change a configuration parameter, then do so and rerun the X.25 test. Problem persists.
Interoperability Testing Interpreting X.25 Errors Error Reason recv(*00B*) Errors related to the receipt of an unexpected CLEAR or RESET packet. Action Some common diagnostics: (0) No additional information - may indicate that the request was delivered to the remote, but it was rejected by the OSI stack. Check Protocol ID. (67) Call setup problem; Invalid called address. Check addresses of the remote and correct. (231) Connection Rejection - NSAP Unreachable. Check the Protocol ID and subaddress.
Interoperability Testing Reason and Refuse Codes Reason and Refuse Codes Protocol Reason Codes The following are reason codes that may be logged or returned to your program. Session Provider Abort Reason Code The value passed back to Session programs by the ses_pabort_id() routine. Transport Disconnect Reason Code The value passed back to XTI program by the t_rcvdis() routine. ASCE/Presentation DCNX_KO Log Message The value shown in the second low order byte of the Cause field (f3 in Cause = 0x0001f3ff).
Interoperability Testing Reason and Refuse Codes Code (0x01) (0x02) (0x03) Meaning Action Provider N-Disconnect (Transient) Previously active network connection was abruptly disconnected. Congestion at TSAP Some vendor’s equipment may indicate that the application above transport is not capable of receiving any more connections. The X.25 card or the switch may have gone down. Provider N-Disconnect (Permanent) Previously active network connection was abruptly disconnected.
Interoperability Testing Reason and Refuse Codes Code (0x08) Meaning N-Reject (NSAP unreachable/ Permanent) Network connection could not be established because the X.121 address was incorrect. (0x09) N-Reset from NS Provider (No Reason) Network connection was reset. (0x0a) N-Reset from NS Provider (Congestion) Network connection was reset. (0x0b) N_Reject (Address Unknown) No destination or route entry exists for the given NSAP. Network connection cannot be established.
Interoperability Testing Reason and Refuse Codes Code (0x1a) Meaning Network Reset from NS User (Resynch) Network connection was reset. Action X.25 diagnostic indicates resynchronization was requested. (0x20) Undefined reason, unknown origin Indicates some X.25 problem. Check for down card on local or remote, switch, or facilities negotiation. (0x21) Invalid Parameter (OTS Kernel) Check for NSAPs that are too large or missing. An encoded parameter is invalid.
Interoperability Testing Reason and Refuse Codes Code (0x82) Meaning Connection Negotiation Failed May be a problem with the classes specified (transport over CONS error). (0x83) Duplicate Source Reference for Same NSAP This is a protocol error. (0x84) Mismatched References Either a protocol error, or may indicate that the remote stack was taken down and brought back up while existing connections remained. Action Check to see if remote only uses class 0.
Interoperability Testing Reason and Refuse Codes Code (0xE7) Meaning Problem Accessing X.25 Subaddress of Remote Action Correct the routing table or bring up the remote. Subaddress portion of X.121 from the OTS routing table is incorrect or the remote is not up. (0xE8) NSAP not Configured Network address portion of the address specified is not configured in the routing table.
Interoperability Testing Reason and Refuse Codes Code (0xF9) Meaning Protocol Error Detected by Local Transport Error encountered decoding a PDU sent by the remote Transport entity. (0xFA) Protocol Error Detected by Local Session Error encountered decoding a PDU sent by the remote Transport entity. (0xFC) Insufficient Resources for Local Transport Stack experiencing resource problems. (0xFD) Insufficient Resources for Local Session Stack experiencing resource problems.
Interoperability Testing Reason and Refuse Codes Session Refuse Codes Table 1-8 describes the meanings defined by ISO 8327 for the reason codes carried on a negative Session connect confirmation. These values are logged after S_CONNECT_Resp (Negative) message, and on return from the ses_connect_rf() library call. Table 1-8 Session Refuse Codes Code Meaning 0 Reason not specified. 1 Rejection by called Session service user due to temporary congestion. 2 Rejection by called Session service user.
Interoperability Testing To Create A Result File To Create A Result File Use the following steps to create a result file. It can be reached from several osiadmin menus. 1. Select “Utilities” from a services menu. 2. Select “Open Result File”. 3. Enter the name of your file (for example, /tmp/ftam.res). 4. Press Done. 5. Press the space bar when a message appears showing the file was opened. If the message shows an error, check the name you specified. 6. Press Previous Menu.
2 Problem Solving Information and procedures for identifying and troubleshooting problems that you may encounter using Hewlett-Packard’s OSI products.
Problem Solving Basic Steps Basic Steps NOTE If the problem you encounter occurs only when communicating with another system, see Chapter 1, “Interoperability Testing,” on page 11. 1. Interpret the initial error. To find more information about the specific error, see “Interpreting Errors” on page 55. 2. Determine the status of components. Make sure all the OSI product components are up and running. See “Checking System Status” on page 56. 3. Verify operation.
Problem Solving Interpreting Errors Interpreting Errors This section describes where you should look to find more information about an error you encountered. Table 2-1 gives the places where you may encounter errors and how to interpret them. Table 2-1 Interpreting Errors Where Action osidiag You will find a description of how to interpret errors at the end of each section in Chapter 1, “Interoperability Testing,” on page 11. nettl log files Many errors contain detailed text describing the problem.
Problem Solving Checking System Status Checking System Status There are several tools that allow you to check if the links, stack, and services are up and running. Perform the following steps to verify that your local system is up. Status Check 1 1. Run otsstat to verify the status of OTS and its attachment to the underlying links. 2. If status says “RUNNING,” go to Status Check 2. 3. If status says “NOT RUNNING,” start the stack using otsstart or osiadmin. If still “NOT RUNNING,” run osiconfchk.
Problem Solving Checking System Status Status Check 4 1. If you are using the FTAM Service, run osistat to verify that the shared memory segment is present and to display the number of currently active FTAM applications. See Chapter 3, “Using OSI and OTS Tools,” on page 71, for more information on osistat. 2. If you are using FTAM, then the count of “Active FTAM responder service providers” should be one or more. If not, then run osiadmin or osistart to start FTAM. 3.
Problem Solving Running Verification Tests Running Verification Tests The verification strategy described here follows a bottom up approach. It first checks the ability of the links to communicate, then the OTS Transport Layer, and last the desired service. All the verification tests use osidiag. Testing the X.400 services may alternatively be performed through x4admin or the X.400 tools described in Managing X.400—Administrator’s Guide.
Problem Solving Running Verification Tests 2. If you have multiple LAN cards, run this test under osiadmin, so that osidiag will use the correct default values 3. If you encounter errors, see “Interpreting LAN Errors” on page 37. OTS Transport Verification To verify OTS Transport, do the following: 1. Go to “Transport Tests-” under osidiag and select the “Loopback...” test. 2. Overwrite the Network Address if you want to test a subnetwork other than the default.
Problem Solving Running Verification Tests 3. Use the default configured values that osidiag presents. For more information about a parameter, press the “Help” key when in the field in question. 4. If you encounter errors, see “Interpreting Errors” for the specific layer in Chapter 1, “Interoperability Testing,” on page 11.
Problem Solving Collecting Troubleshooting Data Collecting Troubleshooting Data If the information already given was not sufficient to isolate and correct the problem, use the tracing and logging facilities to gather more information. The method you use to gather tracing and logging information will depend on the error that is produced. Table 2-2 lists the possible methods.
Problem Solving Tracing and Logging through /opt/ots/bin/osidiag Tracing and Logging through /opt/ots/bin/osidiag osidiag (located in the /opt/ots/bin directory) provides the ability to automatically capture nettl trace and log information and append it to the output for a test operation. osidiag also allows you to copy the results displayed to the screen to a result file. The following steps describe how to enable both facilities through osidiag. 1.
Problem Solving Tracing and Logging through /opt/ots/bin/osidiag Tracing and Logging User Applications Two facilities exist to provide more data about the behavior and errors encountered by your application, API tracing and nettl. API Tracing This facility allows you to trace the calls your application makes to the Application Programmatic Interface. The mechanism to perform API tracing is described in the programmer's guide for the service you are using.
Problem Solving Tracing and Logging through /opt/ots/bin/osidiag Service/Layer FDDI Entities to Log FDDI * The tracing and logging of X.400-specific components can be done through x4admin, and is described in the Managing X.400—Administrator’s Guide. Tracing and logging of OTS and the link is still performed through nettl for X.400. Tracing is only recommended if you have a good understanding of the protocol internals.
Problem Solving Common Configuration Mistakes Common Configuration Mistakes The following list describes some common configuration errors that may result in failure during verification. The errors are grouped by the configuration file that contains them. See the “OTS and Related Parameters” chapter in the OSI Transport Services manual for detailed information about all the parameters.
Problem Solving Common Configuration Mistakes • Incorrect interface name. Specifying an interface name that is not configured will result in warnings, but OTS will still start. If otsstat indicates any links are “NOT RUNNING,” verify these names. ots_parms Common Mistakes • If close to the limit of connections available (448 over LAN, 4096 over X.25) through OTS, the ses_reuse_tp_con flag may hold open connections you need to recycle. • If using CONS/X.
Problem Solving Common Logged Errors Common Logged Errors The following list describes some of the more common errors logged by OTS that you can encounter. These errors are sorted by the subsystem name and the message ID as it appears in the log. Table 2-4 Subsystem OTS Error Description [9600] High Access Method ERROR Indicates an error in the streams interface between user programs and the OTS stack in the kernel.
Problem Solving Common Logged Errors Error Description This error is logged after the Session layer has successfully established a connection, but is releasing the connection in some error state. Examine the log or user application for other errors. [5010] S_DCNX_KO Table 2-7 Subsystem TRANSPORT Error Description [4103] Protocol Error Indicates a protocol error was detected at this layer.
Problem Solving Common Logged Errors Table 2-8 Subsystem NETWORK Error Description [3003] N_REJECT Indicates the X.25 connection could not be established with the remote. Possible problems are that the NSAP/X.121 address mapping for this remote is incorrect. Facility negotiation failed with X.25 (for example, Reverse Charging, X.25 '80/'84). The remote stack or card may not be enabled. The remote system may not be able to accept anymore X.25 connections.
Problem Solving Submitting Problem Information to HP Submitting Problem Information to HP The following items will be very useful in having HP Support diagnose problems with your OSI products. • Result Files - The output created for all your runs of osidiag. Examples of the recommended file names are /tmp/ftam.res and /tmp/tran.res. • OTS Configuration Files - The contents of the following files in /etc/opt/ots/conf: local_app For FTAM problems only. ots_dests For nodes running over X.
3 Using OSI and OTS Tools The software tools you'll use to configure, maintain, and troubleshoot your HP OSI products.
Using OSI and OTS Tools OSIADMIN OSIADMIN The osiadmin (OSI Administration) program gives you access to the various configuration, administration, and diagnostic tools you need to set up and maintain your HP OSI products. osiadmin acts as an umbrella for these tools, providing you with a single, easy way to configure, start, stop, and test each product. Table 3-1 shows the HP OSI products, administration functions, and software tools called by osiadmin.
Using OSI and OTS Tools OSIADMIN RFC1006 FTAM X.
Using OSI and OTS Tools Managing Your Configuration Managing Your Configuration Using osiconf The osiconf program is an interactive configuration tool you can use to do the following: • Verify that your configuration information has been entered with the proper syntax and range, and that it is consistent between OTS and FTAM. • Modify the OTS and FTAM configuration files. osiconf is most commonly used through osiadmin, but it may be started alone.
Using OSI and OTS Tools Managing Your Configuration The directory where the configuration files may be found is specified by setting the environment variable OSI_CONFIG. If OSI_CONFIG is not set, /etc/opt/ots/conf is searched as the default location. Running osiconfchk Follow these steps to run the osiconfchk program: 1. Login as root. 2. Type osiconfchk. For details on the options and variables, refer to the HP-UX online man pages for osiconfchk. 3.
Using OSI and OTS Tools OSI Diagnostics OSI Diagnostics The osidiag (OSI Diagnostic) program allows you to verify that the OSI services provided by the HP network node are operational. You'll use osidiag throughout the remote interoperability procedures. It can also be used as a layer troubleshooting aid in determining the functionality of the suspect component. You can start osidiag from within osiadmin or directly from the HP-UX system prompt.
Using OSI and OTS Tools OSI Diagnostics Component NOTE Test Session Provides verification of HP’s ability to establish or receive connections at the session layer. Data, expedited data, and some of the activity management primitives may also be sent on this connection. Transport Provides verification of HP’s ability to establish or receive connections at the transport layer. Data, and expedited data may also be sent on this connection. Please read that follows this table. X.25 Allows an X.
Using OSI and OTS Tools Starting and Stopping OSI Starting and Stopping OSI Occasionally, while configuring, verifying, or troubleshooting any of the OSI products, you'll need to start or stop the OSI products. Use the commands described here. osistart Command Execute the osistart command from the system prompt. Use it to start services, such as FTAM and X.400 along with the OTS component and whatever links are being used. Issue the osistart command with no options.
Using OSI and OTS Tools Starting and Stopping OSI Stopping OSI To stop the OSI stack, you must shutdown your system. After initial installation of OTS/9000, the OSI stack will start automatically after rebooting. If you do not want it to start automatically, edit the /etc/rc.config.d/ots file and change the value of otsstart to “off.
Using OSI and OTS Tools Starting OTS: otsstart Starting OTS: otsstart This section tells you how to start OTS/9000 directly from the HP-UX shell command line. See the section “To Start OTS/9000,” in chapter 5 of the OSI Transport Services manual, for how to start OTS/9000 from osiadmin. otsstart starts the protocol subsystems, and the CONS and CLNS parts of the network layer. This command requires super-user capability.
Using OSI and OTS Tools Starting OTS: otsstart DOWN not configured, but level 2 is down 2. Next, make sure that OTS is properly configured to use these links. 3. Finally, make sure that no other applications are conflicting with OTS’s use of these links. Recovering from otsstart Failure In most cases, when otsstart fails, you will need to change the configuration before trying to start OTS/9000 again. Use the error messages from otsstart and osiconfchk as a guide for making changes.
Using OSI and OTS Tools Checking OTS Status: otsstat Checking OTS Status: otsstat If connectivity problems occur, one of the first actions to take is to find out whether OTS/9000 and the network services are running. The otsstat command tells you if OTS/9000 is running and whether the OTS/9000 subsystem can successfully communicate with the X.25 and LAN software. The X.25 status is reported in terms of each card’s programmatic access name. The LAN status is reported in terms of the LAN interface name.
Using OSI and OTS Tools Checking OTS Status: otsstat Example 1 The following example shows the output of otsstat when OTS/9000 is running and can properly communicate with X.25 and with LAN. The programmatic access name for the X.25 card is telenet. The interface name for the LAN is lan0. /opt/ots/bin/otsstat OTS: lan0: telenet: NOTE running running running The otsstat command does not include the status of the X.25 and LAN network services. To check their status, use the x25stat and lanscan commands.
Using OSI and OTS Tools Updating OTS: otsupdate Updating OTS: otsupdate Chapter 5 of the OSI Transport Services manual describes many OTS configuration parameters as being “dynamic.” This means that you may change the values of these parameters and have them take effect while OTS/9000 is up and running. Non-dynamic parameters take effect only after the system has been rebooted.
Using OSI and OTS Tools Dynamic Routing Commands Dynamic Routing Commands Dynamic routing commands provide an alternative to using otsupdate. Use of these commands may be more efficient than using otsupdate when the information is small and restricted to routing information. OTS routing information is contained in the Routing Information Base (RIB). The information contained in this database can be changed using a set of user commands. Use these commands to: • View the current RIB entries.
Using OSI and OTS Tools Dynamic Routing Commands otsshowes VIEW: Displays all end system entries for the specified subnetwork. otsshowes subnet_name Intermediate System Commands Intermediate systems are nodes directly reachable from the local node that function as inter-network or intra-network routers. otsaddis ADD: Adds a single intermediate system entry to the specified subnetwork.
Using OSI and OTS Tools Dynamic Routing Commands ES/IS Parameters Table 3-3 Argument ES/IS Command Parameters ots_dests Parameter Description es_nsap dest_net_address Specifies the end system’s NSAP is_nsap dest_net_address Specifies the intermediate system’s NSAP subnet_name dest_out_subnet The symbolic name for the outgoing subnetwork to which this end system is attached. This name must have been previously configured before OTS startup.
Using OSI and OTS Tools Dynamic Routing Commands Table 3-4 ES/IS Command Options Option Description -r Reverse Charge Request off. Specifying this option prohibits outgoing calls from requesting reverse charging. This is the default. -R Reverse Charge Request on. Specifying this option makes outgoing calls request reverse charging. -xN X.25 level of service. N=[0-3]. 0 is X.25 ISO 8878 1 is X.25/ 1980 2 is X.25/ 1984 3 is X.
Using OSI and OTS Tools Dynamic Routing Commands Option Description -P pid Specifying this option causes a destination protocol identifier (PID) to be configured for this destination. This value is specified as 2 to 16 hexadecimal digits (must be an even number of digits) or the word “NULL” (without the quotes). If you use a hexadecimal value, this value is used as the destination PID on connection requests to the end system.
Using OSI and OTS Tools Dynamic Routing Commands otsaddroute ADD: Adds a single route entry for the specified subnetwork. otsaddroute net_id subnet_name is_nsap [-mMask] [-w] otsdelroute DELETE: Deletes the specified route entry. otsdelroute net_id subnet_name [-mMask] [-w] otsshowroute VIEW: Displays all route entries for the specified subnetwork.
Using OSI and OTS Tools Dynamic Routing Commands Route Command Options Table 3-6 Route Command Options Argument Description -w Write this action (add or delete) to the ots_routes configuration file making the change permanent. The default is no write. -mMask Network ID mask. Mask is a bit mask, specified in hex digits. It specifies how may bits in the network ID are significant when resolving addresses.
Using OSI and OTS Tools Dynamic Routing Commands otsshownsaps VIEW: Shows local NSAPs configured for a specified network service.
Index A ACSE/Presentation, 76 adding end systems, 85 intermediate systems, 86 route entries, 90 APRI interpreting interoperability errors, 22 pretest checklist, 19 running client mode tests, 20 running serbver mode tests, 21 testing interoperability, 18 C collecting troubleshooting data, 61 commands, dynamic routing, 85 common configuration mistakes, 65 common logged errors, 67 configuration common mistakes, 65 local_app, 66 managing using osiconf, 74 remote_app, 66 updating, 84 creating result file, 52 D
Index refuse codes, 51 remote_app, 66 result file, creating, 52 RIB, 85 route command, 89 routing information base, see RIB, 85 routing, dynamic, 85 verifying links for troubleshooting, 58 OTS for troubleshooting, 59 services for troubleshooting, 59 viewing end systems, 86 intermediate systems, 86 route entries, 90 S session refuse codes, 51 starting OSI, 78 OTS/9000, 80 status checking system, 56 OTS/9000, 82 stopping OSI, 78 submitting problem information to HP, 70 T tracing user applications, 63 troub
