Unable to Connect to the Master Service Processors (MSPs) Over a Low-Level Link

Transcription

1 Unable to Connect to the Master Service Processors (MSPs) Over a Low-Level Link Symptom Version Problem Fix Unable to connect to a master service processor (MSP) using either the OSM or TSM Low-Level Link, or the TSM Configuration Application. All: OSM or TSM Low-Level Link. TSM client software Version 5.0 and earlier: TSM Configuration Application. This can be caused by one of the following: A. You have entered an incorrect Low-Level Link user name or password for the system. B. An incorrect Low-Level Link IP address is configured in the system list. C. You have lost, or never knew, the IP addresses for the SPs as they are configured in the enclosure backplanes. D. An Ethernet cable is disconnected, is connected to the wrong port, or is bad. E. A hardware or configuration problem exists on a hub on the dedicated LAN. F. There is a problem with the system console TCP/IP or LAN configuration. G. The SP is experiencing a software or hardware problem. H. Too many simultaneous sessions are connected to the same SP, possibly from different system consoles. (This is an unlikely cause.) Caution: Before changing anything, write down every TCP/IP address you find configured on any system console set up to manage an S-series server. Losing track of TCP/IP addresses for the master service processors is one of the worst problems that can occur. For each problem described above, try the related fix or workaround:

2 A. Verify that the Low-Level Link user name and password are correct for the system. If passwords are unknown, try the default user ID and password from the OSM User's Guide or the TSM Configuration Guide. If this fails, an authorized service provider can use the NSK SPTOOL resetuser command to reset the MSP password files to the factory default setting. The SPTOOL is available from the Intranet version of the CSSI Web. Notes: SPTOOL is intended for use only by service providers trained by HP. Do not confuse SPTOOL with SP Tool, which is installed on every system console but which does not contain the resetuser command. Low-Level Link passwords are stored in the PMF CRUs and are synchronized between both PMF CRUs in an enclosure. If you replace one PMF CRU at a time, as required for system connectivity, Low-Level Link passwords will synchronize. Swapping both PMF CRUs out of an enclosure at the same time is not supported. B. Verify that the IP addresses for the SPs in Group 01 are correct. From either the OSM or TSM Low-Level Link File menu, select Edit system list and click Modify to view the configured IP addresses. Be sure to note the current IP addresses before changing them, in case you need to change them back. If the IP addresses are unknown, such as when an enclosure is moved from a previous location and the current IP addresses have not been recorded, try the factory default enclosure IP addresses. Group n Module 1 Slot Group n Module 1 Slot C. If you need to reset the SP IP address contact the GCSC for assistance. An authorized service provider can use the NSK SPTOOL setipaddr command. The SPTOOL is available from the Intranet version of the CSSI Web. Notes: SPTOOL is intended for use only by service providers trained by HP. Do not confuse SPTOOL with SP Tool, which is installed on every system console but which does not contain the resetuser command.

3 D. Verify the cable connections from the system console through the LAN hub to the PMF CRU. Make sure that the correct dedicated LAN Ethernet cable is connected to the Ethernet port of the PMF CRU, not to the Serial Console port. See Step E and General Tips. E. Verify that the LAN hubs on the dedicated LAN are operating correctly. Check to see that the green Link OK lights of the hubs are lit a continuous green for each Ethernet cable connected to a live device. Notes: One port on a hub (often port 8) can be configured in two different ways, depending on whether or not a port connects to a node on the LAN, or to another hub in a daisy-chain. If this setting (usually a physical switch) is incorrect, at least part of your customer's dedicated LAN won't work. F. Check the subnet mask, and IP address, and ping the IP address for the SPs in order from the system console. To Ping an SP: For Windows NT, select Start> Programs> Command Prompt For Windows 2000 and Windows XP, select Start> Programs> Accessories> Command Prompt A DOS command prompt appears. Type ping followed by the IP address: >ping The ping command sends echo packets to which the response from the remote end is received within a few milliseconds (5 to 30) in a successfully configured topology. If results of the ping indicate a less than desirable responsiveness, you might have used an invalid IP address, or there might be a problem with the physical connection (check cables and hubs on the dedicated LAN), a problem with the TCP/IP configuration or LAN adapter on the PC, or a problem with the PMF CRU. A ping result of "Request timed out" means that no device answered to that address. Ping tries several times and records the time required for a response, in case there is an intermittent problem.

