Home
>
Lucent Technologies
>
Communications System
>
Lucent Technologies DEFINITY Enterprise Communications Server Release 6 Instructions Manual
Lucent Technologies DEFINITY Enterprise Communications Server Release 6 Instructions Manual
Have a look at the manual Lucent Technologies DEFINITY Enterprise Communications Server Release 6 Instructions Manual online for free. It’s possible to download the document as PDF or print. UserManuals.tech offer 413 Lucent Technologies manuals and user’s guides for free. Share the user manual or guide on Facebook, Twitter or Google+.
DEFINITY Enterprise Communications Server Release 6 Maintenance for R6r Volumes 1 & 2 555-230-126 Issue 2 January 1998 Responding to Alarms and Errors Page 5-11 Troubleshooting a Duplicated SPE 5 Start by determining the time of the interchange. Then, examine the alarm and error logs as described in the following section. If that does not identify the problem, proceed to the next section, which describes a sequence of tests of the standby SPE. Determining the Time of a Spontaneous Interchange There are 2 ways to tell at what time a spontaneous interchange has taken place: nSTBY-SPE Error 103 This error is logged with a minor alarm whenever a spontaneous interchange takes place. The time recorded for the first occurrence of the error is the approximate time of interchange. The error is logged against the carrier of the SPE that was active before the interchange. This should now be the standby SPE, assuming no further interchanges have taken place. nDisplay initcauses The display initcauses command displays a record of all system resets. In the following example, a spontaneous interchange into the B carrier SPE took place at 2:53 P.M. The standby SPE (B) transitioned into active mode with a WARM restart, (reset level 1). Cause Action Escalated Carrier Time Interchange 1 no 1B 11/27 14:53
DEFINITY Enterprise Communications Server Release 6 Maintenance for R6r Volumes 1 & 2 555-230-126 Issue 2 January 1998 Responding to Alarms and Errors Page 5-12 Troubleshooting a Duplicated SPE 5 Examining the Alarm and Error Logs The system may have had time to log alarms or errors against the fault the caused the interchange. Proceed through the steps summarized in the following flowchart. Examine only major alarms with a timestamp near the time of interchange, and whose carrier designation is the current standby SPE (the SPE interchanged out of). Include any resolved alarms meeting this description. Figure 5-2. Determining the Cause of an SPE Interchange Use the SYSTEM error table following this chart to determine which SPE component is implicated. This indicates a serious processor/memory bus problem. Busyout or, preferably, lock the standby SPE to prevent an interchange, and escalate the problem. Consult MO documentation for PKT-INT. Is there a Major alarm against the standby SW-CTL? no no no no no no no no Consult MO documentation for TAPE.Consult the MO documentation for the indicated component. yes yes yes yesReplace the standby MSSNET circuit pack. yes yes Consult CARR-POW in Chapter 9. yes yesIf handshake is down (checkstatus spe), replace the alarmed standby circuit pack If handshake is up, execute a test long clear of the alarmed component and consult documentation for that MO in Chapter 9. Proceed to the next ¯owchart, Testing the Standby SPE Is there a TAPE error 3585 with aux code 408?Is there a PKT-INT error 100? Is there an error 150 against any SPE component?Is there a SYSTEM error 6002, 6003, 6102, or 6103? Enterdisplay errorsand look for unalarmed errors for SPE components, CARR-POW and SYSTEM. Is there a SYSTEM error 6001 or 6101. Enterdisplay alarmsfor categoriesSPE andenviron. Are there any major alarms against CARR-POW? Are there major alarms against other SPE components? All relevant alarms must be timestamped at or near the time of interchange.
DEFINITY Enterprise Communications Server Release 6 Maintenance for R6r Volumes 1 & 2 555-230-126 Issue 2 January 1998 Responding to Alarms and Errors Page 5-13 Troubleshooting a Duplicated SPE 5 Auxiliary Data for SYSTEM Errors 6002, 6003, 6102, and 6103 The following table shows which components are indicted by the auxiliary error codes found by using the preceding flowchart. Once you have identified the faulted component, consult the section for that MO. AUX Data Implicated Maintenance Object 16384 PROCR 16385 MEM-BD 4137 PKT-INT 16391 SW-CTL 16386 SYSAM 16389 DUPINT 16392 HOST-ADAPTER 16397 TAPE 16398 DISK
DEFINITY Enterprise Communications Server Release 6 Maintenance for R6r Volumes 1 & 2 555-230-126 Issue 2 January 1998 Responding to Alarms and Errors Page 5-14 Troubleshooting a Duplicated SPE 5 Testing the Standby SPE The system may not have had time to log errors against the failed component that caused the spontaneous interchange. If you have progressed through the preceding flowchart without determining the cause of interchange, test the standby for faults by proceeding through the following steps. Figure 5-3. Testing the Standby SPE Consult MO documentation for SW-CTL. Enter \f(HBtest spe-standby long\fH and wait for all tests to execute. Do all tests except for STBY-SPE test 855 pass? Busyout the standby SPE and enter \f(HBtest dup long\fH. Do all DUPINT and DUP-CHL tests pass? When call service needs allow for a possible disruption, release the standby SPE and wait for it to refresh (\f(HBstatus spe\fH). Enter \f(HBreset system interchange\fH. Did the planned interchange succeed? Busyout the standby SPE and enter \f(HBtest dupint long\fH. Do all tests pass? Do all tests pass? Do all tests pass? Run the long test sequence on the active SW-CTL. Enter \f(HBtest stored data long\fH. yes yes yes yes yes yes yes yes Have you completed the steps in the preceding ¯owchart? no no no no no no no Follow normal esclation procedures. Enter \f(HBstatus spe\fH. Is the standby SPE fully refreshed with handshake up?Troubleshoot using MO documentation for STBY-SPE. Consult MO documentation for the component whose test failed. Consult MO documentation for the component whose test failed. Consult MO documentation for DUPINT or DUP-CHL. Consult the following discussion of planned interchange failure. Consult MO documentation for DUPINT.
DEFINITY Enterprise Communications Server Release 6 Maintenance for R6r Volumes 1 & 2 555-230-126 Issue 2 January 1998 Responding to Alarms and Errors Page 5-15 Executing a Planned SPE Interchange 5 Executing a Planned SPE Interchange Planned SPE interchanges are initiated on demand by the reset system interchange command, or automatically by scheduled daily maintenance. The latter is administered with the system-parameters maintenance screen. A planned interchange normally has no perceivable effect on service. All active calls, transient calls, system links and stimuli, and data transmission are preserved. The SYSAM-RMT port (also called the Remote Access Port) is dropped, necessitating a re-login. The duration of the interchange is approximately one minute. !CAUTION: Switching the SPE-select switches to the standby carrier causes a spontaneous interchange, not a planned one. This can disrupt service and is not a recommended procedure. Prerequisites Several conditions must be met to guarantee a non-disruptive interchange. If these are not met the system will not execute the interchange. All of these conditions, listed below, are expected to be met during normal operation. nThe SPE must not be locked by the SPE-SELECT switches. nThe standby SPE must be fully in service. That is, handshake is up, shadowing is on, memory is refreshed, and standby SPE state-of-health is “functional”. ‘‘ STBY-SPE (Standby SPE Maintenance)’’ describes how to correct a failure of any of these. nThere can be no minor alarms against the standby’s PKT-INT or SYSAM circuit packs. nThere can be no ongoing disk or tape operations on either active or standby MSS components. Wait until all such operations, such as translation saves or backup restores, are complete before requesting an interchange. SPE Interchange Failures If the above conditions are not met, or if any intermediate steps taken by the system in executing the interchange fail, the interchange is prevented. Usually, failure of a planned interchange has no effect on service. If the interchange fails after the packet interface links have migrated, the system will require a reset level 1 (warm restart) to restore the links. In such a case, no calls are dropped, and new call service resumes within 5 seconds. However, it is probable that there is a severe system problem which predates the attempted interchange.
DEFINITY Enterprise Communications Server Release 6 Maintenance for R6r Volumes 1 & 2 555-230-126 Issue 2 January 1998 Responding to Alarms and Errors Page 5-16 Executing a Planned SPE Interchange 5 If the SPE is locked by means of the SPE-SELECT switches, error 607, auxiliary data 1153, is logged against SYSTEM. If the switches are not locked and the interchange fails, an unalarmed error 605 is logged against SYSTEM. The auxiliary code associated with this error indicates which aspect of the interchange failed. Table 5-1 explains the meaning of the auxiliary codes and what corrective action to take. Table 5-1. SYSTEM Error 605 Planned Interchange Failure Aux DataSee Note Explanation 13521 Standby SOH “non-functional” 13531 Standby SOH not “functional” 13551 Handshake Communication with Standby SPE is down 13561 Memory Shadowing not enabled 13571 Standby memory not refreshed 13582 Mass Storage System was in use 13593 PKT-INT link migration failed 13601 Interchange failed1 13614 SW-CTL failure 13697 Could not suspend G3-MT connectivity1 13704Could not freeze active SW-CTL1 1371 5 Internal Error associated with processor interrupts1 13726Minor alarm on standby SYSAM or PKT-INT 1395 SPE Duplication not administered 13963 PKT-INT Link Migration failure in Begin Step1 13973PKT-INT Link Migration denied, (peer test in progress) 13983 PKT-INT Link Migration failure in Completion Step1 13993PKT-INT Link Migration failure in Finish Step1 14004Could Not Idle SW-CTL dual port RAM1 14014Could Not Refresh SW-CTL dual port RAM1 14025Internal Error (could not get duplication status) 1403 5 Unable to inhibit Standby Maintenance Monitor 14045 Failure to determine Standby SPE alarm status Continued on next page
DEFINITY Enterprise Communications Server Release 6 Maintenance for R6r Volumes 1 & 2 555-230-126 Issue 2 January 1998 Responding to Alarms and Errors Page 5-17 Executing a Planned SPE Interchange 5 Notes for SYSTEM Error 605 AUX Data: 1. Follow repair instructions in ‘‘ STBY-SPE (Standby SPE Maintenance)’’ for the particular standby SPE problem. After fixing that problem, try the interchange again. 2. Mass Storage System is in use. Check Disk and Tape LEDs for activity. Wait until all MSS activity completes, then try the interchange again. If the problem persists, check for alarms and errors against MSS components and follow repair procedures in Chapter 9, ‘‘ Maintenance Object Repair Procedures’’. 3. Test the PKT-INT on both carriers with the long test sequence. Follow procedures for ‘‘ PKT-INT (Packet Interface Circuit Pack)’’ in Chapter 9, ‘‘Maintenance Object Repair Procedures’’. Once all tests of both PKT-INTs pass, try the interchange again. 4. Consult SW-CTL service documentation. Test SW-CTL on both carriers with the long test sequence. Follow repair instructions for any failures. Once all tests of both SW-CTLs pass, try the interchange again. 5. Make sure the standby SPE is refreshed Then try the interchange again. 6. Examine alarm log to determine which of PKT-INT or SYSAM circuit packs has a minor alarm against it. Consult service documentation of whichever is alarm to clear 7. Check for errors/alarms against active SPE’s SYSAM. If you find any, consult SYSAM service documentation. If you find none, and if all tests of the SYSAM long sequence pass, try the interchange again. 8. Run test duplication-interface long and follow instructions for any test that does not pass. 1. A WARM restart is required.14063 Active SPE’s PKT-INT in held-reset state 14188 Active Duplication Interface circuit pack is in a bad state and needs to be reset. 25005 Internal Software failure1 (sometimes) Table 5-1. SYSTEM Error 605 Planned Interchange Failure — Continued Aux DataSee Note Explanation Continued on next page
DEFINITY Enterprise Communications Server Release 6 Maintenance for R6r Volumes 1 & 2 555-230-126 Issue 2 January 1998 Responding to Alarms and Errors Page 5-18 Fiber Fault Isolation Procedure 5 Fiber Fault Isolation Procedure Use the following procedure to isolate faults on a fiber-link. When troubleshooting a system with duplicated Port Network Connectivity (PNC), first busyout pnc-standby before busying out a standby Fiber-Link (FIBER-LK), Expansion Interface (EXP-INTF), Switch Node Interface (SNI) or DS1 Converter (DS1C). At the end of this section is a description of the loopback tests run and a pinout of the cable used to connect the DS1 C to DS1 facilities. nA busyout of any of these components on a simplex PNC is destructive. nBe sure to release all busied out components after completing the tests. Steps: 1. Enter display alarms with category pnc. Are there any on-board alarms? If so, replace the circuit pack(s). 2. Enter display errors for category pnc. Check for any of the following errors: If one or more of the above errors are present go to step 3. If none of the above errors are present, look for SNI-PEER errors. nIf there is one SNI circuit pack with many different SNI-PEER error types, replace the indicated SNI circuit pack nIf there are many SNI-PEER errors of the same error type, replace the indicted SNI circuit pack using the following table. Maintenance ObjectError Type FIBER-LK Any SNI-BD 513 EXP-INTF 257 769 770 1281 1537 3073 3074 3075 3076 3585 3841 3842
DEFINITY Enterprise Communications Server Release 6 Maintenance for R6r Volumes 1 & 2 555-230-126 Issue 2 January 1998 Responding to Alarms and Errors Page 5-19 Fiber Fault Isolation Procedure 5 nAfter replacing an SNI circuit pack, clear alarms by executing test board UUCSSlong clear for all alarmed EXP-INTF circuit packs. Wait 5 minutes for any SNI-BD or SNI-PEER alarms to clear. (You can speed this process with clear firmware counters [a-pnc | b-pnc] for the PNC that was repaired). nExit this procedure. 3. Enter list fiber-link to get the physical location of the fiber-link endpoints. If a DS1 CONV is administered to the fiber-link (DS1 CONV is “y”), use the display fiber-link command to get the physical location of the DS1 CONV circuit packs on the fiber-link. 4. Execute busyout fiber-link FP followed by test fiber-link FP long. If any tests in the sequence fail, proceed with step 5. If all of the tests pass, clear alarms by executing test board UUCSS long clear for all alarmed EXP-INTF circuit packs. Wait 5 minutes for any SNI-BD, SNI-PEER, FIBER-LK, or DS1C-BD alarms to clear. You can speed this process with clear firmware counters [a-pnc | b-pnc] for the PNC that was repaired. You are finished with this procedure.Error Type SNI slot 12 257 3 513 4 769 5 1025 6 1281 7 1537 8 1793 9 2049 13 2305 14 2561 15 2817 16 3073 17 3329 18 3585 19 3841 20
DEFINITY Enterprise Communications Server Release 6 Maintenance for R6r Volumes 1 & 2 555-230-126 Issue 2 January 1998 Responding to Alarms and Errors Page 5-20 Fiber Fault Isolation Procedure 5 5. For each endpoint of the fiber-link, follow this flowchart: Busyout and test board UUCSS long and record all test failures. When looking at test results, consult the explanations and illustrations of the tests, which appear at the end of this procedure. Is Board Not Assigned displayed for an EXP-INTF in an EPN? If yes, test maintenance long to release an EXP-INTF that may be held reset by an EPN Maintenance circuit pack. If No Ê Did EXP-INTF test 242 fail? If yes, replace the EXP-INTF circuit pack and the lightwave transceiver (if present) and go back to step 4. (EXP-INTF test 242 runs an on-board looparound if no lightwave transceiver is connected to the EXP-INTF.) If No Ê Did SNI test 757 fail? If yes, replace the SNI circuit pack and go back to step 4 of this procedure. If No Ê Did SNI test 756 fail? If yes, replace the SNI circuit pack and the lightwave transceiver (if present) and go back to step 4. If No Ê Did EXP-INTF test 240 fail? If yes, replace the EXP-INTF circuit pack and go back to step 4. If No Ê Did tests 238 (EXP-INTF) or 989 (SNI) fail? If yes, replace the lightwave transceivers and fiber-optic cable, or metallic cable, and go back to step 4. The faulted component can be further isolated by using the Manual Loopback Procedure described at the end of this procedure. NOTE: If a fiber out of frame condition exists and lightwave transceivers are used, check that both lightwave transceivers are of the same type, (9823a or 9823b). If they are not both the same, replace one of the lightwave transceivers so that they match. (9823A is used for