|
|
This chapter helps you isolate problems in a LightStream 2020 multiservice ATM switch (LS2020 switch) to a single field-replaceable unit (FRU), such as a line card, blower, or power supply. Once you have identified the faulty FRU, refer to the chapter "Replacing FRUs" for instructions on removing and replacing it.
This chapter is divided into the following sections:
Read this chapter to learn how to use diagnostics and other methods to isolate faults in LS2020 enterprise ATM switches.
| Caution Before removing any components from the chassis, read the safety instructions below. If you handle components without taking proper electrostatic discharge (ESD) precautions, you may damage the system. |
| Warning LS2020 switches meet accepted safety standards. However, improper use can result in electrical shock, fire hazards, and personal injury. Read all of the following instructions carefully before installation and use. Note and adhere to all Cautions and Warnings. |
Static electricity can damage or degrade electronic components. Before you expose circuitry, make sure that your body, the rack, and the circuit boards are at the same ground potential to prevent damaging ESD. To connect yourself to ground, use a wrist strap connected to one of the system's grounding jacks, or to the bare metal surface of the system frame.
In addition to the ESD guidelines above, extra care should be taken to protect cards. All spare cards are shipped in reusable antistatic shielding bags. When cards are not installed in the machine, keep them in antistatic bags. Do not remove cards from their bags unless you are grounded. Do not place these bags on exposed electrical contacts, where they can cause short circuits.
Power-on self-test (POST) diagnostics are the first line of defense for identifying hardware problems. POST runs automatically on each card whenever the system or the slot is powered up or when the card is reset; it takes about 90 seconds. There are POSTs for the following components:
The POST for each line card also checks the accompanying access card.
If a card passes POST, the green RDY LED on its front bulkhead turns on. If a card fails POST, its yellow FLT LED turns on. To display POST results, use one of these commands:
In the resulting display, look at the POST line and the Application line. If the Application line says DISABLED, you may be able to correct the problem by enabling (activating) the card. See the LightStream 2020 Network Operations Guide for instructions.
Note The FLT LED does not necessarily indicate a POST failure or a disabled application; the LED stays on under other conditions as well. (See the "LED Descriptions" section in the chapter "Hardware Description" for more information on the FLT LED.) If the LED is on but the POST result is OK, try operating the card.
If a card fails POST, review the portion of the section "General Troubleshooting " for the card in question. In most cases, you should also run the hardware diagnostics to confirm that a problem exists. (Hardware diagnostics are described briefly in the following section; the instructions for running them appear in the section "Hardware Diagnostics" later in this chapter.)
General troubleshooting tasks help you identify faults in NPs, switch cards, and line cards. These can be performed before, after, instead of, or in addition to running the diagnostic software. They are the only means of identifying faults in subsystems not covered by POST or diagnostics, such as blowers and power supplies.
Use the information in this section to help isolate faults in an LS2020 switch. This section is to be used in conjunction with the diagnostic software. Some of these procedures require you to be in the same room with the faulty system; others can be performed remotely.
If your LS2020 switch does not operate properly after you have tried the suggestions below, call your customer support representative.
Before resorting to the diagnostics or to complex troubleshooting, check simple things:
If you are bringing up a new LS2020 node, a new card, or a new kind of port for the first time, a likely source of problems is configuration. The problem may exist at either the LS2020 side or the remote side of the connection; be sure to check both configurations. Refer to the LightStream 2020 Configuration Guide for information on software configuration.
The symptoms listed below indicate problems that may require replacement of a switch card. Switch card replacement instructions appear in the chapter "Replacing FRUs."
Note To thoroughly test the switch card's switching fabric, run tests that loop data through the switch card on NPs and/or line cards in every slot in the chassis.
Note If the switch card's fault (FLT) LED is lit, see the "LED Descriptions" section in the chapter "Hardware Description" for a list of possible causes and solutions.
If the NP fails to power up, check its access card at the back of the chassis. An NP requires an NP access card (NPAC); it cannot operate with any other kind of access card.
Note If the NP's fault (FLT) LED is lit, see the "LED Descriptions" section in the chapter "Hardware Description" for a list of possible causes and solutions.
Consider replacing the NP if any of the following applies. NP replacement instructions appear in the chapter "Replacing FRUs."
If the system fails to boot, it could indicate either a problem with the NP itself, a problem with the NP's hard disk drive, or a problem with the software on the hard drive.
This section provides information on how to isolate faults in interface modules. (An interface module consists of a line card and its access card.)
Note If the line card's fault (FLT) LED is lit, see Table 1-7 in the chapter "Hardware Description" for a list of possible causes and solutions.
The following will help you distinguish between problems in a line card and problems in an access card.
| Caution Do not swap one line card for another unless you are sure that the cards are of the same type. |
If you are having trouble bringing up an interface module, check the following:
If you are having signal quality problems with a physical interface on an access card, check the following:
Note To prevent complications from dirty or damaged connectors, keep any unused optical connector covered with its protective cap.
The following conditions may require replacement of either a line card or its access card. Replacement instructions appear in the chapter "Replacing FRUs."
The following conditions indicate failure of a blower. See the chapter "Replacing FRUs" for replacement instructions.
Note Check the blowers carefully. A blower that appears to be turning on its own may be moving due to the breeze created by the other blower.
| Warning The impeller inside the blower box may still be turning. Keep fingers, screwdrivers and other objects away from the perforations in the blower's housing. |
In a system with one power tray, no power will be present if the power tray is faulty. Suspect a problem with the power tray if cycling the system's power has no effect.
A system with two power trays can operate normally when only one is working; if you suspect a problem, use the CLI command show chassis powersupply. The display for a healthy dual-tray system is shown below. (In a system with only one power tray, both lines for the unused slot will read "Empty.")
If a status line for an occupied slot says anything other than Good, check the faulty power tray to see that it is properly connected. (Power tray slot A is on top; slot B is on the bottom.) If the problem persists, replace the power tray as described in the section "Replacing a Power Tray" in the chapter "Replacing FRUs."
Disk assembly problems are indicated by the following symptoms:
If a disk problem is indicated, check the disk assembly connector for bent or broken pins. To do so, remove the disk assembly as described in the section "Replacing a Disk Assembly" in the chapter "Replacing FRUs." Then examine the 64-pin male connector at the back of the slot. If any pins are bent or damaged, they are the likely source of the problem. Replace the disk assembly connector as described in the chapter "Replacing FRUs."
If the connector is in good condition, the problem may be in the disk assembly itself, or in the software on the disk. If you suspect a problem with the software, you should be able to correct it by reinstalling the software as described in the LightStream 2020 Network Operations Guide. If that does not solve the problem, or if you believe the problem lies in the hardware, see the section "Replacing a Disk Assembly" in the chapter "Replacing FRUs" for instructions on replacing the disk assembly.
Midplane problems are indicated by the following symptoms. Midplane replacement instructions appear in the section "Replacing the Midplane" of the chapter "Replacing FRUs."
LS2020 hardware diagnostics are used to discover the location of hardware faults. You can run diagnostics on a line card or a backup NP while the rest of the system continues to operate. Only the card under test comes out of service during the diagnostics (except where you are testing an NP card in a non-redundant system, in which case the system must be taken off line).
Note that certain tests should not be run while the system is operating, and other restrictions may apply as well. See the "Test Notes " section later in this chapter for details.
You can run diagnostics either remotely over a telnet or modem connection, or locally from a console connected to the console port. However, to run diagnostics on the sole NP in a non-redundant system requires a local console or a modem.
The diagnostics reside on each NP's hard disk. Several parts of the system can be tested:
This section is divided into the following subsections:
You can access the diagnostics in three ways:
This section tells you how to use the test command in CLI to run field diagnostics on a line card in a specified slot or on a backup NP.
The first subsection below describes the switches you can use with the test command. The second subsection explains how to use the test command to test a line card, and the third tells you how to use the test command to test a backup NP.
Note You cannot use the test command to run diagnostics on an active NP. Instead, you must load the diagnostics manually and use the manufacturing diagnostic interface. The procedures describing this task appear in the sections "Loading Manufacturing Diagnostics " and "Running Manufacturing Diagnostics " later in this chapter.
The test command impedes normal traffic flow. If you are unsure of the potential impact of this command on your network, contact Cisco customer support.
The syntax of the CLI test command is as follows:
Note The /usr/diag directory also includes a file of switch card diagnostics. These diagnostics are reserved for use by customer service personnel.
If you use the test command with multiple switches, you must enter each one with its own - (minus) character and separate the switches with spaces. For example:
If you run the test command with no switches, diagnostics are loaded and run on the specified card in the background, and your CLI prompt returns so you can perform other tasks. The diagnostics complete in a minimum of 5 minutes. To display their status, enter test <slot#> -r.
This procedure explains how to use the test command in CLI to run diagnostics on a line card. CLI must be running on the system you plan to test.
Step 2 Log in to CLI.
Step 3 Enter protected mode:
You will be prompted to enter the protected mode password.
Step 4 Use the set command to set the SNMP community to a community with write privileges. (If you do not know the appropriate community name for this system, contact the network administrator.) The example below gives the syntax of the command; replace write-community with a real community name.
Step 5 Issue the test command. (Replace the 4 in the example below with the number of the card you want to test, and add any switches you need.)
Step 6 Wait at least 15 minutes for the diagnostics to load and run. If you used the -x switch with test, wait at least 30 minutes. Then use the following command to retrieve test results, replacing the 4 with the slot number of the card you just tested:
The result indicates that the tests passed, that they failed, or (as shown above) that they are still running. In the last case, wait a few minutes for the tests to finish and enter test 4 -r again.
Step 7 If the tests passed, the card is OK—skip to the next step.
If the tests failed, replace the card; see the chapter "Replacing FRUs" for instructions. In the case of failure, you should also record the list of test numbers and error numbers displayed when you enter test -r, and return this list to the repair depot along with the failed card.
Step 8 To return a card to service after running diagnostics, use the following command:
Note After you set the card back to active status, you can no longer use test -r to retrieve diagnostic results.
Step 9 Use the set command to change the SNMP community back to a read-only community. Replace read-community in the example below with the name of a read-only SNMP community.
Follow the procedures in this section to use the test command in CLI to run diagnostics on a backup NP. (If you need to test a lone NP, see the procedure "Loading Manufacturing Diagnostics into a Lone NP " later in this chapter.) This task requires either a local console connected to the switch under test or a modem connection. You cannot use telnet.
The first procedure below explains how to force the active and backup NPs to switch roles; this is only necessary if the NP you want to test is currently active. The second procedure tells you how to run the diagnostics.
Step 2 If the NP you want to test is currently operating as the backup, skip to the next procedure, Testing the Backup NP. Continue with this procedure if the NP to be tested is active; the following steps explain how to force the active NP to become the backup so that you can run diagnostics.
If you are not sure which NP is primary, use the CLI command show chassis general and look for Slot of Primary NP in the resulting display.
Step 3 Establish a local console connection or a modem connection to the system under test. (See the LightStream 2020 Installation Guide for information on terminal settings and how to determine which port to use.)
Step 4 If the command line prompt you see does not contain the words TCS hub, enter `. to get a TCS hub prompt.
Step 5 At the TCS hub prompt, use the connect <slot#> command to connect to the NP you want to test. The example below assumes that you will test the NP in slot 1.
Step 6 When you connect, you will see a login prompt. Log in as root or fldsup.
Step 7 At the prompt, enter reboot -n.
Step 8 Enter `. to return to the TCS hub.
Step 9 Go to step 3 of the next procedure.
Step 2 If the command line prompt you see does not contain the words TCS hub, enter `. to get a TCS hub prompt.
Step 3 At the TCS hub prompt, use connect <slot#> to connect to the NP that you do not want to test. You will use this NP, which must be active, to test the other one. The example below assumes that you are connecting to the NP in slot 2.
Step 4 Log in and, if necessary, enter cli to start the CLI.
Step 5 Enter protected mode:
You will be prompted to enter the protected mode password.
Step 6 Use the set command to set the SNMP community to a community with write privileges. (If you do not know the appropriate community name for this system, contact the network administrator.) The example below gives the syntax of the command; replace write-community with a real community name.
Step 7 Issue the test <slot#> command, where slot# is 1 or 2—the number of the backup NP you are testing. If you need to add any switches to the test command, refer to the section "The test Command " for details.
Step 8 Wait at least 15 minutes for the diagnostics to load and run. If you used the -x switch with test, wait at least 30 minutes. Then use the following command to retrieve test results, replacing the 1 with the slot number of the card you just tested:
The result indicates that the tests passed, that they failed, or (as shown above) that they are still running. In the last case, wait a few minutes for the tests to finish and enter test 1 -r again.
Step 9 If the tests passed, the card is OK—skip to the next step. If the tests failed, you should replace the card; see the chapter "Replacing FRUs" for instructions. (In the case of failure, you should also record the list of test numbers and error numbers displayed when you enter test -r, and return this list to the repair depot along with the failed card.)
Step 10 To return a card to service after running diagnostics, use the following command:
Note After you set the card back to active status, you can no longer use test -r to retrieve diagnostic results.
Step 11 Use the set command to change the SNMP community back to a read-only community. Replace read-community in the example below with the name of a read-only SNMP community.
You must use manufacturing diagnostics to test the single NP in a nonredundant system. If you wish, you can also use them to test backup NPs and line cards. With manufacturing diagnostics, you can specify which test(s) to run.
This section contains the following procedures:
After loading the diagnostics, see the section "Running Manufacturing Diagnostics " for instructions on what to do next.
This procedure explains how to load the manufacturing diagnostics into the sole NP in a nonredundant system. Note that this procedure requires the system under test to stop passing traffic. It also requires you to have a local console connection or a modem connection to the switch whose NP you are testing. You cannot use telnet or rlogin.
The commands used in the procedure are listed below, followed by the procedure itself:
Establishes a terminal connection to the card in the specified slot.
Starts the reboot sequence that allows you to load the diagnostic software.
Tells the NP to load the file diag_np1.aout.
Step 2 Establish a local console connection or a modem connection to the system under test. (See the LightStream 2020 Installation Guide for information on terminal settings and how to determine which console port to use.)
Step 3 If the command line prompt you see does not contain the words TCS hub, enter `. to get a TCS hub prompt.
Step 4 At the TCS hub prompt, use the connect <slot#> command to connect to the NP. In the example below, the NP is assumed to be in slot 1.
Step 5 When you connect, you see a login prompt. Log in as root or fldsup.
Step 6 Enter reboot -n to enter the boot sequence. You will see the following display:
Step 7 Enter 6 at the prompt to escape to the bootstrap command line interpreter:
Step 8 At the boot prompt, enter the following command to load the diagnostic software:
You will see the following display:
Step 9 For instructions on executing tests in NP diagnostics, see the following section, "Running Manufacturing Diagnostics ."
Step 10 When you finish your diagnostic session, you must reset the NP. Enter `. to return to the TCS hub. Then use the command reset <slot#> to reset the NP.
You can use the manufacturing diagnostics to test backup NPs and line cards. Use the procedure in this section to load the manufacturing diagnostics, then go on to the following section, "Running Manufacturing Diagnostics ," for further instructions.
As you follow the procedure below, you will use these commands:
Invokes protected mode in the CLI, allowing you to use test and other protected commands. You must enter a password to enter protected mode.
Sets the SNMP community of the target node to community, a valid community name. You must set to a community with write privileges in order to load and run the diagnostics.
Loads diagnostics into the card indicated by slot#, then passes you to the command-driven interface of the manufacturing diagnostics.
Step 2 Log into the node to be tested, start CLI and enter protected mode:
You will be prompted to enter the protected mode password.
Step 3 Use the set command to set the SNMP community to a community with write privileges. (If you do not know the appropriate community name for this system, contact the network administrator.) The example below gives the syntax of the command; replace write-community with a real community name.
Step 4 Issue the test command with the -m switch, which loads manufacturing diagnostics. Replace slot# below with a real slot number.
You will see a display that resembles this one:
Note You may need to press Return after you see the word "connected" in order to display the diagnostics banner and command prompt.
You can use the run command in any diagnostic package to run a preselected set of tests. See the section "Running Manufacturing Diagnostics " for detailed procedures on running tests.
If you need to return to CLI before completing your session with the diagnostics, you can toggle back and forth as follows: from the diagnostics, use the command ~q to get to CLI; from CLI, use connect <slot#> diagnostic to return to the diagnostics. Be sure to use the exit command to leave diagnostics when your session is finished.
For information on diagnostics commands, refer to the "Command Reference " section at the end of this chapter.
Read this section for information on running manufacturing diagnostics. The first subsection, "Running Sets of Tests ," applies to all of the test procedures that follow it.
In each of the diagnostics packages, commands are provided to run preselected sets of tests:
Note that if you use the sel or dsel commands, the tests executed by run may change. run executes tests that are currently selected; the test set outlined here is selected by default, but you can change it.
Approximate run times for run are as follows:
arun selects every test in the test package and runs it once. Note that arun includes some tests that you might not wish to run routinely (such as loopback tests, which require looping plugs, switch interface tests that send data to the switch card, and time-consuming memory tests). Do not use arun if the system you are testing is operating; use the appropriate procedure from the "Test Notes " section to disable the system first.
Use this procedure to run diagnostics on an NP card. You are assumed to have already loaded the diagnostics onto the card, as described in the preceding section "Loading Manufacturing Diagnostics ."
The screens that follow (Figure 2-1, Figure 2-2, and Figure 2-3) use the arun command in order to display a complete list of tests. It is recommended that you use run instead.
Note See the section "NP Tests with Special Requirements " later in this chapter for notes on tests with special requirements such as looping plugs.
Step 2 To run or rerun a particular test or group of tests, you can use the run command in conjunction with test numbers. For example:
(To display a list of tests and test numbers, use the lst all command.)
Step 3 The status command displays a message giving the status of diagnostic tests. Use status fail to get information only on tests that have failed.
Step 4 For explanations of the error codes used in the status display, use the help command in conjunction with the number of the test in question. For example,:
Note If you need to return to CLI before completing your session with the diagnostics, you can toggle back and forth using the command ~. to get to CLI and connect <slot#> diagnostic to return to the diagnostics. Be sure to exit from the diagnostics when your session is finished.
Step 5 If the card passes the diagnostics, return the card to active mode. First exit from the diagnostics:
Note If you are running diagnostics on an active NP, the exit command has no effect; you must reset the NP. You can either press the reset button on the front of the card, or enter `., then reset <slot#> to reset the NP, then connect <slot#> to reconnect to the NP. Replace <slot#> with the slot number of the card you were testing.
Step 6 When the login prompt appears, log in to the node, enter CLI's protected mode, and use the set command as shown below to reset the card's status to active. Replace <slot#> with the slot number of the card you were testing.
If any tests fail, replace the card being tested. Replacement procedures appear in the chapter "Replacing FRUs."
If all tests pass but you are still experiencing a problem, test the other cards in the chassis. Consider replacing any cards that fail diagnostics. If the problem persists, investigate causes outside the LS2020 hardware, including leased lines and edge devices.
Use this procedure to run diagnostics on a low-speed line card. You are assumed to have already loaded the diagnostics onto the card, as described in the preceding section "Loading Manufacturing Diagnostics ."
Note The screens that follow (Figure 2-4, Figure 2-5, and Figure 2-6) use the arun command in order to display a complete list of tests. It is recommended that you use run instead.
Note Tests flagged in the list above with (L) require looping plugs. See the section "LSC Tests with Special Requirements " later in this chapter for details on tests that have special requirements.
Step 2 To run or rerun a particular test or group of tests, use the run command in conjunction with test numbers. For example:
(To display a list of tests and test numbers, use the lst all command.)
Step 3 The status command displays a message giving the status of diagnostic tests. Use status fail to get information only on tests that have failed.
Step 4 For explanations of the error codes used in the status display, use the help command in conjunction with the number of the test in question. For example,:
Note If you need to return to CLI before completing your session with the diagnostics, you can toggle back and forth using the command ~. to get to CLI and connect <slot#> diagnostic to return to the diagnostics. Be sure to exit from the diagnostics when your session is finished.
Step 5 If the card passes the diagnostics, return the card to active mode. First exit from the diagnostics:
Step 6 When the login prompt appears, log into the node, enter CLI's protected mode, and use the set command as shown below to reset the card's status to active. Replace <slot#> with the slot number of the card you were testing.
If any tests fail, you may need to replace either the line card being tested or its access card. (Replacement procedures appear in the chapter "Replacing FRUs.") Look at the numbers of the tests that failed to determine which card to replace:
Note Tests 111-118 normally fail if you run them in an operating system using test -m; this failure does not indicate a problem and should be ignored.
Note Tests 43, 46, and 50 pass only when looping plugs are installed; disable or disregard them when testing without looping plugs.
If all tests pass but you are still experiencing a problem, test the other cards in the chassis. Consider replacing any cards that fail diagnostics. If the problem persists, investigate causes outside the LS2020 hardware, including leased lines and edge devices.
Use this procedure to run diagnostics on a medium-speed line card. You are assumed to have already loaded the diagnostics onto the card, as described in the preceding section, "Loading Manufacturing Diagnostics ."
Note The screens that follow (Figure 2-7, Figure 2-8, and Figure 2-9) use the arun command in order to display a complete list of tests. It is recommended that you use run instead.
Step 2 To run or rerun a particular test or group of tests, use the run command in conjunction with test numbers. For example:
(To display a list of tests and test numbers, use the lst all command.)
Step 3 The status command displays a message giving the status of diagnostic tests. Use status fail to get information only on tests that have failed.
Step 4 For explanations of the error codes used in the status display, use the help command in conjunction with the number of the test in question. For example,
Note If you need to return to CLI before completing your session with the diagnostics, you can toggle back and forth using the command ~. to get to CLI and connect <slot#> diagnostic to return to the diagnostics. Be sure to exit from the diagnostics when your session is finished.
Step 5 If the card passes the diagnostics, return the card to active mode. First exit from the diagnostics:
Step 6 When the log in prompt appears, log into the node, enter CLI's protected mode, and use the set command as shown below to reset the card's status to active. Replace <slot#> with the slot number of the card you were testing.
Note See the section "MSC Tests with Special Requirements " later in this chapter for notes on tests with special requirements.
If any tests fail, you may need to replace either the line card being tested or its access card. (Replacement procedures appear in the chapter "Replacing FRUs.") Look at the numbers of the tests that failed to determine which card to replace:
Note Tests 70 - 80 normally fail if you run them in an operating system using test -m; this failure does not indicate a problem and should be ignored.
Note Test 95 passes only on the E3 access card; disable or disregard it when testing a T3 card. Tests 93 and 94 pass only when looping plugs are installed; disable or disregard them when testing without looping plugs.
If all tests pass but you are still experiencing a problem, test the other cards in the chassis. Consider replacing any cards that fail diagnostics. If the problem persists, investigate causes outside the LS2020 hardware, including leased lines and edge devices.
Use this procedure to run diagnostics on a packet line card. You are assumed to have already loaded the diagnostics onto the card, as described in the preceding section, "Loading Manufacturing Diagnostics ."
When they are loaded, the PLC diagnostics determine which type of access card is installed with the line card under test. Tests appropriate for the access card are enabled. You can use the access command, described in the section "Command Reference ," later in this chapter to display the type of the access card.
Note See the section "PLC Tests with Special Requirements ," later in this chapter, for notes on tests with special requirements.
Step 2 To run or rerun a particular test or group of tests, use the run command in conjunction with test numbers. For example:
(To display a list of tests and test numbers, use the lst all command.)
Step 3 The status command displays a message giving the status of diagnostic tests. Use status fail to get information only on tests that have failed.
Step 4 For explanations of the error codes used in the status display, use the help command in conjunction with the number of the test in question. For example,:
Note If you need to return to CLI before completing your session with the diagnostics, you can toggle back and forth using the commands ~. to get to CLI and connect <slot#> diagnostic to return to the diagnostics. Be sure to exit from the diagnostics when your session is finished.
Step 5 If the card passes the diagnostics, return the card to active mode. First exit from the diagnostics:
Step 6 When the login prompt appears, log in to the node, enter CLI's protected mode, and use the set command as shown below to reset the card's status to active. Replace <slot#> with the slot number of the card you were testing.
If test 55 (or any of its subtests, 55.01 through 55.15) fails, this indicates a failure in the access card. Replace the access card, as described in the chapter "Replacing FRUs."
If any other tests fail, replace the card being tested. Replacement procedures appear in the chapter "Replacing FRUs."
If all tests pass but you are still experiencing a problem, test the other cards in the chassis. Consider replacing any cards that fail diagnostics. If the problem persists, investigate causes outside the LS2020 hardware, including leased lines and edge devices.
Use this procedure to run diagnostics on a cell line card. It assumes that you have already loaded the diagnostics onto the card, as described in the preceding section, "Loading Manufacturing Diagnostics ."
When they are loaded, the CLC diagnostics determine which type of access card is installed with the line card under test. Tests appropriate for the access card are enabled. You can use the access command, described in the section "Command Reference ," later in this chapter, to display the type of the access card.
Note See the section "CLC Tests with Special Requirements ," later in this chapter, for notes on tests with special requirements.
Step 2 To run or rerun a particular test or group of tests, use the run command in conjunction with test numbers. For example:
(To display a list of tests and test numbers, use the lst all command.)
Step 3 The status command displays a message giving the status of diagnostic tests. Use status fail to get information only on tests that have failed.
Step 4 For explanations of the error codes used in the status display, use the help command in conjunction with the number of the test in question. For example,
Note If you need to return to CLI before completing your session with the diagnostics, you can toggle back and forth using the command ~. to get to CLI and connect <slot#> diagnostic to return to the diagnostics. Be sure to exit from the diagnostics when your session is finished.
Step 5 If the card passes the diagnostics, return the card to active mode. First exit from the diagnostics:
Step 6 When the login prompt appears, log into the node, enter CLI's protected mode, and use the set command as shown below to reset the card's status to active. Replace <slot#> with the slot number of the card you were testing.
If test 49 (or any of its subtests) fails, this indicates a failure in the access card. In this case replace the access card, as described in the chapter "Replacing FRUs."
If any other tests fail, replace the card being tested. Replacement procedures appear in the chapter "Replacing FRUs."
If all tests pass but you are still experiencing a problem, test the other cards in the chassis. Consider replacing any cards that fail diagnostics. If the problem persists, investigate causes outside the LS2020 hardware, including leased lines and edge devices.
This section lists special requirements for tests in each diagnostic package.
The NP tests listed below write data to the hard disk. These tests are disabled by default; you must explicitly enable them in order to run them. Do not run the following tests, unless you are testing a new disk drive or have reason to suspect a fault in your hard disk.
The NP tests listed below send data through the switch card. Take the LS2020 node off line before running these tests, as described in the procedure below. Do not run them on a system that is passing traffic. (If the node is running, these tests may fail when they would otherwise pass. In addition, the "bad" data passed to the switch by the tests may cause traps.)
To run these tests, use the following procedure to disable the system and all the other cards in the chassis. This prevents the other cards from sending packets to the card under test that cause these tests to fail even when no problem exists.
Step 2 At the prompt, use the command reboot -n to bring down the NP. (Bring down both if there are two.)
Step 3 Enter `. to get a TCS hub prompt.
Step 4 From the TCS hub, enter reset <slot#> to reset each slot that has a line card in it. (Do not reset the switch card or NP slots.)
Step 5 Enter connect <slot#> to return to the NP, then press Return to display a menu of boot options.
Step 6 At the menu's Option prompt, enter 6, as shown below.
Step 7 The system displays the following message and a boot prompt. Enter the string shown below to load the NP diagnostics.
Step 8 When the diagnostics finish loading, you can select and run the desired tests.
The NP tests listed below fail if they are run on a system that does not have looping plugs installed on the NP Ethernet port and Diag2 port. (In field diagnostics, these tests are invoked when you use the test command's -l switch.) If you do not have looping plugs installed, it is recommended that you avoid running these tests:
The NP tests listed below fail if they are run on a system that does not have writable diskettes in its floppy disk drives. If you do not have a scratch diskette in each floppy drive, it is recommended that you avoid running these tests:
The NP memory tests listed below take longer than one minute to run. Some take many minutes. (In field diagnostics, these tests are invoked when you use the test command's -x switch.)
The NP diagnostics include tests for the battery-backed RAM clock that keeps time for the whole system. If the tests fail, you will be prompted to reset the clock; you must supply the current time and date. If the system under test has two NPs, their clocks must agree to within one minute or file consistency problems between the two NPs may result.
The low-speed line card tests listed below send data through the switch card. (In field diagnostics, these tests are invoked when you use the test command's -s switch.) Take the LS2020 node off line before running these tests. Do not run them on a system that is passing traffic. (If the node is running, these tests may fail when they would otherwise pass. In addition, the "bad" data passed to the switch by the tests may cause traps.)
To run these tests, use the procedure below to disable the system and all the other cards in the chassis, and then to load the diagnostics into the card you wish to test. This procedure prevents the other cards from sending packets to the card under test that cause these tests to fail even when no problem exists.
Step 2 At the prompt, enter the command reboot -n to bring down the NP. If your system has two NPs, do the following to reboot the second one:
Step 3 Enter `. to get a TCS hub prompt.
Step 4 From the TCS hub, enter reset <slot#> to reset each slot that has a line card in it. (Do not reset the switch card or NP slots.)
Step 5 Enter connect <slot#> to return to the NP, then press Return to display a menu of boot options.
Step 6 At the menu's Option prompt, enter 6, as shown below.
Step 7 The system displays the following message and a boot prompt. Enter the string shown below to load the system monitor, which you will use to load the diagnostics.
Step 8 When the system monitor finishes loading, you will see an identifying message and a prompt, as shown below. To load diagnostics, enter the command shown, replacing <slot#> with the number of the card you want to test.
Step 9 Wait about 5 minutes for the diagnostics to load. Then enter `. to return to the TCS hub.
Step 10 At the TCS hub prompt, use the command connect <slot#> to connect to the card you just loaded.
Step 11 Run the desired tests.
The LSC tests listed below will fail if they are run on a system that does not have looping plugs installed on the I/O ports. (In field diagnostics, these tests are invoked when you use the test command's -l switch.) If you do not have looping plugs installed, it is recommended that you avoid running these tests:
The low-speed line card memory tests listed below take longer than one minute to run. Some take many minutes. (In field diagnostics, these tests are invoked when you use the test command's -x switch.)
The medium-speed line card tests listed below send data through the switch card. (In field diagnostics, these tests are invoked when you use the test command's -s switch.) Take the LS2020 node off line before running these tests. Do not run them on a system that is passing traffic. (If the node is running, these tests may fail when they would otherwise pass. In addition, the "bad" data passed to the switch by the tests may cause traps.)
To run these tests, use the procedure below to disable the system and all the other cards in the chassis, and then to load the diagnostics into the card you wish to test. This procedure prevents the other cards from sending packets to the card under test that cause these tests to fail even when no problem exists.
Step 2 At the bash prompt, enter the command reboot -n to bring down the NP. If your system has two NPs, do the following to reboot the second one:
Step 3 Enter `. to get a TCS hub prompt.
Step 4 From the TCS hub, enter reset <slot#> to reset each slot that has a line card in it. (Do not reset the switch card or NP slots.)
Step 5 Enter connect <slot#> to return to the NP, then press Return to display a menu of boot options.
Step 6 At the menu's Option prompt, enter 6, as shown below.
Step 7 The system displays the following message and a boot prompt. Enter the string shown below to load the system monitor, which you use to load the diagnostics.
Step 8 When the system monitor finishes loading, you see an identifying message and a prompt, as shown below. To load diagnostics, enter the command shown, replacing <slot#> with the number of the card you want to test.
Step 9 Wait about 5 minutes for the diagnostics to load. Then enter `. to return to the TCS hub.
Step 10 At the TCS hub prompt, use the command connect <slot#> to connect to the card you just loaded.
Step 11 Run the desired tests.
The MSC tests listed below fail if they are run on a system that does not have looping plugs installed on the I/O ports. (In field diagnostics, these tests are invoked when you use the test command's -l switch.) If you do not have looping plugs installed, it is recommended that you avoid running these tests:
The medium-speed line card memory tests listed below take longer than one minute to run. Some take many minutes. (In field diagnostics, these tests are invoked when you use the test command's -x switch.)
The packet line card tests listed below send data through the switch card. (In field diagnostics, these tests are invoked when you use the test command's -s switch.) Take the LS2020 node off line before running these tests. Do not run them on a system that is passing traffic. (If the node is running, these tests may fail when they would otherwise pass. In addition, the "bad" data passed to the switch by the tests may cause traps.)
To run these tests, use the procedure below to disable the system and all the other cards in the chassis, and then to load the diagnostics into the card you wish to test. This procedure prevents the other cards from sending packets to the card under test that cause these tests to fail even when no problem exists.
Step 2 At the bash prompt, enter the command reboot -n to bring down the NP. If your system has two NPs, do the following to reboot the second one:
Step 3 Enter `. to get a TCS hub prompt.
Step 4 From the TCS hub, enter reset <slot#> to reset each slot that has a line card in it. (Do not reset the switch card or NP slots.)
Step 5 Enter connect <slot#> to return to the NP, then press Return to display a menu of boot options.
Step 6 At the menu's Option prompt, enter 6, as shown below.
Step 7 The system displays the following message and a boot prompt. Enter the string shown below to load the system monitor, which you use to load the diagnostics.
Step 8 When the system monitor finishes loading, you see an identifying message and a prompt, as shown below. To load diagnostics, enter the command shown, replacing <slot#> with the number of the card you want to test.
Step 9 Wait about 5 minutes for the diagnostics to load. Then enter `. to return to the TCS hub.
Step 10 At the TCS hub prompt, use the command connect <slot#> to connect to the card you just loaded.
Step 11 Run the desired tests.
The PLC tests listed in this section fail if they are run on a system that does not have looping cables installed on the I/O ports. (In field diagnostics, these tests are invoked when you use the test command's -l switch.) The individual tests vary depending on whether your PLC is paired with a serial access card, an FDDI access card, an Ethernet access card, a fiber Ethernet access card, or a CEMAC. If you do not have looping cables installed, it is recommended that you avoid running these tests.
The packet line card memory tests listed below take longer than one minute to run. Some take many minutes. (In field diagnostics, these tests are invoked when you use the test command's -x switch.)
The cell line card tests listed below send data through the switch card. (In field diagnostics, these tests are invoked when you use the test command's -s switch.) Take the LS2020 node off line before running these tests. Do not run them on a system that is passing traffic. (If the node is running, these tests may fail when they would otherwise pass. In addition, the "bad" data passed to the switch by the tests may cause traps.)
To run these tests, use the procedure below to disable the system and all the other cards in the chassis, and then to load the diagnostics into the card you wish to test. This procedure prevents the other cards from sending packets to the card under test that cause these tests to fail even when no problem exists.
Step 2 At the bash prompt, enter the command reboot -n to bring down the NP. If your system has two NPs, do the following to reboot the second one:
Step 3 Enter `. to get a TCS hub prompt.
Step 4 From the TCS hub, enter reset <slot#> to reset each slot that has a line card in it. (Do not reset the switch card or NP slots.)
Step 5 Enter connect <slot#> to return to the NP, then press Return to display a menu of boot options.
Step 6 At the menu's Option prompt, enter 6, as shown below.
Step 7 The system displays the following message and a boot prompt. Enter the string shown below to load the system monitor, which you use to load the diagnostics.
Step 8 When the system monitor finishes loading, you see an identifying message and a prompt, as shown below. To load diagnostics, enter the command shown, replacing <slot#> with the number of the card you want to test.
Step 9 Wait about 5 minutes for the diagnostics to load. Then enter `. to return to the TCS hub.
Step 10 At the TCS hub prompt, use the command connect <slot#> to connect to the card you just loaded.
Step 11 Run the desired tests.
The CLC tests listed below fail if they are run on a system that does not have looping plugs installed on the I/O ports. (In field diagnostics, these tests are invoked when you use the test command's -l switch.) If you do not have looping plugs installed, it is recommended that you avoid running these tests:
The cell line card memory tests listed below take longer than one minute to run. Some take many minutes. (In field diagnostics, these tests are invoked when you use the test command's -x switch.)
This section alphabetically lists and describes selected commands that are available in LS2020 hardware diagnostic packages. Many commands are available in all three packages; others are specific to one or two packages. Each entry lists the packages in which the command is available.
Note LS2020 diagnostics contain many commands that are not listed in this section. Such commands are for use by support personnel only.
Causes the specified command to loop indefinitely. For example, the arun command runs all tests once; !arun cycles through all the tests repeatedly until you stop the loop, or, if stop on fail mode is on, until a test fails.
Without argument: Displays a list of available commands.
With argument: Displays information on the specified command.
In PLC diagnostics: access [cemac | ethernet | fddi | fiberenet | serial]
In CLC diagnostics: access [oc3 | t3 | e3 | t1e1]
With no argument, displays the type of access card installed with the line card under test. With an argument, forces activation of the access card tests for the access card type indicated.
Availability: PLC and CLC diagnostics
Runs all tests once. Not recommended if you do not have looping plugs or if you are running diagnostics remotely, as this command runs tests that require looping plugs.
Checks the status of the battery for the NP's battery-backed RAM. A screen display tells you that the battery is OK, or that it is low. The results of this command are valid only the first time the command is executed after powering up the NP. To get valid results again, you must power cycle the board.
In NP diagnostics: Causes the green RDY LED and/or the yellow FLT LED on the NP bulkhead to blink, turn on, or turn off.
In PLC and CLC diagnostics: Causes LNS OK LED on the bulkhead to blink (on) or not blink (off) during long-running tests. Blinking gives an indication that the tests are still running.
Changes the diagnostics command prompt. Maximum prompt length is 30 characters.
Specifies the count, or number of times the selected tests will be executed when you use the run command. Use cnt with no argument to display the current loop count.
Deselects all selected tests, a particular test, or a range of tests.
Displays the firmware revision levels of the switch interface daughterboard's PCP, CMP, and FSU digital signal processors.
Displays the current test run environment as selected with the mod command.
Runs selected tests (with no argument), or specified tests. The switches, which temporarily override the mode settings, are as follows:
execute is the same as run and go.
You can also run tests using the execute or go commands, or by typing specific test numbers or ranges of numbers. (For example, enter 22 to run test 22.) You can use the switches for the run command with test numbers as well. Thus, for example, these two commands both cause tests 22 through 24 to loop indefinitely:
Halts the diagnostics, resets the board, and transfers control to POST. (Same as quit.)
Formats the diskette in the floppy drive.
Displays information on the floppy disk drive, including firmware revision level and model number.
Runs the specified test or range of tests. go is the same as execute and run.
Displays the last 50 commands entered. This command is useful in conjunction with ^P, which you can use to yank previous commands from the history buffer.
Turns the channel LEDs on the line card bulkhead on or off. Without an argument, led flashes the LEDs in succession until you press any key to stop the test. led on turns all the LEDs on; led off turns them all off. In conjunction with the on/off argument, the channel argument lets you turn particular LEDs on or off. On medium-speed cards, the channels are 0 and 1; on low-speed cards, the channels are 0 - 7. The following command turns LED 0 on:
Availability: LSC and MSC diagnostics
Sets the loop counter to the specified number. When you use execute, go or run, the selected tests repeat, or loop, the specified number of times.
Lists selected tests (with no argument), all tests, a specific test, or a range of tests. (A range is expressed with a dash. For example, you might enter lst 1-6.)
In PLC and CLC diagnostics, tests are numbered hierarchically using both decimal and whole numbers. Similar tests are grouped together under the same number. For example, all the access card tests in PLC diagnostics are subtests of test number 55, and are numbered 55.01 to 55.15. If you enter lst or list in PLC or CLC diagnostics, only the top-level tests are listed. Enter lst all to list all the tests, including subtests.
Lists all installed macros. Refer to the section "Macros ," later in this chapter, for information on installing and using macros.
Sets up the test environment, where mode is one of the following:
0 turns the specified mode off; 1 turns it on. For example, mod sof = 1 turns stop on fail mode on. 0 and 1 can be replaced with off and on. Thus, mod sof = on has the same effect as mod sof = 1.
Halts the diagnostics, resets the board, and transfers control to POST. (Same as exit.)
Displays information identifying the current revision of the diagnostics. rev is the same as ver.
Runs selected tests (with no argument), or specified tests. The switches, which temporarily override the mode settings, are as follows:
run is the same as execute and go.
You can also run tests using the execute or go commands, or by typing specific test numbers or ranges of numbers. (For example, enter 22 to run test 22.) You can use the switches for the run command with test numbers as well. Thus, for example, these two commands both cause tests 22 through 24 to loop indefinitely:
Resets the SCSI bus that communicates with the hard and floppy disk drives.
Selects the test or tests to be run. The argument can be a single test number, a range of numbers (6 - 12, for example), or all (select all tests). Use run to execute selected tests. Use dsel to deselect tests.
Displays the status of selected tests (with no argument); all displays status for all tests; clr clears the status of selected tests; and fail displays the status of failed tests only. To display detailed status, use status and help together:
The help display explains the error codes used in the status display.
Displays temperature readings for the card under test.
Displays the current setting of the NP's time of day clock in Greenwich Mean Time.
Displays information identifying the current version of the diagnostics. ver is the same as rev.
Displays voltage information for the card under test, as measured and reported by the TCS.
Any command can be abbreviated to the shortest string that uniquely identifies it in its diagnostic package. For example, you can enter ve to execute the ver (version) command.
Each diagnostics package lets you configure up to five macros, numbered 0 through 4. (Macros 0 and 1 are preconfigured to run sets of NP, LSC, and MSC diagnostic tests.) A macro can be a command or string of commands. Use the following syntax to install a macro:
Where x is a macro number (0 - 4), and command is a command or a chain of commands.
In the following example, two macros are installed; the second incorporates the first.
To execute a macro, enter its number preceded by an underscore: for example, _1. To list all the installed macros, use the macro command.
Posted: Wed Jan 22 23:49:35 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.