|
|
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:
Also, look at the appendix "LEDs," which explains the different LED states, and the appendix "Diagnostic Tests," which lists all the diagnostic tests available for network processor and line cards.
Before removing any components from the chassis, read these safety instructions.
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 or electrostatic discharge (ESD) can damage electronic components. Before you expose circuitry, make sure that your body, the rack, and the circuit boards are at the same ground potential. 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.
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.
General troubleshooting tasks help you identify faults in NPs, switch cards, and line cards, and they are the only means of identifying faults in subsystems not covered by POST or diagnostics, such as blowers and power supplies. These tasks can be performed before, after, instead of, or in addition to running the diagnostic software. Some of these procedures require you to be in the same room with the faulty system; others can be performed remotely.
Table 3-1 lists symptoms and recommendations by component. Before referring to the table or running diagnostics, first do the following:
If a card's fault (FLT) LED is lit, see the appendix entitled "LEDs" for a list of possible causes and solutions.
For information on replacing FRUs and returning failed FRUs to Cisco, refer to the chapter entitled "Replacing FRUs."
Table 3-1 Symptoms and Recommendations by Component
| Component | Symptom | Recommendation |
|---|---|---|
| Switch card | Test the switch card's switching fabric by running tests that loop data through the switch card on NPs and line cards in every slot in the chassis. |
|
The POST results in failure. (The FLT LED on the card's bulkhead stays lit, and checking the POST results, as directed in the section "Power-on Self Test," shows a problem.) |
||
Diagnostics that loop data through the switch card result in failure of two or more function cards. |
||
Traffic is not passing through the switch card(s), but the line cards and NPs are OK. |
||
The system has data transmission problems that do not go away when you replace the FRU that appears to be failing, or that occur in several FRUs simultaneously. |
Troubleshoot midplane; if problem is not with midplane, replace switch card. |
|
The switch card cannot be fully inserted into its slot. (This probably indicates damage to the connectors on either the card or the midplane.) |
Inspect all the connectors; if you find damage, replace the card or the midplane. |
|
| NP cards | 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. |
|
POST fails (the FLT LED on the card's bulkhead stays lit, and checking the POST results as directed in the section "Power-on Self Test" shows a problem). |
||
The NP fails even when moved to the other slot. (If the card fails in one slot but operates properly in the other, suspect a problem with the midplane.) |
||
Switch NP card with its backup. If it still fails, replace it. |
||
The NP or its access card cannot be fully inserted into its slot. (This probably indicates damage to the connectors on either the card or the midplane.) |
Inspect all the connectors; if you find damage, replace the card or the midplane. |
|
This could indicate 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. Replace NP card. |
||
| Interface modules | Card fails. Can't tell if the problem is with the line or access card. |
For example, if you swap one cell line card with another and the problem persists, the access card is probably at fault. If the problem goes away, the first line card is probably the source of the problem.
|
Look at the back of the chassis. The access card behind the line card must be compatible with the line card. For example, a low-speed line card requires a low-speed access card. See the chapter entitled "Interface Modules" for more information. |
||
Make sure the FDDI cables for each port are attached to the proper connectors. If you are not sure, try reversing the cables on the A and B connectors. (If the cables are properly keyed, you will not be able to misconnect them.) |
||
A serial access module, a low-speed module, or an E1 circuit emulation (CEMAC) module fails to come up. |
Make sure the interface jumpers on the access card are set properly. See the chapter "Hardware Configuration" for more information on interface jumpers. |
|
There are signal quality problems with a physical interface on an access card. |
|
|
POST results in failure. (The FLT LED on the line card's bulkhead stays lit, and checking the POST results as directed in the section "Power-on Self Test" shows a problem.) |
||
A card fails even when moved to another slot. (When you move a line card, be sure to pair it with an appropriate access card; likewise, when you move an access card, pair it with an appropriate line card.) |
||
Run field or manufacturing diagnostics; consider replacing card. |
||
The line card or access card cannot be fully inserted into its slot. This probably indicates damage to the connectors on either the card or the midplane. |
Inspect all the connectors; if you find damage, replace the card or the midplane. |
|
Two or more ports are passing no traffic, dropping many cells, or flapping—coming up and down repeatedly. |
Refer to the looping tests described in the LightStream 2020 Network Operations Guide . (If only one port has symptoms, look for a problem with the line, the external DSU/CSU if one is present, the access card, or the remote device.) |
|
| Blowers | The temperature on one or more cards is out of the recommended range. This is indicated by the appearance of the temperature trap, NPTMM_6. |
Confirm the card temperature with the CLI command show tcs <slot#> or the TCS command show <slot#> temperature. Confirm the source of the problem as described below before replacing a blower. If you have an out-of-range temperature but the blowers are working, make sure the chassis is properly closed (all components, cards, bulkheads, and filler panels must be in place), and that vents in the chassis and the rack panels are not blocked. Also check that the temperature in the system area does not exceed 104\xb0 F (40\xb0 C). |
The system is powered on, but the blower is not turning, making noise, or exhausting air. |
Replace blowers Verify this by looking through the holes in the cover of the rear blower and by removing the front blower cover to examine the front blower. CAUTION: 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. |
|
Two minutes after the system is powered on, the blowers fail to reduce their speed in a room temperature environment. |
Replace blowers. 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. |
|
The system is powered on, but the blower's green LED is off. |
Replace blowers. The LED indicates that the blower is turning at a rate of at least 1500 rotations per minute. You can see the LED through the holes in the rear blower cover; you must remove the blower cover to see the front blower's LED. |
|
| Bulk power trays | In a system with one power tray, no power is present if the power tray is faulty. |
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 read "Empty.") |
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. |
|
| Disk assemblies | ||
Check the write protect switch on the diskette. Otherwise, replace disk assembly. |
||
The system does not boot or you are unable to access the hard disk. |
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, reinstall the software, using the procedure 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. |
|
In a system with two NPs, the primary NP appears to fail and the backup takes over—but the failed NP passes diagnostics. |
||
| Midplane | A card fails in one slot but operates normally in other slots. |
|
Data transmission problems do not go away when you replace the FRU that appears to be failing, or the problems occur in several FRUs simultaneously. |
Check switch card. If switch card is okay, the problem is probably with the midplane. |
|
You cannot fully insert a card into its slot. This probably indicates damage to the connectors on either the card or the midplane. |
Inspect all the connectors; if you find damage, replace the card or the midplane. |
|
Electrical problems (including electrical failure) do not go away when you replace the FRU that appears to be failing, or they occur in several FRUs simultaneously. Electrical problems include out-of-range voltages, indicated by trap NPTMM_6. |
Check card voltages in the CLI using the command show tcs <slot#> voltage, as shown below, or from TCS using the command show <slot#> voltage all. |
LS2020 hardware diagnostics are used to discover the location of hardware faults.The diagnostics reside on each NP's hard disk, and are for testing NP cards, line cards, associated access cards, and the disk drives associated with the NP.
You use one of the following to diagnose hardware problems:
Manufacturing diagnostics are initiated with the CLI test -m command; however, a manual loading procedure is required to start manufacturing diagnostics on a system with a single NP module. For more information, see the section "Manufacturing Diagnostics ." (For a complete list of manufacturing diagnostics tests, see the appendix "Diagnostic Tests.")
Note Manufacturing diagnostics and field diagnostics can only be used on a backup NP, not an active one. For more information, see the section entitled "Using the test Command on a Backup NP."
You can use field or manufacturing diagnostics on a line card or a backup NP while the rest of the system continues to operate. With interface modules, only the card under test comes out of service during the diagnostics. In systems with backup NP modules, the same is true. In systems that have a single NP module, you must take the system off line to test its NP card.
You can run diagnostics remotely over a Telnet or modem connection or locally from a console connected to the console port. However, running diagnostics on the sole NP in a nonredundant system requires a local console or a modem.
The remainder of this chapter provides procedures for working with POSTs, field diagnostics, and manufacturing diagnostics. The last section, "Command Reference ," summarizes key commands available in the diagnostic packages.
Power-on self test (POST) diagnostics are the first line of defense for identifying hardware problems. These diagnostics run automatically on each card whenever the system or the slot is powered up or when the card is reset; they take about 90 seconds. There are POSTs for NP cards and line cards. The POST for each line card also checks the accompanying access card.
To display POST results, use one of these commands:
Typical output from the TCS show <slot#> post command looks like this:
Typical output from the TCS show <slot#> post all command looks like this:
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. Generally, a card that fails POST needs to be replaced.
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 appendix "LEDs" 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 field or manufacturing diagnostics to confirm that a problem exists.
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. Field diagnostics is a subset of manufacturing diagnostics, and is designed to provide information quickly and easily. For your own convenience, you should run field diagnostics before resorting to the more complex and time consuming manufacturing diagnostics.
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.
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. If using multiple switches with the test command, give each switch a - (minus) sign and separate each switch with a space. 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.
Typical field diagnostic tests takes about 15 minutes to run. To display the status of the tests, enter test <slot#> -r.
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.
Typical output from field diagnostics, using the test -p command, looks like this:
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 are 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 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:
This command reports whether the card passed or failed the tests. It also tells you if the tests are still running. For example, if the tests are still running, a message like the following one is displayed:
If the tests are still running, wait for them to finish and run the command again.
Step 7 If the tests indicate that the card is all right, go to the next step.
If the tests result in failure, 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 that information to the repair depot, along with the failed card.
Step 8 To return a card to service after running diagnostics, use the following command:
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.
The test command can only be run on a backup NP, not an active NP. The first procedure below explains how to force the active and backup NPs to switch roles; this is necessary only if the NP you want to test is currently active. The second procedure tells you how to run the diagnostics.
Note If your system has only one 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.
If the NP you want to test is currently operating as the backup, skip to the next procedure, "Testing the Backup NP." 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 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 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 you want to test. The example below shows slot 1 being used.
Step 5 When you connect, you will see a login prompt. Log in as root or fldsup.
Step 6 At the prompt, enter reboot -n.
Step 7 Enter `. to return to the TCS hub.
Step 8 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 shows a connection 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 are 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 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:
This command indicates whether the card passed or failed or whether the tests are still running. For example, if the tests are still running, a message like the following one is displayed:
If the tests are still running, wait for them to finish and run the command again.
Step 9 If the NP passed the tests, go to the next step. If it 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.
Manufacturing diagnostics include a full array of tests, allowing you to diagnose problems with memory, NetTime, peripherals, the Test and Control System, and so on. A complete list of the tests appears in the appendix "Diagnostic Tests." This section provides procedures for running manufacturing diagnostics, and lists some of the more common testing routines.
This section contains the following procedures:
You can use the manufacturing diagnostics to test NPs and line cards. Use the procedure in this section to load the manufacturing diagnostics, then go to the section, "Running Manufacturing Diagnostics " for further instructions.
Note In a redundant system, manufacturing diagnostics can only be used on the backup NP, not an active one. Instructions for forcing the active NP to be backup are in the section "Field Diagnostics." If your system has only one NP, see the procedure "Loading Manufacturing Diagnostics into a Lone NP" later in this chapter.
Step 2 Log into the node to be tested, start CLI and enter protected mode:
Protected mode invokes protected mode in the CLI, allowing you to use test and other protected commands. You must enter a password to enter protected mode.
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.
This command 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.
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:
Step 5 For instructions on executing tests, see the section, "Running Manufacturing Diagnostics ."
Note You may need to press Return after you see the word "connected" in order to display the diagnostics banner and command prompt.
You must use manufacturing diagnostics to test the single NP in a nonredundant system. 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. 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.
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.
connect 1 establishes a terminal connection to the card 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, you will enter a command that tells the NP to load the file diag_np1.aout:
After entering this command, 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.
Read this section for information on running manufacturing diagnostics. You can run either sets of tests or specific tests with the following commands:
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.
Depending on the line card and access card being tested, it can take from 10 minutes to an hour for the run command to complete its test routine.
Typical output from the run command looks like this:
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.
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 sections.
Note See the next heading, "NP Tests with Special Requirements ," 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:
Step 3 Use the status command to learn 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 run diagnostics on a lone 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.
Tests that write data to the hard disk—Tests 43 to 46 write data to the hard disk. Because these tests are disabled by default, you must explicitly enable them in order to run them. Do not run the tests, though, unless you are testing a new disk drive or you think there may be a fault in your hard disk.
Tests that send data through the switch card—Tests 78, 80, and 82 to 93 send data through the switch card. Take the LS2020 node off line before running these tests (see the procedure described later in this section). 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. Doing so 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.
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.
Tests That Require Looping Plugs—Tests 13, 14, and 33 result in failure 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, you should not run these tests:
Tests That Require a Scratch Diskette—Tests 47 to 49 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, you should not run these tests.
Long-Running Memory Tests—Tests 08, 09, and 93 take longer than 1 minute to run. Some take many minutes. (In field diagnostics, these tests are invoked when you use the test command -x switch.)
BB-RAM Clock Test—The NP diagnostics include tests for the battery-backed RAM clock that keeps time for the whole system. If the tests result in failure, 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 1 minute or file consistency problems between the two NPs may result.
If any tests result in failure, replace the card being tested. Replacement procedures appear in the chapter "Replacing FRUs."
If a card passes all tests 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 line card tests. The procedure is good for a low-speed line card (LSC), a medium-speed line card (MSC), a packet line card (PLC), or a cell line card (CLC). Once you run the tests, go to the "Remedial Steps" section for help in working with the results of the tests you have run and for more information on the test you are running.
If you need to return to CLI before completing the diagnostics session, you can enter 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.
You are assumed to have already loaded the diagnostics onto the card, with the procedures provided earlier in this chapter.
Note PLC and CLC diagnostics determine which type of access card is installed with the line card under test. Tests appropriate for that access card are then enabled. To find out the access card type, use the access command. (See the "Command Reference " section later in this chapter.)
Step 2 To run or rerun a test or group of tests, use the run command and specify the test numbers. For example:
(To list tests and test numbers, use the lst all command.)
Note When simultaneously testing multiple CLCs in the same chassis, you should deselect all NetTime tests.
Step 3 Use the status command to obtain the status of diagnostic tests. Use status fail to obtain information on tests that have failed.
Step 4 For explanations of the error codes used in the status display, enter help and the number of the test in question. For example:
Step 5 If the card passes the diagnostics, exit from the diagnostics and return the card to active mode:
Step 6 When the login prompt appears, log in to the node, enter CLI protected mode, and use the set command to reset the card's status to active:
Replace <slot#> with the slot number of the card you were testing.
Table 3-2 lists the tests with special requirements that pertain to the four different line card types listed here (low-speed, medium-speed, PLC, and CLC). The appendix "Diagnostic Tests" has more information on the tests listed in the table. The paragraphs following Table 3-2 discuss the three test categories that appear in the table: (1) tests that send data to the switch card, (2) tests that require looping plugs, and (3) long-running memory tests.
Table 3-2 Line Card Tests with Special Requirements
Tests That Send Data to the Switch Card—Table 3-2 lists line card tests that send data through the switch card. (In field diagnostics, these tests are invoked when you use the test command -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 following procedure to (1) disable the system and all the other cards in the chassis and (2) load the diagnostics into the card you wish to test. This procedure prevents the other cards from sending packets to the card under test. Such packets could 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, and press Return to display a menu of boot options.
Step 6 At the menu's Option prompt, enter 6.
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. Replace /diag_xxx.aout with an entry appropriate for the type of card you are testing: /diag_lsl.aout for a low-speed line card, /diag_msl.aout for a medium-speed card, /diag_plcl.aout for a packet line card, and /diag_clcl.aout for a cell line card.
Step 9 Wait about 5 minutes for the diagnostics to load, and 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.
Tests That Require Looping Plugs—Table 3-2 lists the tests that fall in this category for each card type. The following points pertain to these tests:
Long-Running Memory Tests—The line card memory tests listed in Table 3-2 take longer than 1 minute to run. Some take many minutes. (In field diagnostics, these tests are invoked when you use the test command's -x switch.)
When you have completed the line card test procedure, you may need to take one or more of the steps outlined here. Refer to the paragraphs that pertain to the type of card you are testing.
If the card fails test 55 (or any of its subtests), there is a problem with the access card. Replace the access card, using the procedure described in the chapter "Replacing FRUs."
If a card fails any other test, replace the card being tested, using the procedures described in the chapter "Replacing FRUs."
If the card passes all tests but you still experience a problem, test the other cards in the chassis. Consider replacing any cards that fail diagnostics. If the problem persists, look for causes outside the LS2020 hardware, including leased lines and edge devices.
If the card fails test 49 (or any of its subtests), there is a problem with the access card. Replace the access card, using the procedure described in the chapter "Replacing FRUs."
If a card fails any other test, replace the card being tested, using the procedure described in the chapter "Replacing FRUs."
If the card passes all tests but you still experience a problem, test the other cards in the chassis. Consider replacing any cards that fail diagnostics. If the problem persists, look for causes outside the LS2020 hardware, including leased lines and edge devices.
If the line card fails a test, you may need to replace it or its access card. (Replacement procedures are in the chapter "Replacing FRUs.") The number of the test that the card failed determines which card to replace.
Note Tests 111 to 118 result in failure if you run them in an operating node using test -m. This failure does not indicate a problem, though, and should be ignored. The card passes test 43, 46, and 50 only if looping plugs are installed. Disable or disregard these tests if you are testing without looping plugs.
If the card passes all tests but you still experience a problem, test the other cards in the chassis. Consider replacing any cards that fail diagnostics. If the problem persists, look for causes outside the LS2020 hardware, including leased lines and edge devices.
If the card fails a test, you may need to replace it or its access card. (Replacement procedures are in the chapter "Replacing FRUs.") The number of the test that the card failed determines which card to replace.
Note Ignore any failure in tests 70 to 80 if you run them in an operating node using test -m. Only the E3 access card can pass test 95; disable or disregard that test if you are testing a T3 card. Tests 93 and 94 require that looping plugs be installed; disable or disregard them if you are testing without looping plugs.
If the card passes all tests but you still experience 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 alphabetically lists and describes selected commands that are available in LS2020 hardware diagnostic packages. Each entry in Table 3-3 lists the packages in which the command is available. All packages means the command will work with any line card.
Note LS2020 diagnostics contain many commands that are not listed in this section. Such commands are for use by customer service personnel only.
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.
Table 3-3 Hardware Diagnostic Commands
Posted: Wed Jan 22 23:52:41 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.