4 G. If you think the SP is experiencing problems, try the following: If the NonStop Kernel operating system is running, look in $ZLOG for reoccurring SPR subsystem events related to SP state changes for the SPs in Group 01 and for SPAR dumps. Contact the GCSC and provide them with a tape copy of the $SYSTEM.ZSERVICE subvolume, as well as the version of the SP firmware (if possible). Notes: If OSM or TSM cannot connect to the first SP it tries, it will attempt to connect to the peer SP. This action can mask the fact that the link to the first SP was not successful. H. Only six simultaneous SP sessions are allowed to each SP. Close OSM or TSM Low-Level Link sessions and other SP sessions if too many system consoles have active sessions to the same server. For OSM and TSM client software Version 5.0 and later, use the SP Tool Application's Net Stat command to get information about session connections. The SP Tool Application can be found in the following locations: For OSM and TSM client software versions 2003A and later: Start> Programs> HP SP Tool> SP Tool For TSM client software versions 2000A through G06.20: Start> Programs> Compaq TSM> TSM Service Provider Tools> SP Tool For TSM client software versions 10.0 and earlier: Start> Programs> TSM Client> TSM Service Provider Tools> SP Tool For TSM client software Version 5.0 through Version 7.1, the Net Stat command is available as a button. For OSM and for TSM client software Version 8.0 and later, the Net Stat command is available in the Service Processor menu. Notes: In practice, too many SP sessions will rarely result in an inability to communicate with an MSP. General Tips Remember two basic principles: 1. There is configuration information on both the system consoles and the S-series server to which you wish to connect. 2. The dedicated LAN has several physical connections between a system console and an S-series server: cabling, cards, and hubs. These might be improperly connected, improperly configured, or broken when you arrive at a site.

5 If more than one system console is present on the dedicated LAN, try to connect from all other system consoles. Record the IP addresses configured for the Low-Level Link as found on each system console. One of these system consoles may currently have a correct IP address for the particular service processor you need to reach. If you can connect from one system console, but not from others, you can rule out some potential causes for the problem. Make sure that the dedicated LAN Ethernet cables are connected to the Ethernet port on the PMF CRU. It is physically possible to connect an Ethernet cable to the serial console port, but it won't be functional. Try to connect twice, especially if you have recently restarted your system console. Sometimes the first connection attempt after you restart your system console fails, but later attempts succeed. Physical cabling defects might be rare in original equipment, but cables are always at risk of being disconnected or damaged. Ping Commands Reference Use the ping command from the MS-DOS command prompt, especially if you suspect cable failures or miscabled systems. If you have multiple S-series servers on the same dedicated LAN, or if you have multiple system consoles on that dedicated LAN, you can ping each one individually from a given system console to narrow down a connectivity problem. At the MS-DOS command prompt, use this command to determine a system console's IP address, subnet mask, and default gateway. >ipconfig To perform a loopback ping from your system console to itself (helping to test your system console's Ethernet card), enter this command: >ping Low-Level Link dialog box messages: 1. Both MSPx and MSPy are not responding. LLL logon to <system> failed. REASON: Low-Level Link used the IP addresses configured for the master service processors (MSPs) on your system console's system list under the system name <system>. Nothing responded to basic TCP/IP commands (ping), not even a non-msp device.

6 CAUSES: B-G in the Problem list. 2. Unable to create LLL session4 1. Invalid MSP IP Address specified. 2. Invalid userid/password specified. REASON: Low-Level Link obtained a TCP/IP response (ping) but could not establish the protocol used for communication between the Low-Level Link and a service processor. CAUSES: 1. You might have attempted to connect to a valid TCP/IP address on the dedicated LAN that was not a master service processor (MSP) IP address. 2. The logon to (both) master service processors failed. INITIAL TROUBLESHOOTING: Examine the configured Low-Level Link TCP/IP addresses for the S-series system on the system console you are using. Confirm them with the customer carefully. Make certain that a system console or other TCP/IP address was not accidentally configured in place of a service processor TCP/IP address. Make certain that correct updates on one system console were entered on all others. Caution: Before changing anything, write down every TCP/IP address you find configured on any system console set up to manage an S-series server. Losing track of TCP/IP addresses for the master service processors is one of the worst problems that can occur. Related Topic: Manufacturing Default IP Addresses for S-Series Servers