009-3235-003 - (5400R2.1.2) - Alarm and Trouble Clearing - RevB PDF

5400 Reconfigurable Switching System
Alarm and Trouble Clearing Procedures

Manual
Release 2.1.2
What’s inside...
Alarm monitoring
5400 Switch alarm and trouble clearing procedures
Standards and compliance
Service-affecting/nonservice-affecting alarms
009-3235-003 - Revision B
August 2013
Copyright© 2010-2013 Ciena® Corporation. All rights reserved.
LEGAL NOTICES
THIS DOCUMENT CONTAINS CONFIDENTIAL AND TRADE SECRET INFORMATION OF CIENA
CORPORATION AND ITS RECEIPT OR POSSESSION DOES NOT CONVEY ANY RIGHTS TO REPRODUCE
OR DISCLOSE ITS CONTENTS, OR TO MANUFACTURE, USE, OR SELL ANYTHING THAT IT MAY DESCRIBE.
REPRODUCTION, DISCLOSURE, OR USE IN WHOLE OR IN PART WITHOUT THE SPECIFIC WRITTEN
AUTHORIZATION OF CIENA CORPORATION IS STRICTLY FORBIDDEN.
EVERY EFFORT HAS BEEN MADE TO ENSURE THAT THE INFORMATION IN THIS DOCUMENT IS
COMPLETE AND ACCURATE AT THE TIME OF PUBLISHING; HOWEVER, THE INFORMATION CONTAINED IN
THIS DOCUMENT IS SUBJECT TO CHANGE.
While the information in this document is believed to be accurate and reliable, except as otherwise expressly agreed
to in writing CIENA PROVIDES THIS DOCUMENT “AS IS” WITHOUT WARRANTY OR CONDITION OF ANY
KIND, EITHER EXPRESS OR IMPLIED. The information and/or products described in this document are subject to
change without notice.
Copyright© 2010-2013 Ciena® Corporation. All Rights Reserved
The material contained in this document is also protected by copyright laws of the United States of America and
other countries. It may not be reproduced or distributed in any form by any means, altered in any fashion, or stored
in a data base or retrieval system, without express written permission of the Ciena Corporation.
Security
Ciena® cannot be responsible for unauthorized use of equipment and will not make allowance or credit for
unauthorized use or access.
Contacting Ciena
Corporate Headquarters 410-694-5700 or 800-921-1144 www.ciena.com

Customer Technical Support/Warranty
In North America 1-800-CIENA24 (243-6224)
410-865-4961
In Europe, Middle East, 800-CIENA-24-7 (800-2436-2247)
and Africa +44-207-012-5508
In Asia-Pacific 800-CIENA-24-7 (800-2436-2247)
+81-3-6367-3989
+91-124-4340-600
In Caribbean and Latin 800-CIENA-24-7 (800-2436-2247)
America 410-865-4944 (USA)
Sales and General Information 410-694-5700 E-mail: sales@ciena.com
In North America 410-694-5700 or 800-207-3714 E-mail: sales@ciena.com
In Europe +44-207-012-5500 (UK) E-mail: sales@ciena.com
In Asia +81-3-3248-4680 (Japan) E-mail: sales@ciena.com
In India +91-124-434-0500 E-mail: sales@ciena.com
In Latin America 011-5255-1719-0220 (Mexico City) E-mail: sales@ciena.com
Training 877-CIENA-TD (243-6283) E-mail: techtng@ciena.com
or 410-865-8996
For additional office locations and phone numbers, please visit the Ciena web site at www.ciena.com.
5400 Reconfigurable Switching System Alarm and Trouble Clearing Procedures Manual
Release 2.1.2 009-3235-003 Standard Revision B
Copyright© 2010-2013 Ciena® Corporation August 2013
IMPORTANT: PLEASE READ THIS LICENSE AGREEMENT (“AGREEMENT”) CAREFULLY BEFORE
INSTALLING OR USING CIENA CORPORATION (“Ciena”) SOFTWARE, HARDWARE OR DOCUMENTATION
(COLLECTIVELY, THE “EQUIPMENT”).
BY INSTALLING OR USING THE EQUIPMENT, YOU ACKNOWLEDGE THAT YOU HAVE READ THIS
AGREEMENT AND AGREE TO BE BOUND BY ITS TERMS AND CONDITIONS.
1. Right to Use License; Restrictions. Subject to these terms, and the payment of all applicable license fees,
Ciena grants to you, as end user, a non-exclusive license to use the Ciena software (the “Software”) in object code
form solely in connection with, and as embedded within, the Equipment,. You shall have the right to use the
Software solely for your own internal use and benefit. You may make one copy of the Software and documentation
solely for backup and archival purpose, however you must reproduce and affix all copyright and other proprietary
rights notices that appear in or on the original. You may not, without Ciena's prior written consent, (i) sublicense,
assign, sell, rent, lend, lease, transfer or otherwise distribute the Software; (ii) grant any rights in the Software or
documentation not expressly authorized herein; (iii) modify the Software nor provide any third person the means to
do the same; (iv) create derivative works, translate, disassemble, recompile, reverse engineer or attempt to obtain
the source code of the Software in any way; or (v) alter, destroy, or otherwise remove any proprietary notices or
labels on or embedded within the Software or documentation. You acknowledge that this license is subject to
Section 365 of the U.S. Bankruptcy Code and requires Ciena's consent to any assignment related to a bankruptcy
proceeding. Sole title to the Software and documentation, to any derivative works, and to any associated patents
and copyrights, remains with Ciena or its licensors. Ciena reserves to itself and its licensors all rights in the
Software and documentation not expressly granted to you. You shall preserve intact any notice of copyright,
trademark, logo, legend or other notice of ownership from any original or copies of the Software or documentation.
2. Audit: Upon Ciena's reasonable request, but not more frequently than annually without reasonable cause, you
shall permit Ciena to audit the use of the Software at such times as may be mutually agreed upon to ensure
compliance with this Agreement.
3. Confidentiality. You agree that you will receive confidential or proprietary information (“Confidential Information”)
in connection with the purchase, deployment and use of the Equipment. You will not disclose Confidential
Information to any third party without prior written consent of Ciena, will use it only for purposes for which it was
disclosed, use your best efforts to prevent and protect the contents of the Software from unauthorized disclosure or
use, and must treat it with the same degree of care as you do your own similar information, but with no less than
reasonable care. You acknowledge that the design and structure of the Software constitute trade secrets and/or
copyrighted materials of Ciena and agree that the Equipment is Confidential Information for purposes of this
Agreement.
4. U.S. Government Use. The Software is provided to the Government only with restricted rights and limited rights.
Use, duplication, or disclosure by the Government is subject to restrictions set forth in FAR Sections 52-227-14 and
52-227-19 or DFARS Section 52.227-7013(C)(1)(ii), as applicable. The Equipment and any accompanying technical
data (collectively “Materials”) are commercial within the meaning of applicable Federal acquisition regulations.
These Materials were developed fully at private expense. U.S. Government use of the Materials is restricted by this
Agreement, and all other U.S. Government use is prohibited. In accordance with FAR 12.212 and DFAR
Supplement 227.7202, software delivered to you is commercial computer software and the use of that software is
further restricted by this Agreement.
5. Term of License. This license is effective until terminated. Customer may terminate this license at any time by
giving written notice to Ciena [or] and destroying or erasing all copies of Software including any documentation.
Ciena may terminate this Agreement and your license to the Software immediately by giving you written notice of
termination in the event that either (i) you breach any term or condition of this Agreement or (ii) you are wound up
other than voluntarily for the purposes of amalgamation or reorganization, have a receiver appointed or enter into
liquidation or bankruptcy or analogous process in your home country. Termination shall be without prejudice to any
other rights or remedies Ciena may have. In the event of any termination you will have no right to keep or use the
Software or any copy of the Software for any purpose and you shall destroy and erase all copies of such Software in
its possession or control, and forward written certification to Ciena that all such copies of Software have been
destroyed or erased.
6. Compliance with laws. You agree to comply with all applicable laws, including all import regulations, and to
obtain all required licenses and permits related to installation and use of Equipment. Software, including technical
data, is subject to U.S. export control laws, including the U.S. Export Administration Act and its associated
regulations, and may be subject to export or import regulations in other countries. Customer agrees to comply
strictly with all such regulations and acknowledges that it has the responsibility to obtain licenses to export, re-
export, or import Software.
7. Limitation of Liability. ANY LIABILITY OF Ciena SHALL BE LIMITED IN THE AGGREGATE TO THE
AMOUNTS PAID BY YOU FOR THE SOFTWARE. THIS LIMITATION APPLIES TO ALL CAUSES OF ACTION,
INCLUDING WITHOUT LIMITATION BREACH OF CONTRACT, BREACH OF WARRANTY, NEGLIGENCE,
STRICT LIABILITY, MISREPRESENTATION AND OTHER TORTS. THE LIMITATIONS OF LIABILITY DESCRIBED
IN THIS SECTION ALSO APPLY TO ANY THIRD-PARTY SUPPLIER OF Ciena. NEITHER Ciena NOR ANY OF
ITS THIRD-PARTY SUPPLIERS SHALL BE LIABLE FOR ANY INJURY, LOSS OR DAMAGE, WHETHER
INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL INCLUDING WITHOUT LIMITATION ANY LOST
PROFITS, CONTRACTS, DATA OR PROGRAMS, AND THE COST OF RECOVERING SUCH DATA OR
PROGRAMS, EVEN IF INFORMED OF THE POSSIBILITY OF SUCH DAMAGES IN ADVANCE
8. General. Ciena may assign this Agreement to any Ciena affiliate or to a purchaser of the intellectual property
rights in the Software, but otherwise neither this Agreement nor any rights hereunder may be assigned nor duties
delegated by either party, and any attempt to do so will be void. This Agreement shall be governed by the laws of
the State of Maryland (without regard to the conflict of laws provisions) and shall be enforceable in the courts of
Maryland. The U.N. Convention on Contracts for the International Sale of Goods shall not apply hereto. This
Agreement constitutes the complete and exclusive statement of agreement between the parties relating to the
license for the Software and supersedes all proposals, communications, purchase orders, and prior agreements,
verbal or written, between the parties. If any portion hereof is found to be void or unenforceable, the remaining
provisions shall remain in full force and effect.
v
Publication history 0
April 2013
Revision A
This is the first release of this document for software release 2.1.1.
August 2013
Revision B
This revision supports software release 2.1.2.
5400 Reconfigurable Switching System Alarm And Trouble Clearing Manual

009-3235-003 Revision B
vi Publication history

009-3235-003 Revision B
Contents vii
Contents 0
About this document xiii
Alarm monitoring 1-1

About this manual 1-1
Prerequisites 1-1
Overview 1-2
5400 Switch alarms 1-2
General trouble clearing approach 1-3
5400 Switch alarm and trouble clearing procedures 2-1

2-1 A-SNCP automatic switch 2-8
2-2 A-SNCP fail to switch 2-13
2-3 A-SNCP forced switch to protect 2-14
2-4 A-SNCP forced switch to working 2-16
2-5 A-SNCP lockout of protect 2-18
2-6 A-SNCP manual switch to protect 2-20
2-7 A-SNCP manual switch to working 2-22
2-8 AIS-L/MS-AIS (TTP) 2-24
2-9 AIS-P/RDI-P (CTP) 2-27
2-10 All redundant sync units failed 2-30
2-11 All references failed 2-32
2-12 AU-AIS 2-34
2-13 Autonegotiation fail 2-37
2-14 Bay air filter(s) problem 2-38
2-15 Bay high ambient temperature 2-40
2-16 Bay low ambient temperature 2-42
2-17 BLSR automatic switch to protect 2-44
2-18 BLSR default k-bytes defect 2-49
2-19 BLSR failure to switch 2-51
2-20 BLSR force switch to protect 2-52
2-21 BLSR improper APS codes 2-53
2-22 BLSR inconsistent APS codes 2-56
2-23 BLSR lockout of protect 2-58
2-24 BLSR lockout of work 2-59
2-25 BLSR manual switch to protect 2-60
2-26 BLSR node id mismatch 2-61
2-27 BLSR protection degrade condition 2-64
2-28 BLSR protection group misconfiguration 2-65
2-29 Circuit pack over temperature 2-67
2-30 Clock mode not normal 2-70
2-31 Communications subsystem conflict 2-73
2-32 Configuration mismatch 2-75
2-33 Co-routed SNC is degraded 2-77
2-34 Co-routed SNC is unavailable 2-78
2-35 DC power failed 2-79
2-36 DCN interface link failure 2-82

009-3235-003 Revision B
viii Contents
2-37 Degraded switch fabric 2-83

2-38 Ethernet forward fault indication 2-84
2-39 Ethernet-LOF 2-86
2-40 Ethernet-LOS 2-90
2-41 Ethernet-RFI 2-94
2-42 Fan overdriven 2-96
2-43 Fan speed mismatch 2-98
2-44 FCC automatic switch 2-100
2-45 FCC crossconnect degraded 2-104
2-46 FCC disabled 2-106
2-47 FCC fail to switch 2-109
2-48 FCC forced switch to protect 2-110
2-49 FCC forced switch to working 2-112
2-50 FCC lockout of protect 2-114
2-51 FCC manual switch to protect 2-115
2-52 FCC manual switch to working 2-116
2-53 FEC type mismatch 2-118
2-54 Firmware mismatch 2-119
2-55 Generic AIS 2-121
2-56 GFP UPI mismatch 2-122
2-57 In loopback condition 2-124
2-58 In loopback mode 2-125
2-59 Input power fuse 2-126
2-60 Intrusion detection 2-128
2-61 LAPS automatic switch to protect 2-129
2-62 LAPS channel mismatch 2-134
2-63 LAPS fail to switch 2-136
2-64 LAPS far end protection line failure 2-137
2-65 LAPS forced switch to protect 2-138
2-66 LAPS forced switch to working 2-140
2-67 LAPS invalid APS mode 2-142
2-68 LAPS lockout of protection 2-144
2-69 LAPS lockout of working 2-145
2-70 LAPS manual switch to protect 2-147
2-71 LAPS manual switch to working 2-149
2-72 LAPS mode mismatch 2-151
2-73 LAPS protection switch byte failure 2-153
2-74 LCH 2-155
2-75 LOC 2-157
2-76 LOF 2-159
2-77 LOP 2-163
2-78 Loss of PCS 2-165
2-79 LOS 2-167
2-80 LSC 2-171
2-81 Maximum discovered route limit reached 2-175
2-82 NDP adjacency down 2-176
2-83 NDP duplicate subtended neighbor condition 2-178
2-84 Network configuration changes inhibited 2-179
2-85 Nodes per area exceeded 2-180
2-86 ODU AIS 2-182

009-3235-003 Revision B
Contents ix
2-87 ODU BDI 2-184

2-88 ODU DEG 2-186
2-89 ODU LCK 2-190
2-90 ODU LOF 2-191
2-91 ODU OCI 2-195
2-92 ODU PLM 2-197
2-93 ODU TIM 2-199
2-94 Operation out of spec 2-201
2-95 OPU CSF 2-202
2-96 OPU MSI mismatch 2-204
2-97 OPR out of range 2-205
2-98 Optical trace mismatch 2-206
2-99 OSI communications failure 2-207
2-100 OSPF adjacency down 2-209
2-101 OSRP advertised bandwidth mismatch condition 2-210
2-102 OSRP concatenation mismatch condition 2-212
2-103 OSRP CTP bandwidth locked 2-214
2-104 OSRP CTP misconfigured bandwidth lockout 2-215
2-105 OSRP link ID mismatch condition 2-216
2-106 OSRP LTP misconfigured bandwidth mismatch 2-217
2-107 OSRP LTP misconfigured bandwidth threshold limit reached condition 2-218
2-108 OSRP LTP oversubscribed 2-219
2-109 OSRP misconfigured admin state condition 2-221
2-110 OSRP misconfigured CID condition 2-223
2-111 OSRP misconfigured condition 2-225
2-112 OSRP misconfigured node name condition 2-227
2-113 OSRP OVPN ID mismatch conditions 2-229
2-114 OSRP port capability mismatch 2-230
2-115 OSRP remote unreachable condition 2-231
2-116 OTU AIS 2-233
2-117 OTU BDI 2-235
2-118 OTU DEG 2-237
2-119 OTU LOF 2-241
2-120 OTU LOL 2-245
2-121 OTU PFSD 2-249
2-122 OTU PFSF 2-253
2-123 OTU TIM 2-257
2-124 Out-of-range 2-259
2-125 PDI-P 2-260
2-126 PLM-P 2-261
2-127 Provisioning required 2-262
2-128 RDI/MS-RDI 2-264
2-129 Remote nodes per system exceded 2-266
2-130 Reference failed 2-268
2-131 Replaceable unit mismatch 2-271
2-132 Replaceable unit missing 2-273
2-133 Replaceable unit problem 2-276
2-134 SD/SF 2-286
2-135 SD-P/SF-P 2-290
2-136 Secondary CTM initializing 2-291

009-3235-003 Revision B
x Contents
2-137 Section trace mismatch 2-292

2-138 Signaled SNCP automatic switch 2-294
2-139 Signaled SNCP fail to switch 2-298
2-140 Signaled SNCP forced switch to protect 2-299
2-141 Signaled SNCP forced switch to working 2-301
2-142 Signaled SNCP lockout of protection 2-302
2-143 Signaled SNCP manual switch to protect 2-304
2-144 Signaled SNCP manual switch to working 2-306
2-145 SNC home path not defined 2-308
2-146 SNC manual regroom status 2-309
2-147 SNC restored using preemption 2-310
2-148 Superuser logged in 2-311
2-149 TAP connection active 2-312
2-150 TCM AIS 2-314
2-151 TCM BDI 2-316
2-152 TCM DEG 2-318
2-153 TCM delay measurement failure 2-322
2-154 TCM LCK 2-324
2-155 TCM LOF 2-326
2-156 TCM LTC 2-330
2-157 TCM OCI 2-332
2-158 TCM TIM 2-333
2-159 Test session active 2-335
2-160 TIM-P 2-337
2-161 Timing backup not available 2-339
2-162 Timing force - lockout 2-341
2-163 Revertive switch (timing reference switch) 2-343
2-164 Non-revertive switch (timing reference switch) 2-344
2-165 Trace mismatch 2-345
2-166 Transmitter tuning in progress 2-347
2-167 Unavailable (SNC) 2-348
2-168 UNEQ/UNEQ-P 2-351
2-169 UPSR automatic switch 2-353
2-170 UPSR fail to switch 2-357
2-171 UPSR manual switch to protect 2-358
2-172 UPSR manual switch to working 2-360
2-173 UPSR force switch to protect 2-362
2-174 UPSR force switch to work 2-364
2-175 UPSR lockout of protect 2-366
Standards and compliance 3-1

Health and safety 3-2
Compliance information 3-2
Part 15 of the Federal Communications Commission (FCC): interference 3-2
Industry Canada notice 3-3
C-Tick 3-3
VCCI 3-3
EN55022 Class A notice 3-3

009-3235-003 Revision B
Contents xi
Food and Drug Administration (FDA) laser safety warning 3-4

Class 1 laser product notice 3-4
Environmental impact statement 3-4
Restricted access location 3-4
Bonding, grounding, and connections 3-4
Toxic emissions 3-5
Telcordia document standards 3-5
Safety information and instructions 3-5
Voltage precaution 3-6
Dual connection energy level hazard 3-7
Lift precautions 3-7
General static electricity precautions 3-8
Optical fiber handling precautions 3-9
Fiber break and damaged fiber precautions 3-9
Precautions for handling and storing modules 3-10
Service-affecting/nonservice-affecting alarms 4-1

009-3235-003 Revision B
xii Contents

009-3235-003 Revision B
xiii
About this document 0
This document provides a description of the Ciena® 5430 Reconfigurable

Switching System and 5410 Reconfigurable Switching System trouble
clearing activities and supplies information for identifying and clearing
conditions. The 5430 Reconfigurable Switching System and 5410
Reconfigurable Switching System is hereinafter referred to as 5400 Switch.
The procedures contained in this manual are intended to be performed on a

powered-up 5400 Switch exhibiting alarms or conditions in order to return the
5400 Switch to a fully operational condition free of alarms and conditions.
Due to the tenuous nature of performing alarm and trouble clearing

procedures on any traffic-bearing system, the user is strongly advised to
consider all system operational factors prior to executing any procedure
contained in this document; therefore, all procedures are presented as
guidelines for clearing alarms on mission-critical components.
Disclaimer
While every effort has been made to ensure that this document is complete
and accurate at the time of printing, the information that it contains is subject
to change. Ciena® is not responsible for any additions to or alterations of the
original document. Networks vary widely in their configurations, topologies,
and traffic conditions. This document is intended as a general guide only. It
has not been tested for all possible applications, and it may not be complete
or accurate for some situations.
Trademark acknowledgements
• Ciena® is a registered trademark of Ciena Corporation.
• CoreDirector® FS Multiservice Optical Switch and CoreDirector® FSCI
Multiservice Optical Switch are registered trademarks of Ciena
Corporation.
• ON-Center® Network & Service Management Suite is a registered
trademark of Ciena Corporation.
• CoreDirector Designer™ Software Tool (CDD) is a trademark of Ciena
Corporation.

009-3235-003 Revision B
xiv About this document
• Windows® XP, Windows® NT, and Windows® 7 are registered

trademarks of the Microsoft Corporation.
• UNIX® is a registered trademark licensed exclusively through X/Open
Company, Ltd.
• Microsoft® is either a registered trademark or trademark of Microsoft
Corporation in the United States and/or other countries.
• Sun, Sun Microsystems, JAVA, Java Secure Socket Extension, and
JAVAX are trademarks or registered trademarks of Sun Microsystems,
Inc. in the U.S. or other countries. This product includes code licensed
from RSA Data Security.
Intended audience
This document is intended for certified system installation technicians, test
engineers, and technical support technicians responsible for using the 5400
Reconfigurable Switching System. All 5400 Switching System personnel are
required to read, understand, and observe the safety precautions described
in the appropriate product manuals.
Document conventions
This section describes conventions that outline specific categories of
information throughout this document.
Symbols
Symbols denote text that requires special attention. The information contained
alongside a symbol corresponds to one of the following levels:
DANGER
Risk of personal injury
This symbol is used to highlight information so the user can avoid
personal injury.
CAUTION
Equipment damage or data loss
This symbol is used to highlight information so the user can avoid
equipment damage or data loss.
Related documentation
Additional supporting documentation is available through the Ciena web site
at http://www.ciena.com.
The following list contains the names of the related documents in the suite:
• 5400 Reconfigurable Switching System System Description Manual (009-
3235-006)

009-3235-003 Revision B
About this document xv
• 5400 Reconfigurable Switching System TL1 Manual (009-3235-016)

• 5400 Reconfigurable Switching System Turn-Up and Test Manual (009-
3235-002)
• 5400 Reconfigurable Switching System Service Manual (009-3235-004)
• 5400 Reconfigurable Switching System Alarm and Trouble Clearing
Procedure Manual (009-3235-003)
• 5400 Reconfigurable Switching System Node Manager (009-3235-005)

009-3235-003 Revision B
xvi About this document

009-3235-003 Revision B
1-1
Alarm monitoring 1-
About this manual

This manual is organized in chapters which describe the 5400 Switch alarm
and trouble clearing procedures. The 5400 Switch features automated
provisioning, self-discovery, and is fully interoperable with the Ciena
CoreDirector Family of Multiservice Optical Switches.
The CoreDirector Family of Multiservice Switches are hereinafter referred to

collectively as CoreDirector Switch. Unless otherwise specified, references to
a 5400 Switching System within this document refer to interconnected
network of CoreDirector Switches, 5410 Switches, and 5430 Switches.
Prerequisites
The following prerequisites must be met in order to successfully operate the
5400 Switch using procedures contained in this manual.
• The 5400 Switch must be installed in accordance with the 5400 Switch
hardware installation manual.
• The 5400 Switch system must be turned up and tested in accordance with
the 5400 Switch Turn-up and Test Manual.
• Node Manager must be installed and running on either a laptop or site
terminal. The revision level of the Node Manager software must be
compatible with the 5400 Switch.
• A File Transfer Protocol (FTP) application (for example, WFTPD software
by Texas Imperial Software or another FTP package) must be made
available to support software upgrades that may be required.
• The user must be Ciena-certified.
• The user must have the appropriate 5400 Switch Node Manager user
privileges to perform certain tasks.
• The user must have a knowledge of:
– The operating system on which Node Manager resides (for
example, Windows NT, Windows 2000, or UNIX operating
systems)

009-3235-003 Revision B
1-2 Alarm monitoring
– Digital optical test set usage

– 5400 Switch Node Manager software
• The user must have access to the 5400 Switch System Description
Manual:
– Module locations, descriptions, controls and indicators
– Specifications
• The user must have access to the 5400 Switch Service Manual.
Overview
The 5400 Reconfigurable Switching System conducts fault monitoring
applications and detects, isolates, and corrects abnormal operations. These
fault monitoring features inform external management software applications
(ON-Center® Network & Service Management Suite and 5400 Node
Manager). This chapter describes basic alarm monitoring using:
• 5400 Node Manager- refer to the 5400 Switch Node Manager User Guide
as required
• 5400 Switch controls and indicators- refer to the 5400 Switch System
Description Manual as required
5400 Switch alarms
Alarm categories (Table 1-1) are determined by International
Telecommunications Union (ITU) standards. Specific subsystems are
responsible for generating alarms such as equipment, Trail Termination Point
(TTP), and Connection Termination Point (CTP).
Table 1-1
Alarm categories
Alarm Description
Communications alarm An alarm associated with the procedures and/or processes required to
carry information from one point to another.
Environmental alarm An alarm caused by a condition relating to an enclosure in which the

equipment resides. Equipment failures include the fuse/power circuit
failures, receiver/transmitter failures, switching matrix failures, and Data
Communications Channel (DCC) hardware failures.
Equipment alarm An alarm caused by an equipment fault.

009-3235-003 Revision B
Alarm monitoring 1-3
Table 1-1 (continued)

Alarm categories
Alarm Description
Processing error alarm An alarm caused by a software and/or processing failure.
Quality of Service (QOS) An alarm caused by the degradation in the quality of the service
alarm provided.
Threshold crossing A transient alarm generated when the performance monitoring

threshold value has been compromised.
General trouble clearing approach

When the Network Operations Center (NOC) operator detects a 5400 Switch
system alarm, the operator uses 5400 Node Manager to troubleshoot
remotely. This tool pinpoints faults rapidly. In addition, the CSM software and
5400 Switch Node Manager applications provide additional details about the
fault.
In some instances, external conditions (for example, a severed fiber) cause an

alarm. In this case, the 5400 Switch alarms the line, and the NOC operator
can troubleshoot and dispatch a craft technician or a technical support
engineer to the site.
Local troubleshooting uses 5400 Node Manager and 5400 Switch controls
and indicators. If it is determined that a fault is caused by 5400 Switch circuit
packs or common equipment, a on-site technician can continue physical
troubleshooting. Upon arrival on-site, the technician makes an assessment of
the condition of the 5400 Switch by performing a visual inspection of the LEDs
on the display panel on the top of the rack/chassis.
If a LED is illuminated, further isolation can be accomplished opening the

5400 Switch doors and observing the fault LEDs on the different modules. An
illuminated fault (FLT) LED on a module pinpoints the malfunction to that
module.
While the NOC operator troubleshoots remotely, the craft technician performs
a visual inspection of the system and uses 5400 Switch Node Manager
software to diagnose the malfunction. Diagnostics and troubleshooting may
also require specialized test equipment (for example, power meter, back
reflection meter, optical spectrum analyzer, or optical time domain
reflectometer).

009-3235-003 Revision B
1-4 Alarm monitoring
After diagnosing the problem, the craft technician refers to the appropriate
maintenance procedure contained in the 5400 Switch Service Manual.
ATTENTION
Clear alarms in order of severity. Clear all Critical alarms first, then clear all
Major alarms, and then clear all minor alarms.

009-3235-003 Revision B
2-1
5400 Switch alarm and trouble clearing

procedures 2-
This chapter provides trouble clearing procedures for all alarms and warnings
monitored by the 5400 Switch. The alarms and warnings are in alphabetic
order.
Table 2-1
5400 Switch Alarms
Alarm Page
A-SNCP automatic switch Page 8
A-SNCP fail to switch Page 13
A-SNCP forced switch to protect Page 14
A-SNCP forced switch to working Page 16
A-SNCP lockout of protect Page 18
A-SNCP manual switch to protect Page 20
A-SNCP manual switch to working Page 22
AIS-L/MS-AIS (TTP) Page 24
AIS-P/RDI-P (CTP) Page 27
All redundant sync units failed Page 30
All references failed Page 32
AU-AIS Page 34
Autonegotiation fail Page 37
Bay air filter(s) problem Page 38
Bay high ambient temperature Page 40
Bay low ambient temperature Page 42
BLSR automatic switch to protect Page 44
5400 Reconfigurable Switching System Alarm and Trouble Clearing Manual

2-2 5400 Switch alarm and trouble clearing procedures

5400 Switch Alarms (continued)
Alarm Page
BLSR default k-bytes defect Page 49
BLSR failure to switch Page 51
BLSR force switch to protect Page 52
BLSR improper APS codes Page 53
BLSR inconsistent APS codes Page 56
BLSR lockout of protect Page 58
BLSR lockout of work Page 59
BLSR manual switch to protect Page 60
BLSR node id mismatch Page 61
BLSR protection degrade condition Page 64
BLSR protection group misconfiguration Page 66
Circuit pack over temperature Page 68
Clock mode not normal Page 71
Communications subsystem conflict Page 74
Configuration mismatch Page 76
Co-routed SNC is degraded Page 78
Co-routed SNC is unavailable Page 79
DC power failed Page 80
DCN interface link failure Page 83
Degraded switch fabric Page 84
Ethernet forward fault indication Page 85
Ethernet-LOF Page 87
Ethernet-LOS Page 91
Ethernet-RFI Page 95
Fan overdriven Page 97
Fan speed mismatch Page 99
FCC automatic switch Page 101


Alarm Page
FCC crossconnect degraded Page 105
FCC disabled Page 107
FCC fail to switch Page 110
FCC forced switch to protect Page 111
FCC forced switch to working Page 113
FCC lockout of protect Page 115
FCC manual switch to protect Page 116
FCC manual switch to working Page 117
FEC type mismatch Page 119
Firmware mismatch Page 120
Generic AIS Page 122
GFP UPI mismatch Page 123
In loopback condition Page 125
In loopback mode Page 126
Input power fuse Page 127
Intrusion detection Page 129
LAPS automatic switch to protect Page 130
LAPS channel mismatch Page 135
LAPS fail to switch Page 137
LAPS far end protection line failure Page 138
LAPS forced switch to protect Page 139
LAPS forced switch to working Page 141
LAPS invalid APS mode Page 143
LAPS lockout of protection Page 145
LAPS lockout of working Page 146
LAPS manual switch to protect Page 148
LAPS manual switch to working Page 150


Alarm Page
LAPS mode mismatch Page 152
LAPS protection switch byte failure Page 154
LCH Page 156
LOC Page 158
LOF Page 160
LOP Page 164
Loss of PCS Page 166
LOS Page 168
LSC Page 173
Maximum discovered route limit reached Page 177
NDP adjacency down Page 178
NDP duplicate subtended neighbor condition Page 180
Network configuration changes inhibited Page 181
Nodes per area exceeded Page 182
ODU AIS Page 184
ODU BDI Page 186
ODU DEG Page 188
ODU LCK Page 192
ODU LOF Page 193
ODU OCI Page 198
ODU PLM Page 200
ODU TIM Page 202
Operation out of spec Page 204
OPU CSF Page 205
OPU MSI mismatch Page 207
OPR out of range Page 209
Optical trace mismatch Page 209


Alarm Page
OSI communications failure Page 210
OSPF adjacency down Page 212
OSRP advertised bandwidth mismatch condition Page 213
OSRP concatenation mismatch condition Page 215
OSRP CTP bandwidth locked Page 217
OSRP CTP misconfigured bandwidth lockout Page 218
OSRP link ID mismatch condition Page 219
OSRP LTP misconfigured bandwidth mismatch Page 221
OSRP LTP misconfigured bandwidth threshold limit Page 222

reached condition
OSRP LTP oversubscribed Page 223
OSRP misconfigured admin state condition Page 225
OSRP misconfigured CID condition Page 227
OSRP misconfigured condition Page 229
OSRP misconfigured node name condition Page 231
OSRP OVPN ID mismatch conditions Page 233
OSRP port capability mismatch Page 234
OSRP remote unreachable condition Page 235
OTU AIS Page 237
OTU BDI Page 239
OTU DEG Page 241
OTU LOF Page 246
OTU LOL Page 250
OTU PFSD Page 255
OTU PFSF Page 259
OTU TIM Page 263
Out-of-range Page 265
PDI-P Page 266


Alarm Page
PLM-P Page 267
Provisioning required Page 268
RDI/MS-RDI Page 270
Remote nodes per system exceded Page 272
Reference failed Page 274
Replaceable unit mismatch Page 277
Replaceable unit missing Page 279
Replaceable unit problem Page 282
SD/SF Page 293
SD-P/SF-P Page 297
Secondary CTM initializing Page 298
Section trace mismatch Page 299
Signaled SNCP automatic switch Page 301
Signaled SNCP fail to switch Page 305
Signaled SNCP forced switch to protect Page 306
Signaled SNCP forced switch to working Page 308
Signaled SNCP lockout of protection Page 310
Signaled SNCP manual switch to protect Page 312
Signaled SNCP manual switch to working Page 314
SNC home path not defined Page 316
SNC manual regroom status Page 317
SNC restored using preemption Page 318
Superuser logged in Page 319
TAP connection active Page 320
TCM AIS Page 322
TCM BDI Page 324
TCM DEG Page 326


Alarm Page
TCM delay measurement failure Page 330
TCM LCK Page 332
TCM LOF Page 334
TCM LTC Page 338
TCM OCI Page 340
TCM TIM Page 341
Test session active Page 343
TIM-P Page 345
Timing backup not available Page 347
Timing force - lockout Page 349
Revertive switch (timing reference switch) Page 351
Non-revertive switch (timing reference switch) Page 352
Trace mismatch Page 353
Transmitter tuning in progress Page 355
Unavailable (SNC) Page 356
UNEQ/UNEQ-P Page 359
UPSR automatic switch Page 361
UPSR fail to switch Page 366
UPSR manual switch to protect Page 367
UPSR manual switch to working Page 369
UPSR force switch to protect Page 371
UPSR force switch to work Page 373
UPSR lockout of protect Page 375
ATTENTION
Maintenance procedures are located in the 5400 Switch Service Manual.

Procedure 2-1
A-SNCP automatic switch
Category: Standing condition
Object Class: MoPathSwitchingPUProxy
Probable Cause: ASNCP Automatic Switch
NM Probable Cause: ASNCP Automatic Switch
NM Additional Text: Arbitrary SNCP PU Protection Switch.

Previous Selector:<bay>-<shelf>-<slot>-<port>_<headTs>
Current Selector: <bay>-<shelf>-<slot>-<port>_<headTs>
Condition Description: LOP/AIS-P/SF-P/SD-P detected on the work path

and the protect path is error-free
Default Severity: Warning, Non service affecting
TL1 String: WKSWPR
The ASNCP Automatic Switch condition is raised when a revertive ASNCP

Protection Group automatically switches to protect and when a protection
group is provisioned from non-revertive to revertive and it is not on the working
line at the time of the provisioning change.
The ASNCP Automatic Switch to Protect condition clears if a protection group

is provisioned from revertive to non-revertive and when the target object is no
longer automatically protected.
“Service-affecting/nonservice-affecting alarms” on page 4-1, provides

additional information.
Alarm clearing procedure

Step Action
1 From the Node Manager workstation, launch the Node Manager application
and log on to the desired node.
2 Click Go > Monitoring > Alarms & Events, select the Alarms tab.
3 Note the port that displays the A-SNCP automatic switch condition.
4 Expand the equipment tree until alarmed port is displayed and verify that no
equipment alarms exist.

— If an equipment alarm exists, discontinue this procedure and perform

the trouble clearing procedure for the alarmed equipment.
5 Check the far end upstream LTE or MSTE laser and optical line multiplexer in
accordance with that technology's guidelines. If the line in alarm is in the
interior 5400 Switch/CoreDirector Switch network, the upstream LTE or
MSTE is another 5400 Switch or CoreDirector Switch. If the line in alarm is a
network drop, the upstream technology is typically an Aggregator/MUX. The
far end upstream LTE or MSTE laser should be checked for the following:
– Port and LM (or equivalent if other technology) equipment failures
or Laser Bias Current TCAs should not be present. (Corrective
action: replace the port, LM, or equivalent.)
– The laser should be of the correct type (rate, wavelength, and
reach), and the provisioned optical rate (if applicable) should also
be correct. (Corrective action: replace port SFP/XFP/CFP or
equivalent with correct rate, wavelength, and reach. To check/
correct provisioned rate of a transmit 5400 Switch port, expand the
Node Manager configuration tree, select the Physical TP and
Basic tabs, and ensure that the provisioned optical rate is correct.
Always lock the port before correcting and unlock when
completed.)
– The laser should not be locked. (Corrective action: unlock the port
or equivalent.)
– The output level of the laser (Node Manager PRTP Physical tab)
should be in accordance with SFP/XFP/CFP Specifications in the
5400 Switch System Description Manual. (Corrective action: clean
the transmit port or equivalent fiber connector, replace the port or
equivalent, and/or correct improper LBO if not a 5400 Switch
technology.)
— The output should not have bit errors. If bit errors are present but all
of the other indicated laser tests are good, the transmit LM (or
equivalent if other technology) may be defective.
— If the far end upstream LTE or MSTE laser or optical multiplexer tests
bad, repair in accordance with upstream technology guidelines, then
go to Step 26.
— If the far end upstream LTE or MSTE laser and optical multiplexer
tests good, go to Step 6.
CAUTION
Risk of interruption to service
Performance of this procedure may cause a traffic disruption. This
instruction is intended as a general guide only, has not been tested
for all possible applications or configurations, and may not be
complete or accurate for some situations.

CAUTION
Risk of damage to circuit packs
This equipment contains Electrostatic Discharge (ESD) sensitive
devices. Wear grounding straps when handling equipment and follow
ESD procedures.
ATTENTION
Perform the following steps at the node.
6 Remove the alarmed port receive fiber. If required, refer to the 5400 Switch
Service Manual. Insert the receive fiber into a test set capable of reading bit
errors and light level.
7 Determine if bit errors are reported by the test set.
— If bit errors are reported, go to Step 8.
— If bit errors are not reported, go to Step 19.
8 Clean the receive fiber in accordance with Ciena Standard Cleaning &
Equipment Safety Practices and reinsert receive fiber into test set.
10 The received light level should be in accordance with SFP/XFP/CFP
Specifications in the 5400 Switch System Description Manual. Verify that the
received light level is within specification.
11 If the received light level is within specification, go to Step 17.
— If the received light level is not within specification, go to Step 12.
12 Determine if there one or more WDM line systems in the upstream path
(between the transmit LTE or MSTE checked in Step 5 and the receive LTE
or MSTE in alarm).
— If no WDM line systems are in the upstream path, go to Step 13.
— If there are any WDM line systems in the upstream path, go to Step
15.
13 The output of the far end upstream LTE or MSTE was previously tested in
Step 5. The low light level and resulting bit errors must be the result of a dirty
or defective fiber or connector between (but not including) the transmit LTE or
MSTE and the receive 5400 Switch LTE or MSTE. Isolate and clean/repair the
fiber or connector trouble in accordance with internal guidelines.
14 Determine if a defective or dirty fiber or connector was cleaned or repaired in
Step 13.
— If a defective/dirty fiber or connector was cleaned or repaired in Step
13, go to Step 15.
— If no defective/dirty fibers or connectors were cleaned or repaired in
Step 13, go to Step 28.

15 Check the laser and output of the closest upstream WDM system (using all of
the checks noted in Step 5 of this procedure), and check/clean the transmit
fiber and connectors from the output of the WDM system to the input of the
alarmed 5400 Switch port in alarm. Correct any problems that are found.
16 Determine if any problems were isolated and corrected in Step 15.
— If any problems were isolated and corrected in Step 15, go to Step 17.
— If no problems were isolated and corrected in Step 15, go to Step 28.
17 Isolate/repair or refer the BER problem across all WDM line systems between
the upstream transmit LTE or MSTE and the receive 5400 Switch LTE or
MSTE in alarm in accordance with internal guidelines. In addition to checking
for higher rate WDM system alarms and PM data, this isolation should include
checking any fibers and connectors on the input to the first WDM system and
fibers and connectors between multiple WDM systems, as well as output
lasers from one WDM system to another.
19 Clean the port fiber connector in accordance with Ciena Standard Cleaning
and Equipment Safety Practices.
20 Check that the installed receive port is the correct type (rate, wavelength, and
reach) by verifying the part number.
21 Click Go > Configuring > Ptp and select the Basic tab.
22 View the Configured Rate box and ensure that the correct optical rate is
selected.
— If the correct optical rate is selected, go to Step 23.
— If the correct optical rate is not selected, lock the port, select the
correct rate, and unlock the port.
23 Reconnect the fiber, then reinstall the port in accordance with the 5400
Switch Service Manual.
24 Verify that the alarm cleared.
— If the alarm cleared, stop this procedure.
— If the alarm did not clear, go to Step 25.
25 Replace the port with a shelf spare. If required, refer to the 5400 Switch
Service Manual, then go to Step 28.
26 Determine if the test set is reporting bit errors or a light level is not within
specification defined in SFP/XFP/CFP Specifications in the 5400 Switch
System Description Manual.
— If the test set is reporting bit errors or a light level is out of
specification, go to Step 28.
— If the test set is not reporting bit errors or a light level is not out of
27 Reconnect the receive fiber, then reinstall the port. If required, refer to the
5400 Switch Service Manual.


— If the alarm cleared, end this procedure.
— If the alarm did not clear, contact the next level of support.
—end—

Procedure 2-2
A-SNCP fail to switch
Category: Communication
Probable Cause: ASNCP Failure to Switch
NM Probable Cause: ASNCP Failure to Switch
NM Additional Text: Arbitrary SNCP PU Protection Switch.Previous

Selector:
<bay>-<shelf>-<slot>-<port>_<headTs> Current Selector: <bay>-<shelf>-
<slot>-<port>_<headTs>
Condition Description: ASNCP Protection Unit is unable to perform

automatic protection switching because of defects on both the Work and
Protect paths.
TL1 String: FAILTOSW


Step Action
2 Click Go > Monitoring > Alarms & Events and select the Alarms tab.
3 Note and clear any path faults protection switch byte failure and far end
protect line fail alarms.
—end—

Procedure 2-3
A-SNCP forced switch to protect
Category: Service report
Probable Cause: ASNCP Force Switch to Protect
NM Probable Cause: ASNCP Force Switch to Protect

Selector:
Condition Description: Working line failure caused forced ASNCP protection

unit switch to protection
TL1 String: FRCDWKSWPR
The ASNCP Forced Switch to Protect condition is raised when a forced switch
to the protect path is initiated. The condition is cleared when a higher priority
switch is initiated or when the forced switch is released.


Step Action
2 Click Go > Monitoring > Alarms & Events and select the Alarms tab. Note
the module that displays the A-SNCP forced switch to protect warning.
3 From the list under the Go > Protection > Path Level > SNCP > Groups tab,
select the protection unit identified in Step 2.
4 Verify the state of the working path in the Administer/Status field is OKAY.
5 Click the Release button in Administer Status field.
6 Click Yes in confirmation dialog.

7 If there are several locked protection units in the ASNCP group, from the list
under the Go > Protection > Path Level > SNCP > Group tab, select the
ASNCP group.
8 Click the Release button in Administer All PUs field.
9 Click Accept.
—end—

Procedure 2-4
A-SNCP forced switch to working
Probable Cause: ASNCP Force Switch to Work
NM Probable Cause: ASNCP Force Switch to Work

Selector:
Condition Description: ASNCP protection unit forced switch to protection

detected
TL1 String: FRCDWKSWBK
The ASNCP Forced Switch to working condition is raised when a forced

switch to the working path is initiated. The condition is cleared when a higher
priority switch is initiated or when the forced switch is released.


Step Action
the module that displays the A-SNCP forced switch to working warning.
3 Click Go > Protection > Path Level > SNCP and select the Protection Units
tab, select the ASNCP protection unit identified in Step 2 from the list in the
list frame.
4 Click the Release button in the Administer/Status field.

6 If there are several protection units switched, under the Go > Protection >
Path Level > SNCP > Group tab, select the ASNCP group identified in Step
2 from the list in the list frame.
8 Click Accept.
9 Verify that the warning cleared.
—end—

Procedure 2-5
A-SNCP lockout of protect
Probable Cause: ASNCP Lockout of Protect
NM Probable Cause: ASNCP Lockout of Protect

Selector:
Condition Description: User invoked lock out of protection detected
TL1 String: LOCKOUTOFPR
This warning occurs when a user invokes a lock out of protection on an

ASNCP protection unit and is cleared when the lockout is released.


Step Action
the module that displays the A-SNCP lockout of protect warning.
3 From the list under the Go > Protection > Path Level > SNCP > Protection
Unit tab, select the protection unit identified in Step 2.
ASNCP group.


—end—

Procedure 2-6
A-SNCP manual switch to protect
Object Class: PathSwitchingPUProxy
Probable Cause: ASNCP Manual Switch to Protect
NM Probable Cause: ASNCP Manual Switch to Protect

Selector:
Condition Description: User invoked manual switch to protection on an

ASNCP protection unit detected
TL1 String: MANWKSWPR
The ASNCP Manual Switch to Protect condition is raised when a manual

switch to the protect path is initiated and the ASNCP protection feature is
provisioned as revertive. The condition is cleared when a higher priority switch
is initiated or when the manual switch is released.


Step Action
the port that displays the A-SNCP manual switch to protect condition.
3 Under the Go > Protection > Path Level > SNCP > Protection Unit tab,
select the protection unit identified in Step 2 from the list.
4 Click the Release button in Administer/Status field.
5 If there are several switched protection units in the ASNCP group, under the
Go > Protection > Path Level > SNCP > Group tab, select the ASNCP
group from the list.

6 Click the Release button in Administer all PUs field.

—end—

Procedure 2-7
A-SNCP manual switch to working
Probable Cause: ASNCP Manual Switch to Work
NM Probable Cause: ASNCP Manual Switch to Work
NM Additional Text: Arbitrary SNCP PU Protection Switch.

Previous Selector: <bay>-<shelf>-<slot>-<port>_<headTs> Current Selector:
<bay>-<shelf>-<slot>-<port>_<headTs>
Condition Description: User invoked Manual Switch to Working detected
TL1 String: MANWKSWBK
This warning is raised when a manual switch to the working path is initiated
and the ASNCP protection is provisioned as revertive. The condition is cleared
when a higher priority switch is initiated or when the manual switch is
released.


Step Action
the module that displays the A-SNCP manual switch to working warning.
4 Verify the state of the protect path in the Administer/Status field is OKAY.
6 Click YES in the confirmation dialog.

ASNCP group.
9 Click Accept.
—end—

Procedure 2-8
AIS-L/MS-AIS (TTP)
Object Class: TTP (SDH)
Probable Cause: AIS-L (SONET) MS-AIS (SDH)
NM Probable Cause: AIS-L (SONET) MS-AIS (SDH)
NM Additional Text:
• SONET- Line AIS

• SDH- Multiplex section AIS
Condition Description: Line alarm indication signal detected (SONET) or
multiplex section alarm indication signal detected (SDH)
Default Severity: Dynamic - Minor/Not service affecting for ports with no

cross-connection provisioned, Minor/Not service affecting for ports with
protected status, or Major/Service affecting for ports with unprotected status
TL1 String: AIS-L (SONET) MS-AIS (SDH)
An Alarm Indication Signal - Line (AIS-L)/ Alarm Indication Signal - multiplex

section (MS-AIS) indicates that upstream equipment has experienced a
facility or equipment failure. Resolving the fault in the adjoining node clears the
AIS-L alarm in the reporting node.
When a node detects AIS-L on an incoming signal, it generates AIS-P on the

outgoing CTPs and sends the RDI-L signal back toward the peer to indicate
that the node has detected an AIS-L or lower layer defect on the signal that
the peer originated.


Step Action

the port that displays the AIS-L/MS-AIS (TTP) alarm.
3 Expand the node equipment tree until the alarmed port is displayed and verify
that no equipment alarms exist.
— If an equipment alarm does not exist, go to Step 4.
4 For all upstream WDM technologies between the node LTE reporting the AIS-
L alarm and the upstream LTE, check for any equipment alarms and line
facility defect alarms in the line facility path.
— If all WDM technologies in the upstream line facility path test good,
go to Step 5.
— If any WDM technologies in the upstream line facility path are
reporting equipment alarms or line signal defects, resolve or refer in
accordance with internal guidelines. When all WDM technology
alarms are resolved, go to Step 5.
CAUTION
ATTENTION
If an upstream WDM technology signal defect alarm is isolated back to the
transmit LTE, the LTE laser should be checked for the following:
— SFP/XFP/CFP and LM equipment failures or Laser Bias Current Threshold Crossing
Alerts (TCAs) should not be present. (Corrective action: replace SFP/XFP/CFP or
LM.)
— The laser should be of the correct type (rate, wavelength, and reach), and the
provisioned optical rate (if applicable) should also be correct. (Corrective action:
replace/provision SFP/XFP/CFP with correct rate, wavelength, and reach. To check/
correct provisioned rate of a transmit node port, expand the Node Manager
Configuration tree, click Go > Configuring > Trail TPs and ensure that the provisioned
optical rate is correct by viewing the list frame Rate to ensure that the correct optical
rate is selected. Always lock the port before correcting, and unlock the port when
completed.)
— The laser should not be locked. (Corrective action; unlock the SFP/XFP/CFP.)
— Verify the output level of the laser (Corrective action: clean the transmit SFP/XFP/CFP
fiber connector and bulkhead connector, replace the SFP/XFP/CFP, or correct
improper Line Build Out (LBO) if not 5400 Switch technology.)
— The output should not have bit errors. If bit errors are present but all of the other
indicated laser tests are good, the transmit LM (or equivalent if other technology) may
be defective.
ATTENTION

5 Remove the incoming fiber to the port and connect the fiber to an optical test
set.
— If test set reports incoming AIS-L or any other line signal defect, the
section trouble is external. The source of the downstream AIS must
be manually isolated to a reporting WDM system. Isolate or refer in
accordance with internal guidelines.
ATTENTION
If a signal defect is isolated to the upstream LTE, check the upstream LTE
laser as indicated in Step 4. When the root cause of the AIS alarm is isolated
and resolved, go to Step 6.
— If the test set does not report incoming AIS-L or any other line signal
defect, go to Step 7.
6 Reconnect fiber, reinstall SFP/XFP/CFP, and recheck alarm status.
— If the alarm still exists, go to Step 7.
7 Replace the SFP/XFP/CFP in accordance with the 5400 Switch Service
Manual.
—end—

Procedure 2-9
AIS-P/RDI-P (CTP)
Object Class: CTP (SONET and SDH)
Probable Cause: AIS-P (SONET), RFI-P (SDH)
NM Probable Cause: AIS-P (SONET), RFI-P (SDH)
NM Additional Text:
• Path AIS
• AU-AIS
Condition Description: A path level Alarm Indication Signal condition is
present on the associated CTP
Default Severity:
• Not reported (default)

• Dynamic - Minor/Not service affecting for ports with protected status, or
Major/service affecting for ports with unprotected status
TL1 String:
• AIS-P (SONET), AU-AIS (SDH)

Alarm Indication Signal - Path (AIS-P) and Remote Defect Indicator - Path
(RDI-P) are maintenance signals that alert downstream equipment that a
defect (for example, LOS or LOF) has been detected in the incoming signal.
The node reports AIS-P or RDI-P for drop-side CTPs at the originating and
terminating nodes only. The drop-side CTP alarms are critical and service
affecting.
AIS-P and RDI-P are cleared when the CTP is administratively locked, the
path is deleted, or 10 seconds after the path AIS or RDI clears.


Step Action

2 Click Go > Monitoring > Alarms & Events and select the Alarms tab. Select
the AIS-P/RDI-P (CTP) alarm and note the upstream drop CTP at the 5400
Switch network edge.
3 Determine if the CTP is reporting an AIS (CTP) alarm at the node at the
network edge drop of the overall SNC.
— If the CTP is reporting an AIS (CTP) alarm, the trouble is external to
the 5400 Switch network. Isolate and resolve or refer the external
AIS-P trouble in accordance with internal guidelines, then go to Step
6.
— If the CTP is not reporting an AIS (CTP) alarm, go to Step 4.
CAUTION
CAUTION
ESD procedures.
ATTENTION
4 At the Node Manager workstation, view the Current Alarms Summary screen
for the presence of the AIS-P alarm reporting at the upstream 5400 Switch
network edge drop CTP.
— If an AIS-P alarm is being reported at the upstream incoming drop
CTP, the trouble is external to the 5400 Switch network. Isolate and
resolve or refer the external AIS-P trouble in accordance with internal
guidelines, then go to Step 6.
— If this alarm is not being reported at the upstream incoming drop CTP,
the root cause of this trouble is internal to the 5400 Switch network.
An Unavailable (SNC) alarm should be reporting at the source node
for this SNC. Go to Step 5.
5 View the alarms for all 5400 Switches in the upstream path. Note any of the
following alarms reporting to any 5400 Switch in the upstream facility path.
— Facility defect alarms (LOS, LOF, AIS-L/MS-AIS(TTP), SD/SF) on
any port associated with the SNC on any 5400 Switch in the
upstream path.

— Equipment alarms on any SFP/XFP/CFP or LM associated with the

SNC reporting on any 5400 Switch in the upstream path.
— SM equipment or Port Data Plane Health alarms, power alarms, TGS
equipment alarms, or Ref Fail alarms reporting on any 5400 Switch
in the upstream path.
— If any of the indicated alarms are present on any 5400 Switch in the
upstream path, discontinue this procedure and perform the TCP for
the noted alarm.
— If none of the indicated alarms are present on any 5400 Switch in the
upstream path, go to Step 6.
—end—

Procedure 2-10
All redundant sync units failed
Category: Equipment
Object Class: NE, moBay
Probable Cause: All Redundant Synch Units Failed
NM Probable Cause: All Redundant Synch Units Failed
NM Additional Text: All Redundant Synch Units Failed
Condition Description: An All Redundant Synch Units Failed condition is

raised if both redundant timing subsystems are considered failed.
Default Severity: Critical, Service affecting
Type: Standing Condition
TL1 String: SYNCEQPT
The All Redundant Synch Units Failed alarm is raised when both redundant
timing subsystems fail. In the event of an All Redundant Synch Units Failed
condition, a line level AIS is transmitted on all ports in the node and
Replaceable Unit Problem alarms (RUPs) are reported for both CTMs.
The System clears the alarm notification All Redundant Synch Units Failed
when one of the redundant timing subsystems is operational.


Step Action

ATTENTION
The All Redundant Synch Units Failed alarm means that both the A-CTM
and C-CTM timing subsystems have failed and that AIS-L is transmitted on
all ports. The following steps replace the secondary CTM and then replace
the primary CTM. The last steps of this procedure refer the user to perform
the All redundant sync units failed or procedures if required.
2 Under the Monitoring > Alarms & Events tab, view the alarm summary and
details screen. Note that the All redundant sync units failed alarm is
present and Replaceable Unit Problem Alarms are present for A-CTM and C-
CTM.
3 Refer to the 5400 Switch and replace the secondary CTM in accordance with
the Remove and Install Control and Timing Module (CTM) procedure.
details screen. Note that the All Redundant Synch Units Failed alarm cleared
and the Replaceable Unit Problem Alarm for the replaced CTM cleared.
— If the All Redundant Synch Units Failed alarm has not cleared,
contact the next level of support.
5 If a Replaceable Unit Problem Alarm is present for the remaining CTM, refer
to the 5400 Switch and replace the remaining CTM in accordance with the
Remove and Install Control and Timing Module (CTM) procedure.
details screen. Note that the Replaceable Unit Problem Alarms for the
replaced CTM cleared.
details screen.
— If All redundant sync units failed alarm is present, go to All
redundant sync units failed on Page 30.
— If Reference failed alarm is present, go to Reference failed on
Page 274.
—end—

Procedure 2-11
All references failed
Category: Communications
Object Class: SynchPG
Probable Cause: All References Failed
NM Probable Cause: All References Failed
NM Additional Text: The provisioned timing references for <TimingInput,

TimingOutputX> PG are failed.
Condition Description: An All References Failed condition is raised if all the

input references for a SyncPG are disqualified as a timing reference and the
node must enter holdover/faststart.
Default Severity: Major, service affecting
TL1 String: SYNCOOS
The All References Failed condition is raised when a valid timing reference is
not available. This can be due to an input failure, SSM disqualification, locked
reference, or not defined reference. In this state, the system autonomously
enters holdover or free-run.The manually disabled state does not cause this
condition.
The All References Failed condition clears when one or more timing
references are qualified.


Step Action
3 Select the All references failed alarm and note the failure reason for each
BITS or SSU input.

4 For BITS 1 or SSU A, complete the Reference failed TCP and then go to
Step 5 of this procedure.
5 For BITS 2 or SSU B, complete the Reference failed TCP and then go to
Step 6 of this procedure.
—end—

Procedure 2-12
AU-AIS
Object Class: CTP (SDH)
Probable Cause: AU-AIS
NM Probable Cause: AU-AIS
NM Additional Text: Path AIS
Condition Description: A path level Alarm Indication Signal condition is

present on the associated CTP
Default Severity:
• Dynamic - Minor/Not service affecting for ports with protected status, or

Major/service affecting for ports with unprotected status
TL1 String:
• AU-AIS
Alarm Indication Signal - Path (AIS-P) and Remote Defect Indicator - Path
(RDI-P) are maintenance signals that alert downstream equipment that a
defect (for example, LOS or LOF) has been detected in the incoming signal.
The node reports AIS-P or RDI-P for drop-side CTPs at the originating and
terminating nodes only. The drop-side CTP alarms are critical and service
affecting.
AIS-P and RDI-P are cleared when the CTP is administratively locked, the
path is deleted, or 10 seconds after the path AIS or RDI clears.


Step Action

2 Click Go > Monitoring > Alarms & Events, select the Alarms tab. Select the
AU-AIS alarm and note the upstream drop CTP at the 5400 Switch network
edge.
3 Determine if the CTP is reporting an AIS (CTP) alarm at the node at the
network edge drop of the overall SNC.
— If the CTP is reporting an AIS (CTP) alarm, the trouble is external to
the 5400 Switch network. Isolate and resolve or refer the external
AIS-P trouble in accordance with internal guidelines, then go to Step
6.
— If the CTP is not reporting an AIS (CTP) alarm, go to Step 4.
CAUTION
CAUTION
ESD procedures.
ATTENTION
4 At the Node Manager workstation, view the Current Alarms Summary screen
for the presence of the AIS-P alarm reporting at the upstream 5400 Switch
network edge drop CTP.
— If an AIS-P alarm is being reported at the upstream incoming drop
CTP, the trouble is external to the 5400 Switch network. Isolate and
resolve or refer the external AIS-P trouble in accordance with internal
guidelines, then go to Step 6.
— If this alarm is not being reported at the upstream incoming drop CTP,
the root cause of this trouble is internal to the 5400 Switch network.
An Unavailable (SNC) alarm should be reporting at the source node
for this SNC. Go to Step 5.
5 View the alarms for all 5400 Switches in the upstream path. Note any of the
following alarms reporting to any 5400 Switch in the upstream facility path.
— Facility defect alarms (LOS, LOF, AIS-L/MS-AIS(TTP), SD/SF) on
any port associated with the SNC on any 5400 Switch in the
upstream path.
— Equipment alarms on any SFP/XFP/CFP or LM associated with the
SNC reporting on any 5400 Switch in the upstream path.

— SM equipment or Port Data Plane Health alarms, power alarms, TGS

equipment alarms, or Ref Fail alarms reporting on any 5400 Switch
in the upstream path.
— If any of the indicated alarms are present on any 5400 Switch in the
upstream path, discontinue this procedure and perform the TCP for
the noted alarm.
— If none of the indicated alarms are present on any 5400 Switch in the
upstream path, go to Step 6.
—end—

Procedure 2-13
Autonegotiation fail
Object Class: ETTP
Probable Cause:
NM Probable Cause: Autonegotiation Fail
NM Additional Text: Autonegotiation Fail
Condition Description:
TL1 String: Autonegotiation Fail
The Autonegotiation Fail condition is raised against the ETTP if the

Autonegotiation status is "Failed" or is any value other than "Failed".


Step Action
3 Select the Autonegotiation fail alarm and note the name of the TETTP
reporting the alarm.
4 Click Go > TransETTP > Basic and verify that the Autonegotiation enable/
disable setting is provisioned with the same settings as the link partner of the
TETTP.
—end—

Procedure 2-14
Bay air filter(s) problem
Category: Equipment
Object Class: MoBay
Probable Cause: Bay Air Filter(s) Problem
NM Probable Cause: Bay Air Filter(s) Problem
NM Additional Text: Filter Maintenance Interval Expiration
Condition Description: This alarm is generated when the air filter needs to
be replaced.
Default Severity: Maintenance Interval Expiration: Minor, Non service

affecting.
TL1 String: AIRFILTER
A Bay Air Filter Problem is raised when the air filter timer expires and is
cleared by a user action to set the timer to a non-zero value.


Step Action
the Bay air filter(s) problem alarm, and note any additional equipment alarm
information related to the node.
— If there are any input power alarms, discontinue this procedure and
perform the appropriate Input Power TCP.
— If there are cooling fan unit replaceable unit problems, discontinue
this procedure and perform the replaceable unit problem TCP.

— If there are no related equipment alarms, go to Step 3.

CAUTION
ESD procedures.
ATTENTION
3 At the node, replace the air filter in accordance with the Remove and Install
Air Filter procedure listed in the 5400 Switch Service Manual.
4 At the Node Manager workstation, expand the inventory equipment tree if
necessary and select Bay.
5 In the Air Filter Service Timer text box, enter the number of days until the next
air filter service in accordance with local site practices.
6 Click Accept.
—end—

Procedure 2-15
Bay high ambient temperature
Category: Equipment
Object Class: MoBay
Probable Cause: Bay High Ambient Temperature
NM Probable Cause: Bay High Ambient Temperature
NM Additional Text: Ambient bay temperature detected in excess of 40°C
Condition Description: This alarm is generated when the node detects an

ambient temperature in excess of 40° C which is above the long term
operating conditions for the bay.
TL1 String: HITEMP
The Bay High Ambient Temperature alarm is raised immediately (there is no

integration period) when the ambient temperature sensor for the 5400 Switch
bay rises above the 40° C (Celsius) or 104° Fahrenheit (F) threshold.


Step Action
the Bay high ambient temperature alarm and note other alarms reporting
at the node and any additional alarm information. Check for related alarms in
the following order:
— If there are any input power alarms present, discontinue this
procedure and perform the appropriate input power trouble clearing
procedure. (Input power problems may affect the fans and ultimately
bay cooling.)
— If there are any CFU replaceable unit problem alarms, discontinue
this procedure and perform the associated CFU replaceable unit
problem trouble clearing procedure.

ATTENTION
Do not discontinue this procedure in favor of Fan Overdriven alarms. The fans
always increase in Revolutions Per Minute (RPM) if there are any temperature-
related alarms.
— If none of the above alarms exist, go to Step 3.

3 Check the ambient temperature of the facility and verify that it does not
exceed the operating temperature requirements of the equipment (40°C or
104°F).
— If facility ambient temperature is below 40°C or 104°F, go to Step 4.
— If facility ambient temperature is above 40°C or 104°F, correct the
office ambient temperature, then go to Step 2.
4 At the node, remove and inspect the air filter in accordance with the Remove
and Install Air Filter procedure in the 5400 Switch Service Manual and
replace if needed.
5 At the node, inspect for and replace any circuit pack blanks that are missing
in any empty slots of Shelf A, Shelf B, or Shelf C. Ensure that all other covers
are correctly installed.
6 If the air filter was replaced or circuit pack blanks were installed, go to Step 7.
— If the air filter was not replaced and no circuit pack blanks were
installed, contact the next level of support.
—end—

Procedure 2-16
Bay low ambient temperature
Category: Equipment
Object Class: MoBay
Probable Cause: Bay Low Ambient Temperature
NM Probable Cause: Bay Low Ambient Temperature
NM Additional Text: Ambient bay temperature detected below 5°C
Condition Description: This alarm is generated when the System detects an

ambient temperature below 5°C.
TL1 String: LWTEMP
The Bay Low Ambient Temperature alarm occurs immediately (there is no

integration period) when the ambient temperature falls below the 5°C (41°F)
threshold. The Bay Low Ambient Temperature alarm clears when the ambient
temperature rises above 10.0°C (50°F) threshold.


Step Action
the Bay low ambient temperature alarm.
3 Check facility ambient temperature and ensure that temperature is not below
the minimum operating ambient temperature operating requirements (5°C or
41°F).
— If facility ambient temperature is below the minimum operating
requirements of the equipment (5°C or 41°F), correct the facility
ambient temperature and go to Step 5.
— If facility ambient temperature is above the minimum operating
requirements of the equipment (5°C or 41°F), go to Step 4.

4 At the Node Manager workstation, view the alarm and event summary and
details screen and other alarms reporting at the node. Note any additional
alarm information.
— If Fan Overdriven alarm is present, discontinue this procedure and
perform the Fan Overdriven TCP.
—end—

Procedure 2-17
BLSR automatic switch to protect
Object Class: MoVlsrPg
Probable Cause: BLSR Automatic Switch
NM Probable Cause: BLSR Automatic Switch
Condition Description: Automatic switch due to defects
Additional Text: Automatic Switch to Protect
TL1 String: WKSWPR
The system raises an Automatic Switch to Protect condition upon automatic

operation of a Revertive BLSR Span or Ring Switch. The condition is raised
against the defective line. In a revertive protection group, this is the working
line.
The system also raises an Automatic Switch to Protect condition if a protection

group is provisioned from non-revertive to revertive, and if it is not on the
working line at the time of the provisioning change.
The system clears the Automatic Switch to Protect condition when:
• a protection group is provisioned from revertive to non-revertive

• a higher-priority automatic switching command is initiated
• the target object is no longer automatically protected.

Step Action

the BLSR automatic switch to protect alarm and note the port that displays
the automatic switchover condition.
— Port and LM (or equivalent if other technology) equipment failures or
Laser Bias Current TCAs should not be present. (Corrective action:
replace the port, LM, or equivalent.)
— The laser should be of the correct type (rate, wavelength, and reach),
and the provisioned optical rate (if applicable) should also be correct.
(Corrective action: replace port SFP/XFP/CFP or equivalent with
correct rate, wavelength, and reach. To check/correct provisioned
rate of a transmit 5400 Switch port, expand the Node Manager
configuration tree, select the Physical TP and Basic tabs, and
ensure that the provisioned optical rate is correct. Always lock the
port before correcting and unlock when completed.)
— The laser should not be locked. (Corrective action: unlock the port or
equivalent.)
— The output level of the laser (Node Manager PRTP Physical tab)
technology.)
The output should not have bit errors. If bit errors are present but all of the
other indicated laser tests are good, the transmit LM (or equivalent if other
technology) may be defective.
If the far end upstream LTE or MSTE laser or optical multiplexer tests bad,
repair in accordance with upstream technology guidelines, then go to Step 25.
If the far end upstream LTE or MSTE laser and optical multiplexer tests good,
go to Step 5.

CAUTION
CAUTION
ESD procedures.
ATTENTION
or MSTE in alarm).
14.


Step 12.
12, go to Step 14.
20 Under the Go > Configuration menu, select the Physical TP and Basic
tabs.
selected.

—end—

Procedure 2-18
BLSR default k-bytes defect
Object Class: MoVlsrPU
Probable Cause: BLSR Default K-Bytes
NM Probable Cause: BLSR Default K-Bytes
Default Severity: Minor, Non service affecting
TL1 String: BLSRKB
The system raises the BLSR Default K Byte condition if the NE continues to
detect a default K bytes for 2.5 (±0.5) seconds.
A NE in a pass-through state does not send a notification message upon

raising a default K bytes condition.
The system clears the BLSR Default K Byte condition when:
• the defect is absent for 10 (±0.5) seconds

• the NE detects a loss of signal defect, loss of frame defect, or line AIS
defect

Step Action
3 Select the port that displays the BLSR default k-bytes defect warning, the
source name and additional information.
the TCP for the alarmed equipment.

4 Check the downstream far end LTE Receiver (in accordance with the
guidelines of the downstream LTE technology) to identify any Receiver
equipment failure alarms, Near End APS alarms, or incoming line facility
defect alarms.
— If no Receiver equipment failure alarms, or incoming line facility
defect alarms are present on the downstream LTE, go to the next
step.
— If any Receiver equipment failure alarms, Near End APS alarms, or
incoming line facility defect alarms are present on the downstream
LTE, discontinue this procedure and clear the noted equipment or
facility defect alarm in accordance with the downstream technology
guidelines.
—end—

Procedure 2-19
BLSR failure to switch
Probable Cause: BLSR Failure to Switch
NM Probable Cause: BLSR Failure to Switch
Condition Description: Failure to switch and protect traffic
Additional Text: Switch Failure
Default Severity: Critical, service affecting
The system raises a Failure to Switch condition against a BLSR protection

group when the system is unable to perform an automatic protection switch.
The system clears the Failure to Switch condition if the switch succeeds or if
the protection switch is no longer required because the underlying failure
cleared.


Step Action
3 Note and clear any BLSR faults: BLSR Automatic Switch To Protect, BLSR
default K byte defect, BLSR node Id mismatch or BLSR Protection Group
misconfiguration.
—end—

Procedure 2-20
BLSR force switch to protect
Object Class: MoVlsrPu
Probable Cause: BLSR Force Switch to Protect
NM Probable Cause: BLSR Force Switch to Protect
Additional Text: Force Switch to Protect
The system raises a Force Switch to Protect condition against a BLSR

protection group when a user operates a force switch to the protect path,
whether or not a switch occurs.
The system clears the Force Switch to Protect condition when the manual
state is cleared by management command or by a higher-priority automatic
switching command.


Step Action
3 Note the NE that displays the BLSR force switch to protect alarm.
4 Click Go > Protection > BLSR Ring Groups > Traffic Flow and select the
Span Type tab.
5 Select Clear from the Operation Type drop down list.
—end—

Procedure 2-21
BLSR improper APS codes
Probable Cause: BLSR Improper APS Codes
NM Probable Cause: BLSR Improper APS Codes
TL1 String: IMPROPAPS
Improper APS codes defect is the occurrence of three consecutive and

identical frames containing:
• Unused codes in bits 6-8 of byte K2 (table 6-2)

• Codes irrelevant to the specific protection switching operation request
• Requests irrelevant to the state of the ring
• ET code received (sourced) in bits 6-8 of byte K2 on the incoming
(outgoing) span, but not sourced (received) on the outgoing (incoming)
span
An example of a code irrelevant to the protection switching operation is a
reverse request with a long path indicator. It is also any code other than an
expected response or higher priority request to an existing long path ring
protection switching request (bridge or release sequence) in a 2-fiber ring or
a short path span protection switching request in a 4-fiber ring. This defect
incorporates APS timer expirations which indicate failure to receive the
expected response code within allotted time. (CoreDirector treats timer
expirations as failToSwitch defects.)
In the process of establishing a ring protection switch in a 2-fiber ring, the node
requesting the bridge may briefly receive idle codes with a short path indicator
not destined to it and not from its neighbor, as the intermediate nodes enter
pass through bidirectionally. Although expected in the transition, it is not the
proper response to a ring switch request and is therefore considered an
improper APS code defect. A signal failure response with a bridged indicator
would be a proper response. Similarly, a response with a bridged and
switched indicator and a higher priority request are also proper responses.

Requests irrelevant to the state of the ring include any span protection switch
request to a 2-fiber ring NE, and a request for a lower priority failure when the
ring is already satisfying a higher priority request.
The system raises the BLSR Improper APS Codes condition if the NE
continues to detect improper APS codes for 2.5 (±0.5) seconds.

raising a BLSR Improper APS Codes condition.
The system clears the BLSR Improper APS Codes condition when:
• the defect is absent for 10 (±0.5) seconds

defect

Step Action
and log on to the desired node. Repeat for both the near and far end NEs
(both adjacent Switches to the one raising the alarm).
the NE that displays the BLSR improper APS codes alarm.
3 Expand the NE Equipment Tree.
— If an equipment alarm exists, discontinue this procedure and execute
4 Under the Protection menu, click BLSR/MS-SP from the selection tree and
clear any user-initiated or auto protection switch conditions on the ring.
5 From the NM session on the NE raising the alarm and the adjacent NE, under
Go > Protection > BLSR Ring Groups, click the alarmed BLSR Ring Group
and click Administer. Perform a Lockout of Protection Span (LP-S) on the NE
where the alarm is being raised (near end NE).
6 If the alarm cleared at the NM workstation, stop this procedure.
7 If the alarm did not clear at the NM workstation, procedure with the following
steps.
8 From the NM session on the NE raising the alarm and the adjacent NE, under
Go > Protection > BLSR Ring Groups, click the alarmed BLSR Ring Group
and click Administer. Perform a Lockout of Protection Span (LP-S) on the NE
adjacent to where the alarm is being raised (far end NE).

steps.
10 From the NM session on the alarmed and adjacent Switches, under Go >
Protection > BLSR Ring Groups, attempt to clear the alarm by locking and
unlocking the BLSR Protection Group.
steps.
12 Reseat the Line Module (LM) at the far-end Switch.
steps.
14 Reseat the Line Module (LM) at the near -end Switch.
steps.
16 Replace the LM at the far-end Switch.
steps.
18 Replace the LM at the near -end Switch.
—end—

Procedure 2-22
BLSR inconsistent APS codes
Probable Cause: BLSR Inconsistant APS Codes
NM Probable Cause: BLSR Inconsistant APS Codes
Additional Text:
TL1 String: INCONSISTAPS
The system raises the BLSR Inconsistent APS Codes condition if the NE
continues to detect improper APS codes for 2.5 (±0.5) seconds.

raising a BLSR Inconsistent APS Codes condition.
The system clears the BLSR Inconsistent APS Codes condition when:
• the defect is absent for 10 (±0.5) seconds.

defect.

Step Action
and log on to the desired node. Repeat for both the near and far end NEs
(both adjacent Switches to the one raising the alarm).
the NE that displays the BLSR inconsistent APS codes
3 At Go > Performance Monitoring, determine the ring displaying the fault.

4 Determine all the faults associated with the port associated with the ring
identified in Step 3
5 Using the Trouble Clearing Procedures for the faults noted in Step 4, clear all
faults.
6 At Go > Monitoring > Alarms & Events, select the alarm tab and determine
if the BLSR inconsistent APS codes alarm has cleared.
—end—

Procedure 2-23
BLSR lockout of protect
Probable Cause: BLSR Lockout of Protect
NM Probable Cause: BLSR Lockout of Protect
Additional Text: Lockout of <East Span, West Span, Both East and West Spans, or
Ring> Protection
The system raises a Lockout of Protect condition against a BLSR protection

group when a user operates a lockout switch of the protect path.
The system clears the Lockout of Protect condition when the manual state is
cleared by management command.


Step Action
2 Click Go > Monitoring > Alarms & Events, select the Alarms tab. select the
alarm, and note the NE that displays the BLSR lockout of protect alarm.
3 Note the port that displays the Forced Switch To Protect warning.
4 Click Go > Protection > BLSR Ring Groups > Traffic Flow tab and select
the BLSR group identified in Step 2.
5 Select the Span Type tab.
—end—

Procedure 2-24
BLSR lockout of work
Probable Cause: BLSR Lockout of Work
NM Probable Cause: BLSR Lockout of Work
Additional Text: Lockout of <East Span, West Span, Both East and West Spans,
or Ring> Work
TL1 String: LOCKOUTOFWK
The system raises a Lockout of Work condition against a BLSR protection

The system clears the Lockout of Work condition when the manual state is


Step Action
the NE that displays the BLSR lockout of work alarm.
3 Click Go > Protection > BLSR Ring Groups > Traffic Flow and select the
Span Type tab.
—end—

Procedure 2-25
BLSR manual switch to protect
Probable Cause: BLSR Manual Switch to Protect
NM Probable Cause: BLSR Manual Switch to Protect
Additional Text: Manual Switch to Protect
The system raises a Manual Switch to Protect condition against a BLSR

protection group when a user operates a manual switch to the protect path,
whether or not a switch occurs.
The system clears the Manual Switch to Protect condition when the manual
switching command.


Step Action
the NE that displays the BLSR manual switch to protect alarm.
3 Click Go > Protection > BLSR Ring Groups > Traffic Flow tab and select
the BLSR group identified in Step 2.
4 Select the Span Type tab.
—end—

Procedure 2-26
BLSR node id mismatch
Probable Cause: BLSR Node ID Mismatch
NM Probable Cause: BLSR Node ID Mismatch
Additional Text: Node ID <Neighbor Node ID Prov> Provisioned, but Node ID

<Neighbor Node ID Detected> Detected
TL1 String: BLSRNM
The system raises the BLSR Node ID Mismatch condition if the NE continues
to detect improper APS codes for 2.5 (±0.5) seconds.
The system clears the BLSR Node ID Mismatch condition when the:
• the defect is absent for 10 (±0.5) seconds.

defect.

Step Action
and log on to the desired node. Repeat for both the near end and far end NEs
(both adjacent Switches to the one raising the alarm.
2 Click Go > Monitoring > Alarms & Events, select the Alarms tab, select the
alarm, and note the NE that displays the BLSR node id mismatch alarm.
3 Expand the Equipment Tree.

4 Under the Protection menu, click BLSR/MS-SP from the selection tree and
clear any user-initiated or auto protection switch conditions on the ring.
5 From the NM session on the Switch raising the alarm and the adjacent
Switch, click BLSR Ring Groups under the Protection menu. Click both
BLSR protection groups and check to ensure that the correct protection unit
orientation (east-west) is used. If the protection unit orientation is correct, go
to Step 7. If the protection unit orientation is incorrect, change to the correct
orientation and go to Step 6.
6 Verify that the alarm cleared at the NM workstation.
7 From the NM session on the alarmed and adjacent Switches, click BLSR Ring
Groups under the Protection menu. Ensure that duplicate node IDs are not
provisioned for two or more Switches in the ring (ring map corrupted). If no
duplications are found, go to Step 4. If duplications are found, correct
duplications and go to Step 8.
9 From the NM session on the alarmed and adjacent Switches, click BLSR Ring
Groups under the Protection menu. Attempt to clear the alarm by locking,
then unlocking the BLSR protection group.
– If the alarm cleared, stop this procedure.
– If the alarm did not clear, go to Step 11.
11 Verify that the physical (fiber) interconnects and OSRP links and the Switch
and adjacent NEs match the ring map. If they match, go to Step 15. If they do
not match, reconfigure the physical interconnects and OSRP links to the
proper configuration and go to Step 12.
13 Reseat the Line Module (LM) at the far-end Switch.
15 Reseat the Line Module (LM) at the near -end Switch.

17 Replace the LM at the far-end Switch.

19 Replace the LM at the near -end Switch.
—end—

Procedure 2-27
BLSR protection degrade condition
Object Class: BLSR
Probable Cause: BLSR Protection Degrade Detected
Condition Description: BLSR Protection Degrade condition when the

Enhanced Protection Byte Excerciser detects a fault on the Span.
Additional Text: The available protection facilities on the BLSR Span [Span ID] are
degraded.
TL1 String: BLSRPROTDEG
The BLSR Protection Degrade condition is raised when:
• a span is attached to a DX, which has Enhanced Protection Exerciser

enabled
• Line defects (AIS-L, SD-L or SF-L) are detected on the protect line

Step Action
alarm, and note the NE that displays the BLSR protection degrade
condition and note the PU and span (East or West) obtained from the
additional alarm text information.
3 Click on Go > Protection > Line Level> BLSR/MS-SP screen, select the
Protection Group that contains the alarmed Protection Unit.
4 In the detail screen, disable the Protection Exerciser by unchecking the
Protection Exerciser East or Protection Exerciser West as appropriate.
5 Click Accept.

—end—

Procedure 2-28
BLSR protection group misconfiguration
Probable Cause: BLSR Misconfiguration
NM Probable Cause: BLSR Misconfiguration
Additional Text: (see below)
TL1 String: MISCONFIG
The system raises a BLSR Protection Group Misconfiguration condition for

cases two where NE's in a given ring are provisioned with the same NodeId.
The notification additional text in this case will be:
Duplicate Node ID <Node ID duplicated> Present in the Ring

cases where NE's participating in a given ring are not all provisioned with the
same Ring ID. The notification additional text in this case will be:
Ring ID Mismatch Present in the Ring

cases where the ring includes more than 16 nodes for normal BLSR operation
or more than 24 nodes for Extended K-byte operation. The notification
additional text in this case will be:
Maximum Number of Nodes Exceeded in the Ring

cases where spans in a BLSR ring are connected to the east side of one NE
and the West side of the other. It is an error to configure E-E or W-W. The
notification additional text in this case will be:
Misconnected Spans Present

The system clears a BLSR Protection Group Misconfiguration condition when
the above underlying condition is condition is corrected or the BLSR ring is de-
provisioned.



Step Action
and log on to the desired node. Repeat for both the near end and far end NEs
(both adjacent Switches to the one raising the alarm.
alarm, and note the NE that displays the BLSR protection group
misconfiguration and note any additional alarm text information.
3 At the Go > Protection > Line Level> BLSR/MS-SP screen, open the Ring
demonstrating the alarm.
4 Record the ring settings.
5 Repeat Step 1 through Step 4 for each node in the ring, as needed, to clear
the following conditions as noted in the alarm additional text.
— Ensure that each East span in the ring connects to a West span on
the neighboring node.
Ensure that each Working Line connects to a Working Line and that each
Protect line
connects to a Protect Line around the ring.
— Ensure that each node on the ring has the same VLSR, TLSR, or 2F-
BLSR/MS-SPRing setting on all nodes.
— Ensure that each node on the ring has the same Ring ID.
— Ensure that no two nodes on the ring have the same node ID.
— Ensure that there are not more than 16 nodes in the ring.
— Ensure that asymmetric/symmetric provisioning is consistent
between nodes.
6 Correct any of the above errors.
—end—

Procedure 2-29
Circuit pack over temperature
Category: Equipment
Object Class: MoCircuitPack
Probable Cause: Replaceable Unit Problem
NM Probable Cause: Replaceable Unit Problem
NM Additional Text: DPHF, CircuitPack Over Temperature, <Isolation

Mechanism>
Condition Description: Circuit Pack Over Temperature is generated when

any one of the monitored temperatures on a card exceeds its operating
temperature range.
TL1 String: RUP
There are two types of temperatures monitored on a circuit pack: regional

ambient temperatures and device-specific die temperatures. Each monitored
temperature has its own over temperature threshold.
Circuit Pack Over Temperature is generated when any one of the monitored
temperatures on a circuit pack cross its over temperature threshold.
Circuit Pack Over Temperature is cleared when all monitored temperatures of

a circuit pack are below their max operating temperatures.


Step Action
Circuit pack over temperature alarm, and note other alarms reporting at the
node and any additional alarm information. Check for related alarms in the
following order:


bay cooling.)
ATTENTION
Do not discontinue this procedure in favor of Fan Overdriven alarms. The
fans always increase in RPM if there are any temperature-related alarms.
— If none of the above alarms exist, go to Step 3.

CAUTION
CAUTION
ESD procedures.
ATTENTION
3 Check the ambient temperature of the facility and verify that it does not
exceed the operating temperature requirements of the equipment (40°C or
104°F).
— If facility ambient temperature is below 40°C or 104°F, go to Step 4.
— If facility ambient temperature is above 40°C or 104°F, correct the
office ambient temperature, then go to Step 10.
4 Determine if the air filter or circuit pack blanks were previously checked while
executing this procedure.
— If the air filter or circuit pack blanks were checked, go to Step 8.
— If the air filter or circuit pack blanks were not checked, go to Step 5.
replace if needed.

7 Determine if the air filter was replaced in Step 5 or circuit packs blanks were
installed in Step 6.
— If the air filter was replaced or circuit pack blanks were installed, go
to Step 10.
— If the air filter was not replaced and no circuit pack blanks were
installed, go to Step 8.
8 Determine if the alarmed circuit pack was previously replaced while executing
this procedure.
— If the alarmed circuit pack was replaced, go to Step 10.
— If the alarmed circuit pack was not replaced, go to Step 9.
9 At the node, replace circuit pack in accordance with the appropriate 5400
Switch Service Manual procedure listed below:
Remove and Install Cooling Fan Unit
Remove and Install Control and Timing Module
Remove and Install Switch Module
Remove and Install SFP/XFP/CFP
Remove and Install Line Module
Remove and Install PDU Display Module
Remove and Install I/O Panel
10 Verify that Circuit pack over temperature alarm cleared at the Node
Manager workstation.
ATTENTION
It may take up to one hour for the temperature to stabilize and the alarm to
clear.

—end—

Procedure 2-30
Clock mode not normal
Category: Quality of Service
Object Class: Sync PG
Probable Cause: Clock Mode Not Normal
NM Probable Cause: Clock Mode Not Normal
NM Additional Text: Clock <mode> on <A|C>-CTM
Condition Description: The Internal Sync PG is not fully locked to a defined

reference and is in the fast-start, holdover, or free-run mode instead of the
normal mode.
TL1 String: SYNCCLK
The 5400 Switch supports four types of clock modes:
• Normal mode
• Fast-start mode
• Holdover mode
• Free-run mode
Transitions from Normal mode to the other modes due to Loss of Reference
or a Jump in Frequency produces the alarm.
Clock mode refers to the set {normal, fast start, holdover, free-run}. Normal is
the normal mode of operation when an external source is the timing reference;
however, the System can also be provisioned to run free, using its own internal
reference.
Clock Mode Not Normal condition is raise when the Internal Synch PG is
operating in fast-start, holdover, or free-run based on the autonomous
selection of these modes.
Clock Mode Not Normal condition is not raised during forced holdover or
forced free-run operation.

Clock Mode Not Normal condition clears and re-raises with the new timing
mode if the SyncPG changes between fast-start, holdover, and free-run.
Clock Mode Not Normal condition clears when the timing mode of the Sync
PG is in the normal mode of operation.


Step Action
Clock mode not normal alarm, and note the alarm. Note any additional
reported timing alarms In the following order:
— If the All References Failed alarm is present, discontinue this
procedure and perform the trouble clearing procedure for the All
redundant sync units failed alarm.
— If any Replaceable unit missing, Replaceable unit problem, or
Replaceable unit mismatch alarms are raised against either of the
Control and Timing Modules, discontinue this procedure and perform
the associated TCP.
— If the additional information indicates that the current mode is Fast
Start, wait 15 minutes, then go to Step 6.
— If the additional information indicates that the current mode is
Holdover or Free Run, go to Step 3..
CAUTION
3 Verify that at least one BITS input is active. From the field Node Manager
workstation, click Go > Administration > Timing Reference > Sync PGPU.
In the List frame, click TimingInput. Click the Protection Units tab and
check the Protect State.
— If at least one TimingInput Reference Protect State is active, go to
Step 4.
— If no BITS inputs are active, discontinue this procedure and perform
the trouble clearing procedure for the All redundant sync units
failed alarm.

4 Verify that the clock was not manually forced into Hold Over mode by
selecting the Protection Group tab and note the current operating mode.
— If the mode does not indicate Hold Over, go to Step 5.
— If the mode indicates Hold Over, change the current operating mode
to Normal and click Accept.
5 Verify that the clock mode transitions into Fast Start, then changes to
Normal.
ATTENTION
It can take up to 700 seconds for the clock mode to transition from Fast Start
to Normal.

—end—

Procedure 2-31
Communications subsystem conflict
Object Class:
Probable Cause: Configuration Mismatch
NM Probable Cause: Configuration Mismatch
Additional Text: Configuration Mismatch between the Subtended NE

provisioned communication attributes and the reported communication
attributes.
Default Severity: Warning, Not service affecting
TL1 String: COMMSUBSYSTCONFLICT
The system raises this condition when the provisioned and reported IP
address for the neighbor do not match resulting in address conflict. The
condition is cleared when the provisioned and reported IP address for the
neighbor match resolving the address conflict, or when the IP over DCC/GCC
service is de-provisioned.
The system also raises this condition when a PPP configuration conflict is
detected across a DCC/GCC link. The condition is cleared when the PPP
configuration conflict is corrected or the PPP link is deleted.


Step Action
alarm, and note the NE that displays the Communications subsystem
conflict alarm.
3 Verify that the neighbor node IP address in the IP Address field is the correct
IP address for the subtended node.

4 If the IP address is provisioned incorrectly, delete the provisioned Neighbor

node IP address and recreate with the correct IP address.
—end—

Procedure 2-32
Configuration mismatch
Object Class: PTP
NM Probable Cause: Configuration Mismatch
NM Additional Text: Local <config xxx>; far-end <yyy>. (or specific

alternatives as identified.)
Condition Description: A Replaceable Unit Type Mismatch alarm is raised if

an SFP/XFP/CFP with incompatible capabilities is installed into a port
previously defined for a different interface type.
Default Severity: Minor, Not service affecting
TL1 String: CONFIGMISMATCH
The Configuration Mismatch warning occurs when a mismatched

configuration between a local internal object and a far-end peer object is
detected. The 5400 Switch validates provisioning commands before executing
the commands, and denies commands that create non-operational or
inconsistent configurations. The 5400 Switch also accepts pre-provisioning,
which means that an illegal configuration cannot be detected until equipment
is installed or until a transmission facility is connected to another network
element, particularly to another Ciena product. When the 5400 Switch
initializes equipment, facilities or services, it validates the provisioned
attributes against the equipment and facility capabilities. In the event of
incompatibility, the Configuration Mismatch condition is declared and the
offending object is operationally disabled. The Configuration Mismatch
warning is usually reported for bundle ID, administrative weight, missing
bridge card or interface type (SONET/SDH) Configuration Mismatches.


Step Action

alarm, and note the port that displays the Configuration mismatch warning,
the source name, and additional information.
3 Note the additional information local and far end configuration parameters. If
the configuration parameters need to be changed (usually interface type) on
the terminating end point, log on to the appropriate node and repeat this step.
4 Change the configuration parameters to match the local or far end as required
then click Accept.
—end—

Procedure 2-33
Co-routed SNC is degraded
Object Class: MoCoRoutedSNCGroup
NM Probable Cause: Some but not all member SNCs are Unavailable
NM Additional Text: Some but not all SNCs in the group are Unavailable
Condition Description: Co-Routed SNC is Degraded
TL1 String: CRSNCDEGRADED
This alarm is raised when some but not all of the SNCs in a co-routed group
are unavailable.
This alarm is cleared when all of the SNCs in the co-routed group move to
Working state or Starting State.


Step Action
alarm, and note the connection that displays the Co-routed SNC is
degraded alarm.
3 Check the Group’s constraints and DTLs if applicable to ensure, sufficient
bandwidth for setup is available.
4 Ensure the Group bandwidth is sufficient to establish remaining member
SNCs.
—end—

Procedure 2-34
Co-routed SNC is unavailable
Object Class: MoCoRoutedSNCGroup
NM Probable Cause: All member SNCs are Unavailable
NM Additional Text: All of the SNCs in the group are Unavailable
Condition Description: Co-Routed SNC is Failed
TL1 String: CRSNCUNAVAILABLE
This alarm is raised when all of the SNCs in a co-routed group are unavailable.
This alarm is cleared when at least one member SNCs return to Working
state.


Step Action
alarm, and note the connection that displays the Co-routed SNC is
unavailable alarm.
3 Check the Group's constraints and DTLs if applicable to ensure, sufficient
bandwidth for setup is available.
4 Ensure the Group bandwidth is sufficient to establish member SNCs
—end—

Procedure 2-35
DC power failed
Category: Equipment
Object Class: moCircuitPackPDU
Probable Cause: DC Power Failed
NM Probable Cause: DC Power Failed
NM Additional Text: Based on underlying cause:
Low or No voltage present. Input power failed on feed <A/B[all]>
Condition Description: The input power is not present, the fuse is missing or
blown.
Alternatively, a feed has been detected with a voltage level at or below -40
VDC. This potentially represents a last gasp, as power will be disabled in the
range of -38.5±1 VDC.
TL1 String: LWBATVG
A DC Power Failed is declared if any circuit pack detects an input power at or

below -40 VDC on one or both redundant power feeds.
A DC Power Failed is cleared if all circuit packs detect an input power above -
41 VDC on both redundant power feeds.


CAUTION
ESD procedures.
Step Action

alarm, and note the DC power failed alarm in the display and note any
additional power related problems or probable cause information.
3 If the probable cause indicates an on board fuse failure, go to Step 11.
— If the rectifier fail alarm is reported by multiple circuit packs, go to
Step 4.
4 At the rear of the node, verify all power arms of the -48VDC supply voltages
at the PDU shelf in accordance with the Verifying -48 VDC Supply Voltage
procedure in the 5400 Switch Service Manual.
— If supply voltage is within spec on all measured feeds, go to Step 5.
— If no supply voltage is present on any one of the measured feeds,
there is an external rectifier failure. Restore the correct supply
voltage in accordance with local guidelines, then go to Step 5.
— Contact the next level of support for help if needed.
5 Determine if any fuse/circuit breaker is open/tripped at the PDU shelf.
— If the fuse/circuit breaker are open/tripped, go to Step 8.
— If the fuse/circuit breaker are not open/tripped, go to Step 6.
6 Open all doors and covers on the bay and visually inspect for obvious
indications of a power short. (Power short indications include smoke, burn
marks, discoloration, and so forth.)
— If obvious power short indications are present, complete this
procedure with the next level of support. Go to Step 7.
— If no obvious power short indications are present, go to Step 10.
7 At the node, refer to the 5400 Switch Service Manual and replace any burnt
or discolored modules in accordance with the appropriate procedure as listed
below, then go to Step 12.
8 For all feeds noted in Step 5, replace the fuse/toggle the circuit breaker to ON.
9 Determine if any associated fuse/circuit breaker opens/trips.
— If the fuse/breaker opens/, go to Step 12.
— If the fuse/breaker did not open/trip, go to Step 10.
— If the alarm persists, contact the next level of support.

11 At the node, replace the module in accordance with the appropriate

procedure as listed above.
ATTENTION
If alarm clears, check module history to see if the alarm is intermittent. If
alarm is intermittent, contact next level of support.

—end—

Procedure 2-36
DCN interface link failure
Object Class: Equipment
Probable Cause: DCN Interface Link Failure
NM Probable Cause: DCN Interface Link Failure
NM Additional Text: [AUX | MAIN] Port Link Failure
Condition Description: The Ethernet level link is down on one or more of the
four DCN ports (MAIN1, AUX1, MAIN2, AUX2)
TL1 String: DCNFAIL


Step Action
NE that displays the DCN interface link failure alarm.
3 Replace the Ethernet cable connecting the affected DCN port to the external
router.
— If the alarm exists go to Step 4
— If the alarm clears go to Step 5
4 Connect the affected DCN port to a different port on the external router.
—end—

Procedure 2-37
Degraded switch fabric
Object Class: MoBay
Probable Cause: Degraded Switch Fabric
NM Probable Cause: The number of active Switch Modules is less than the
number of provisioned Switch Modules.
NM Additional Text: The number of active Switch Modules is less than the
number of provisioned Switch Modules.
Condition Description: The number of active SMs in the NE drops below 8.
TL1 String: SWMTXMCD


Step Action
NE that displays the Degraded switch fabric alarm.
3 Check the number of Switch Modules inserted.
4 Verify the amount of SMs required for this configuration, are in accordance
with the ”Primary Switch Module Supported in the 5400 Switch” listed in the
5400 Switch System Description Manual.
5 Insert SMs as required.
—end—

Procedure 2-38
Ethernet forward fault indication
Object Class: ETTP
NM Probable Cause: Ethernet Forward Fault Indication
NM Additional Text: Ethernet Forward Fault
TL1 String: ETH-EFFI
An Ethernet Forward Fault Indication (EFFI) is a warning signal sent by the

downstream node when an LOS or a link failure in the Ethernet Trail
Termination Point (ETTP) is detected. The signal is sent to the upstream node
located at the far end of the Ethernet Tunnel, which raises the EFFI alarm. The
EFFI alarm clears in the reporting node when the fault in the downstream
node or the ETTP is resolved.


Step Action
NE that displays the Ethernet forward fault indication alarm, and note the
port that displays
– the Communication warning
– the source name
– probable cause
– additional information.
— If the probable cause indicates Ethernet Forward Fault Indication,
proceed to Step 3.

3 Check the far-end laser in accordance with upstream technology guidelines

for this line to identify the ETTP that may be generating this fault.
— If any alarms are reported, resolve or refer in accordance with
internal guidelines. When resolved, go to Step 4.
4 Recheck the Ethernet Forward Fault Indication alarm status.
—end—

Procedure 2-39
Ethernet-LOF
Object Class: ETTP
Probable Cause: Ethernet-LOF
NM Probable Cause: Ethernet-LOF
NM Additional Text: Ethernet Loss of Frame
Default Severity: Dynamic - MN/NSA for ports with no cross connection

provisioned, MJ/NSA for ports with protected status, or CR/SA for ports with
unprotected status
TL1 String: ETH-LOF
The Ethernet-LOF alarm is raised when an Ethernet loss of character

synchronization defect persists for 2.5 (± 0.5) seconds.


Step Action
1 From the field Node Manager workstation, launch the Node Manager
application and log on to the desired node.
alarm, and note the NE that displays the Ethernet-LOF alarm.
3 Expand the equipment tree until the alarmed port is displayed and verify that
no equipment alarms exist.
4 Check the far end upstream laser transmitter and optical line multiplexer in
accordance with that technology's guidelines. The far end upstream laser
transmitter should be checked for the following:

— SFP/XFP/CFP and LM (or equivalent if other technology) equipment

failures or Laser Bias Current TCAs should not be present.
(Corrective action: replace SFP/XFP/CFP, LM, or equivalent.)
(Corrective action: replace/provision SFP/XFP/CFP with correct rate,
wavelength, and reach. To check/correct provisioned rate of a
transmit 5400 Switch port, select the port, expand the Node Manager
configuration tree, click Go > Inventory and select the Basic tab,
then ensure that the provisioned optical rate is correct. Always lock
the port before correcting and unlock when completed.)
— The output level of the laser should be in accordance with SFP/XFP/
CFP Specifications in the 5400 Switch System Description Manual.
(Corrective action: clean the transmit port fiber connector, replace the
SFP/XFP/CFP, and/or correct improper Line Build Out (LBO) if not a
5400 Switch technology.)
go to Step 22.
— If the far end upstream laser transmitter test good, go to Step 5.
CAUTION
CAUTION
ESD procedures.
ATTENTION
5 Check if the service type of the upstream node is set to Ethernet and not set
to transmit SONET, OTN or other transport standard protocols.
— If the upstream node is a 5400 Switch, select the remote transmitter
port and click Go > Configuration > ptp and select the basic tab to
verify the service type.
— If service type indicates Ethernet go to next step. If not correct the
service type in accordance with the 5400 Switch Service Manual, go
to Step 23

6 Remove the receive fiber in accordance with 5400 Switch Service Manual,
and insert the receive fiber into a test set capable of reading bit errors, as well
as light level.
— If no bit errors are reported, go to Step 15.
Equipment Safety Practices and reinsert receive fiber into the test set.
— If the received light level is within specification, go to Step 14.
11 Determine if there are one or more WDM line systems in the upstream path
(between the transmitter checked in Step 4 and the Receiver in alarm).
— If there are no WDM line systems in the upstream path, go to Step 12.
13.
12 The output of the far end upstream transmitter was previously tested in Step
4. The low light level and resulting bit errors must be the result of a dirty or
defective fiber or connector between (but not including) the transmitter and
the receiver 5400 Switch. Isolate and clean/repair the fiber or connector
trouble in accordance with internal guidelines.
— If a defective or dirty fiber or connector was cleaned or repaired, go
to Step 22.
— If no defective or dirty fibers or connectors were cleaned or repaired,
go to Step 24.
— If any problems were isolated and corrected, go to Step 22.
— If no problems were isolated and corrected, go to Step 24.
the upstream transmitter and the receiver 5400 Switch in alarm in accordance
with internal guidelines. In addition to checking for higher rate WDM system
alarms and PM data, this isolation should include checking any fibers and
connectors on the input to the first WDM system and fibers and connectors
between multiple WDM systems, as well as output lasers from one WDM
system to another.


& Equipment Safety Practices.
17 From within the Node Manager application, expand the equipment tree to the
port in alarm.
18 Click Go > Configuring > Trail TPs and ensure that the provisioned optical
rate is correct by viewing the list frame Rate to ensure that the correct optical
rate is selected.
19 Reconnect the receive fiber and if applicable, reinstall the SFP/XFP/CFP in
accordance with the 5400 Switch Service Manual.
21 Replace the module and then go to Step 24.
22 Determine if the test set is reporting bit errors or a light level that is not within
— If the test set is reporting bit errors or a light level that is out of
— If the test set is not reporting bit errors or a light level that is out of
specification, go to
Step 23.
—end—

Procedure 2-40
Ethernet-LOS
Object Class: ETTP
Probable Cause: LOS
NM Probable Cause: LOS
NM Additional Text: Loss of Signal
Condition Description: An Ethernet loss of signal (LOS) occurs upon

detection of loss of light or loss of character synchronization.
TL1 String: LOS
A Loss of Signal (LOS) alarm is declared when the LOS defect persists for 2.5
(±0.5) seconds or an LOS defect is present when the conditions for declaring
an LOF failure are also met (LOF is inhibited when LOS is declared). The LOS
alarm is cleared when the line recovers or the port is admin locked.


Step Action
alarm, and note the port that displays the Ethernet-LOS alarm.
4 Check the far end upstream laser transmitter in accordance with that
technology's guidelines. The far end upstream laser transmitter should be
checked for the following:

– SFP/XFP/CFP and LM (or equivalent if other technology)

equipment failures or Laser Bias Current TCAs should not be
present. (Corrective action: replace SFP/XFP/CFP, LM, or
equivalent.)
be correct. (Corrective action: re-place/provision SFP/XFP/CFP
with correct rate, wavelength, and reach. To check/correct
provisioned rate of a transmit 5400 Switch port, select the port,
expand the Node Manager configuration tree, click Go > Inventory
and select the Basic tab, then ensure that the provisioned optical
rate is correct. Always lock the port before correcting and unlock
when completed).
– The laser should not be locked. (Corrective action: unlock the
port.)
– The output level of the laser should be in accordance with SFP/
XFP/CFP Specifications in the 5400 Switch System Description
Manual. (Corrective action: clean the transmit SFP/XFP/CFP fiber
connector, replace the SFP/XFP/CFP, and/or correct improper
Line Build Out (LBO) if not a 5400 Switch technology.)
— If the far end upstream laser transmitter tests bad, repair in
accordance with upstream technology guidelines, then go to Step 22.
— If the far end upstream laser transmitter tests good, go to Step 5.
CAUTION
CAUTION
ESD procedures.
ATTENTION

5 Remove the receive fiber and insert the receive fiber into a test set capable
of reading bit errors, as well as light level.
— If the test set reported bit errors, go to Step 7.
— If the test set did not report bit errors, go to Step 14.
Equipment Safety Practices, and reinsert receive fiber into the test set.
(between the transmitter checked in Step 4 and the Receiver in alarm).
— If no WDM line systems were in the upstream path, go to Step 11.
— If any WDM line systems were in the upstream path, go to Step 12.
11 The output of the far end upstream transmitter was previously tested in Step
4. The low light level and resulting bit errors must be the result of a dirty or
defective fiber or connector between (but not including) the transmitter and
the receiver 5400 Switch. Isolate and clean/repair the fiber or connector
to Step 21
— If no defective or dirty fibers or connectors was cleaned or repaired
in Step 23
the upstream transmitter and the receiver 5400 Switch in alarm in accordance
with internal guidelines. In addition to checking for higher rate WDM system
alarms and PM data, this isolation should include checking any fibers and
connectors on the input to the first WDM system and fibers and connectors
between multiple WDM systems, as well as output lasers from one WDM
system to another.

16 From within the Node Manager application, expand the equipment tree and
select the port in alarm.
rate is selected.
accordance with the procedures listed in the 5400 Switch Service Manual.
19 Verify that the alarm cleared at the Node Manager workstation.
20 Replace the module then go to Step 23.
Step 22.
—end—

Procedure 2-41
Ethernet-RFI
Object Class: ETTP
Probable Cause: Ethernet-RFI
NM Probable Cause: Ethernet-RFI
NM Additional Text: Remote Fault
Condition Description: An ethernet client has received an indication that its

transmitted signal is not being received at the far end.
Default Severity: Dynamic - WN/NSA for ports with no cross-connection

provisioned, WN/NSA for ports with protected status, or MJ/SA for ports with
unprotected status.
TL1 String: ETH-RFI
A Ethernet Remote Fault Indication (ERFI) is a warning signal used to alert

upstream equipment that a defect (for example, framing error in received
signal) has been detected. This signal informs an upstream node that the
downstream node detected an error. Resolving the fault in the downstream
node or the customer equipment that transmitted the signal to the downstream
node, clears the ERFI alarm in the reporting node.
An Ethernet Remote Failure Indicator alarm is declared when the ethernet far
end defect persists for 2.5 (±0.5) seconds and is cleared when the ethernet
far end defect is absent for 10 (±0.5) seconds.


Step Action
alarm, and note the port that displays the Communication warning, the
source name, probable cause and additional information.

3 If the probable cause and additional information indicates Ethernet RFI then
proceed to Step 4.
4 Check the signal received by the downstream node to identify this fault.
5 If any alarms are reported, resolve or refer in accordance with internal
guidelines. When resolved, go to Step 6.
6 Recheck the Ethernet Remote Fault Indication alarm status.
—end—

Procedure 2-42
Fan overdriven
Category: Equipment
Probable Cause: Fan Overdriven
NM Probable Cause: Fan Overdriven
NM Additional Text: The maximum allowable fan speed is not sufficient to

maintain the setpoint temperature of a device residing on <CircuitPack ID>.
Condition Description: This alarm is generated when the temperature

control system needs to set the fan speed higher than the maximum possible
(8000 RPM) in order to maintain the setpoint temperatures of all devices in the
system.
TL1 String: HITEMP
A Fan Overdriven alarm is raised when the temperature control algorithm

attempts to increase the fan speed beyond 8000 RPM in order to maintain the
setpoint temperatures of all devices in the system.
A Fan Overdriven alarm indicates that a device on a circuit pack is above its
setpoint temperature, but not necessarily above its max operating threshold.
Fan Overdriven is cleared when the commanded fan speed falls below 7500
RPM.


Step Action
Fan overdriven alarm, and note any additional equipment alarm information
related to the node.


bay cooling.)
— If there are no related equipment or high temperature alarms, go to
Step 3.
CAUTION
ESD procedures.
ATTENTION
replace if needed.
5 Wait 30 minutes, and then verify that the alarm cleared at the Node Manager
workstation.
—end—

Procedure 2-43
Fan speed mismatch
Category: Equipment
Object Class: MoCircuitPackCFU
Probable Cause: Fan Speed Mismatch
NM Probable Cause: Fan Speed Mismatch
NM Additional Text: .
TL1 String: FANSPDMISMTCH
Fan Speed Mismatch condition is raised when the actual fan speed does not
match the fan speed set by the System.
Fan Speed Mismatch condition is cleared when the actual fan speed matches
the fan speed set by the System.


Step Action
Fan speed mismatch alarm, and note any additional equipment alarm
information related to the node.
bay cooling.)
— If there are no related equipment or high temperature alarms, go to
Step 3.

CAUTION
ESD procedures.
3 At the node, identify the failed fan tray assembly and immediately replace with
a new fan tray assembly.
—end—

Procedure 2-44
FCC automatic switch
Probable Cause: FCC Automatic Switch
NM Probable Cause: FCC Automatic Switch
NM Additional Text:
TL1 String: DEGRADED
This warning is raised against a revertive FCC Protection Group if LOP/AIS-

P/SF-P/SD-P is introduced on the work path and the protect path is error-free
and when a protection group is provisioned from non-revertive to revertive (if
it is not on the working line at the time of the provisioning change). The FCC
Automatic Switch warning clears if a protection group is provisioned from
revertive to non-revertive and when the target object is no longer automatically
protected.


Step Action
alarm, and note the port that displays the FCC automatic switch condition.

interior 5400 Switch network, the upstream LTE or MSTE is another 5400
Switch. If the line in alarm is a network drop, the upstream technology is
typically an Aggregator/MUX. The far end upstream LTE or MSTE laser
should be checked for the following:
(Corrective action: replace port or equivalent with correct rate,
transmit 5400 Switch port, expand the Node Manager configuration
tree, select the Physical TP and Basic tabs, and ensure that the
provisioned optical rate is correct. Always lock the port before
correcting and unlock when completed.)
equivalent.)
(Corrective action: clean the transmit port or equivalent fiber
connector, replace the port or equivalent, and/or correct improper
LBO if not a 5400 Switch technology.)
go to Step 5.
CAUTION
CAUTION
ESD procedures.

ATTENTION
5 Remove the alarmed port receive fiber. Insert the receive fiber into a test set
capable of reading bit errors and light level.
or MSTE in alarm).
14.
Step 12.
— If a defective or dirty fiber or connector was cleaned or repaired in
— If no defective or dirty fibers or connectors were cleaned or repaired
in Step 12, go to Step 26.

tabs.
selected.
21 Reconnect the receive fiber, then reinstall the port.
23 Replace the port with a shelf spare and then go to Step 26.
—end—

Procedure 2-45
FCC crossconnect degraded
Object Class: FCC
Probable Cause: Flexible cross-connect degraded
NM Probable Cause: Flexible cross-connect degraded
NM Additional Text: FCC is degraded. Traffic may be affected.
Condition Description: An FCC has one or more endpoints in a disabled

state but at least one that is good.
TL1 String: DEGRADED
The Flex Cross-Connect Degraded condition is raised against a flexible cross-

connect when the flexible cross-connect availability status remains in the
degraded state for (2.5 +/- 0.5) seconds and clears when the flexible cross-
connect availability status is no longer degraded.


Step Action
FCC crossconnect degraded alarm, and note any additional alarm
information.
3 View the Current Alarms details screen and note any related Unavailable
(SNC) alarms.
— If a SNC related alarm exists, discontinue this procedure and perform
the Unavailable (SNC) alarm TCP.
— If an equipment alarm does not exist, isolate the problem to the
outgoing drop and perform the associated downstream TCP.

4 Check the far end laser in accordance with downstream technology

guidelines for this line to identify the LTE/PTE that may be generating this
alarm.
— If no upstream alarm can be identified, go to Step 5.
5 Recheck the alarm status.
—end—

Procedure 2-46
FCC disabled
Object Class: FCC
Probable Cause: Flexible cross-connect disabled
NM Probable Cause: Flexible cross-connect disabled
NM Additional Text: FCC is unavailable. Traffic may be affected.
Condition Description: All endpoints in the FCC are disabled
TL1 String: PRCDRERR
The Flex Cross-Connect Disabled condition is raised against a flexible cross-

connect when the flexible cross-connect availability status remains in the
disabled state for (2.5 +/- 0.5) seconds. The disable state is when all the TTPs
(ports) supporting the CTPs are either locked or in LOS state. The condition
clears when the flexible cross-connect availability status is no longer disabled.


Step Action
FCC disabled alarm, and note any additional alarm information.
3 Click Go > Provisioning > Flexible Cross Connect and note the related
CTP.
4 At Go > Configuring > Connection TP screen. Note the related port for the
retrieved CTP and FCC.
5 If the CTP is in a VCG being protected by GigE Port protection then the
procedure for GigE Port Protection should be followed to isolate the problem.
6 At Go > Monitoring > Alarms and Events Summary and details screen to
verify that no other communication or equipment alarm related to the
retrieved port and other equipment exists.

— If a communication or equipment alarm exists, discontinue this

procedure and perform the TCP for the alarmed facility or equipment.
— If no communication or equipment alarm exists, go to Step 8.
7 At Go > Configuring > Physical TP tab. View the Configuring Physical TP
screen for the retrieved port and ensure that the Admin States are UNLOCK
and the Operational States are ENABLE.
— If Admin State is Locked, change the Admin State to Unlocked
and go to Step 5.
— If Operational State is Disabled and the Admin State is Unlocked,
go to Step 9.
— If Operational State is Enabled and the Admin State is Unlocked,
go to Step 14.
8 Check the far end laser in accordance with upstream technology guidelines.
— If upstream technology tests bad, repair in accordance with upstream
technology guidelines and go to Step 14.
— If upstream technology tests good, go to Step 10.
CAUTION
CAUTION
ESD procedures.
ATTENTION
9 Remove the SFP/XFP/CFP in accordance with 5400 Switch Service Manual

procedures and inspect incoming fiber and SFP/XFP/CFP fiber connector.
Clean the incoming fiber in accordance with Ciena Standard Cleaning &
Equipment Safety Practices and the SFP/XFP/CFP fiber connector in
accordance with Ciena Standard Cleaning & Equipment Safety Practices.
11 Remove the SFP/XFP/CFP in accordance with 5400 Switch Service Manual
procedures, connect the incoming fiber to a SONET test set, and determine
if an alarm is incoming.

— If the test set reports an incoming alarm, the trouble is external.

Isolate and repair the upstream fiber or connector problem before
proceeding to Step 13. Consult the next level of support if necessary.
— If the test set does not report incoming an alarm, reconnect fiber and
go to Step 14.
13 Replace the SFP/XFP/CFP in accordance with the procedures listed in the
5400 Switch Service Manual and verify that the alarm cleared at Node
Manager.
—end—

Procedure 2-47
FCC fail to switch
Probable Cause: FCC Failure to Switch
NM Probable Cause: FCC Failure to Switch
Condition Description: FCC is unable to perform automatic protection

switching because of defects on both the Work and Protect paths


Step Action
3 Note and clear any path faults protection switch byte failure, ASNCP Failure
to Switch, and far end protect line fail alarms.
—end—

Procedure 2-48
FCC forced switch to protect
Probable Cause: FCC Force Switch to Protect
NM Probable Cause: FCC Force Switch to Protect
NM Additional Text:
Condition Description: Forced Switch of Work to Protect
An FCC forced switch to protect warning is raised when a forced switch to the
protect path is initiated. The warning clears when a higher-priority switch is
initiated or when the forced switch is released.


Step Action
alarm, and note the module that displays the FCC fail to switch condition.
4 Verify the state of the working path in the Administer/Status field; it should be
OKAY.
7 If there are several locked protection units in the FCC group, from the list
FCC SNCP protection group.

9 Click Accept.
—end—

Procedure 2-49
FCC forced switch to working
Probable Cause: FCC Force Switch to Work
NM Probable Cause: FCC Force Switch to Work
NM Additional Text:
Condition Description: FCC Forced Switch to Work
An FCC Forced Switch To Working warning is raised when a forced switch to

the work path is initiated by the user. The warning clears when a higher-


Step Action
alarm, and note the module that displays the FCC forced switch to working
condition.
OKAY.
7 If there are several locked protection units in the FCC group, from the list

8 Click Accept.
—end—

Procedure 2-50
FCC lockout of protect
Probable Cause: FCC Lockout of Protect
NM Probable Cause: FCC Lockout of Protect
Condition Description: Lockout of Working
An FCC lockout of protect warning is raised when a when a lockout of

protection is initiated by the user. The warning clears when the lockout is
released.


Step Action
alarm, and note the module that displays the FCC lockout of protect
condition.
5 If there are several locked protection units in the SNCP group, from the list
—end—

Procedure 2-51
FCC manual switch to protect
Probable Cause: FCC Manual Switch to Protect
Condition Description: Manual Switch of Work to Protect
An FCC Manual Switch To Protect warning is raised when a manual switch to

the protect path is initiated and the FCC protection feature is provisioned as
revertive. The warning clears when the manual state is cleared by
management command, when a higher-priority automatic switching command
is initiated, or when the user initiates a manual switch to the working path.


Step Action
alarm, and note the module that displays the FCC manual switch to protect
condition.
Go > Protection > Path Level > SNCP > Group tab, select the FCC SNCP
protection group from the list.
—end—

Procedure 2-52
FCC manual switch to working
Probable Cause: FCC Manual Switch to Work
NM Probable Cause: FCC Manual Switch to Work
NM Additional Text:
Condition Description: FCC Manual Switch to Working
An FCC Manual Switch To Working warning is raised when a manual switch

to the working path is initiated and the FCC protection feature is provisioned
as revertive. The warning clears when the manual state is cleared by
management command, when a higher-priority automatic switching command
is initiated, or when the user initiates a manual switch to the protect path.


Step Action
alarm, and note the module that displays the FCC manual switch to
working condition.
4 Verify the state of the protect path in the Administer/Status field; it should be
OKAY.

9 Click Accept.
—end—

Procedure 2-53
FEC type mismatch
Object Class: TTP
Probable Cause:
NM Probable Cause: FEC Type Mismatch
NM Additional Text:
Condition Description: FEC Type provisioning Mismatch
Default Severity: Minor, Non-service affecting
TL1 String: FECM


Step Action
alarm, and note the module that displays the FEC type mismatch condition.
3 Check the FEC settings at both the upstream and local nodes.
4 Change the configuration parameters to the local or far end nodes as
required.
5 Verify the FEC settings at both ends are similar.
6 Click Accept.
—end—

Procedure 2-54
Firmware mismatch
category: Equipment
Object Class: Any LM
Probable Cause: Firmware Mismatch
NM Probable Cause: Firmware Mismatch
NM Additional Text: <equipment AID>, <equipment_name >, <CLEI>

missing.
TL1 String: FWMISMATCH
In most cases, software and firmware upgrade to the node and its modules
does not affect service, and the node updates them automatically when
necessary. However, there are a few FPGAs that cannot be upgraded in-
service. Rather than causing a service hit as a side-effect of an upgrade, the
System declares a firmware mismatch condition, which flags the human
operator to execute an upgrade procedure (typically by way of switching traffic
or administratively locking the module).
Firmware mismatch can occur in two ways: either the module is newly
installed, in which case it is not providing service and can be upgraded
automatically, or some level of the control plane is
re-booting, in which case the data plane may be carrying service and firmware
cannot be automatically upgraded.


Step Action
alarm, and note the circuit pack that displays the alarm.

3 Determine if the LM is carrying traffic.

— If the LM is not carrying traffic, go to Step 4.
— If the LM is carrying traffic, move traffic off of the LM prior to
performing Step 4.
CAUTION
4 Click Inventory and expand the equipment tree to the LM identified in Step 2.
5 Place the LM into HIR and click Accept.
6 Remove LM from HIR and click Accept.
— If the alarm did not clear, contact the next level of support
—end—

Procedure 2-55
Generic AIS
Object Class: TTP (CBR)
Probable Cause: Generic AIS
NM Probable Cause: Generic AIS
NM Additional Text: PN11 Generic AIS Signal

provisioned, MJ/NSA for ports with protected status, or MJ/SA for ports with
unprotected status
TL1 String: Generic AIS
The CBR PN11 alarm condition is raised when a dPN11 defect persists for 2.5
(±0.5) seconds.


Step Action
alarm, and note the NE that displays the Generic AIS alarm.
3 In the upstream NE:
– If TTP is unlocked go to Step 4:
– If SNC has an unavailable alarm then go to Step 5.
4 Lock TTP and go to Step 6
5 Clear SNC alarm and go to Step 6
—end—

Procedure 2-56
GFP UPI mismatch
Object Class: CG
Probable Cause: GFP UPI Mismatch
NM Probable Cause: GFP UPI Mismatch
NM Additional Text: Expected UPI value(s), Received UPI value(s)
TL1 String: GFP-UPM
The UPI Mismatch alarm is raised against the GFP object if an dUPM defect
persists for 2.5 (± 0.5) seconds.
The GFP UPM condition clears when the dUPM defect is absent for 10 (± 0.5)
seconds.


Step Action
alarm, and note the MoGfpAp object that displays the GFP UPI mismatch
alarm.
3 Verify the expected and received UPI code in the additional text of the alarm.
4 If the UPI transmitted from the remote end MoGfpAp object is different than
the one expected, check the configuration on the MoGfpAp object on both
near end and far end of the Ethernet tunnel.
5 Correction of the configuration, clears the alarm.

ATTENTION
UPI values on the MoGfpAp is not user configurable in R 2.1. It is driven by
the TransparencyMode on the ETTP object.
6 Verify the TransparencyMode on the associated ETTP objects are same on

both ends of the tunnel.
7 Correcting the above configuration, clears the alarm.
—end—

Procedure 2-57
In loopback condition
Object Class: CTP, GTP, PTP
Probable Cause: In Loopback Mode
NM Probable Cause: In Loopback Mode
Condition Description: Loopback is enabled on a a CTP, GTP, or PTP.
TL1 String: Not applicable
The Loopback Mode warning is raised whenever a CTP, GTP, or PTP is in the
loopback mode. The loopback mode warning clears when a loopback is
disabled on a CTP, GTP, or PTP.


Step Action
condition, and note the port that displays the In loopback condition warning.
3 Click Go > Configuring > Ptp.
4 Select the port displaying the alarm.
5 Select the Basic tab.
6 In the Parameter section, select None from Loopback type drop down menu.
7 Click Accept.
—end—

Procedure 2-58
In loopback mode
Object Class: TTP
Probable Cause: Loopback
NM Probable Cause: Loopback
Condition Description: Loopback is enabled on a a TTP.
The Loopback Mode warning is raised whenever a TTP is in the loopback

mode. The loopback mode warning clears when a loopback is disabled on a
TTP.


Step Action
condition, and note the TTP that displays the In loopback mode warning.
3 Click Go > Configuring > Trail TTPs and select the TTP.
5 Select None from Loopback type drop down menu.
6 Click Accept.
—end—

Procedure 2-59
Input power fuse
Category: Equipment
Object Class: MoCircuit Pack- PDU
Probable Cause: Input Power Fuse
NM Probable Cause: Input Power Fuse
NM Additional Text: Input power fuse/breaker associated with <A/B[all]> is

detected in an open/tripped state
Condition Description: The fuse/breaker associated with a given redundant

input power feed is in an open/tripped state.
TL1 String: INPUTPWRFUSE
An Input Power Fuse is raised when the primary control module detects a
fuse/breaker in an open/tripped state.
An Input Power Fuse is cleared when the primary control module no longer
sees a fuse/breaker in an open/tripped state for a period of 10 seconds.


CAUTION
ESD procedures.
Step Action
alarm, and note the module reporting the alarm and note any additional
power related problems or probable cause information.

3 At the node, replace circuit pack in accordance with the appropriate

procedures listed in the 5400 Switch Service Manual.
—end—

Procedure 2-60
Intrusion detection
Category: Alert
Object Class: MoAccount
Probable Cause: IntrusionDetection
NM Probable Cause: IntrusionDetection
Default Severity: Security Alert
The Intrusion Detection condition applies to all user accounts (including the
superuser account) locked when the max number of login attempts is
exceeded.

Step Action
1 Verify and clear intrusion in accordance with local procedures.

—end—

Procedure 2-61
LAPS automatic switch to protect
Object Class: APS PG
Probable Cause: APS Automatic Switch to Protect
NM Probable Cause: APS Automatic Switch to Protect
NM Additional Text:
Condition Description: Auto switch due to defects.
TL1 String: WKSWPR
An automatic switch to protect condition is raised when an automatic switch

operation is detected in a LAPS protection group. The condition is declared
against the defective line; the working line in a revertive protection group.
ATTENTION
This Ciena requirement supersedes GR-474 R8-34 [397], R8-36 [399]
An automatic switch to protect condition is also raised if a protection group is

provisioned from non-revertive to revertive, and if it is not on the working line
at the time of the provisioning change.
An automatic switch to protect condition clears if any of the following occur:
• A protection group is provisioned from revertive to non-revertive

• A higher-priority automatic switching command is initiated
• The line is removed from the protection group.

Step Action

LAPS automatic switch to protect alarm, and note the port that displays the
automatic switchover condition.
(Corrective action: replace port SFP/XFP/CFP or equivalent with
equivalent.)
— The output level of the laser (Node Manager PRTP Physical tab)
technology.)
go to Step 5.

CAUTION
CAUTION
ESD procedures.
ATTENTION
or MSTE in alarm).
14.


Step 14.
tabs.
selected.
22 Reconnect the receive fiber, then reinstall the port in accordance with the

—end—

Procedure 2-62
LAPS channel mismatch
Object Class: APS
Probable Cause: APS Channel Mismatch Failure
NM Probable Cause: APS Channel Mismatch Failure
NM Additional Text: Linear APS Channel Mismatch
Condition Description: K-byte channel mismatch detected.
TL1 String: APSCM
Unless working in a 1+1 unidirectional mode, LTE or MSTE monitors the

channel numbers in the K1 Protection Switching byte (bits 5 through 8) and
received K2 byte (bites 1 through 4) for channel mismatch. A defect is
declared if there is a mismatch for 50 milliseconds, or if the bits are not
identical in three consecutive frames. A Channel Mismatch Failure is typically
caused by a provisioning error.
A LAPS Channel Mismatch condition is raised against the protection line

when a LAPS group has a mismatch between the transmitted K1 and received
K2 bytes.
The channel mismatch failure is raised if the channel mismatch defect persists
for 2.5 (± 0.5) seconds and clears when the channel mismatch defect is
absent for 10 (± 0.5) seconds.


Step Action

LAPS channel mismatch alarm, and note the port that displays the warning,
3 Note the local and far end configuration parameters. If the configuration
parameters need to be changed on the terminating end point, log on to the
appropriate node and repeat this step.
4 Change the configuration parameters to match the local or far end as
required.
5 Click Accept.
—end—

Procedure 2-63
LAPS fail to switch
Probable Cause: APS Failure to Switch
NM Probable Cause: APS Failure to Switch
NM Additional Text: Switch Failure Channel(s): Channel Number
Condition Description: Failure to switch and protect traffic
A Fail to Switch condition occurs when the APS Protection Group is unable to
perform automatic protection switching. Protection switch failure could be
caused by APS faults (Protection Switch Byte Fail, Channel Mismatch Failure,
or Far End Protect Line Failure), in which case root-cause analysis
suppresses this condition and escalates the root cause to critical and service
effecting. Failure might also be due to a (local or remote) LM re-boot, during
which it is unable to participate in K byte exchanges.


Step Action
3 Note and clear any LAPS faults: LAPS Automatic Switch To Protect, LAPS
Channel Mismatch, LAPS Far End Protection Line Failure, LAPS Mode
Mismatch, LAPS Protection Switch Byte Failure
—end—

Procedure 2-64
LAPS far end protection line failure
Probable Cause: APS Far End Protection Line Failure
NM Probable Cause: APS Far End Protection Line Failure
TL1 String: FEPRLF
Line-terminating equipment monitors the K1 byte for Far End Protection

failure. A defect is detected if there is a Failed Signal (FS) for three
consecutive frames. A Far End Protect Line Fail alarm is raised if the defect
persists for 2.5 seconds and clears when the defect is absent for 10 (¬± 0.5)
seconds. The defect is also cleared when the protection line fails at the near
end, or when the protection line is administratively locked.


Step Action
alarm, and note the port that displays the LAPS far end protection line
failure warning, the source name, and additional information.
3 Note and clear any LAPS faults.
4 Protect Line Failure.
5 Verify that the alarm clears.
—end—

Procedure 2-65
LAPS forced switch to protect
Probable Cause: APS Force Switch to Protect
NM Probable Cause: APS Force Switch to Protect
NM Additional Text:
Condition Description: APS Forced Switch to Protect
A Forced Switch To Protect warning occurs when a management operation

causes a linear APS group to enter a non-automatic state. A Forced Switch To
Protect condition is raised against a LAPS protection group when a user
operates a forced switch to the protect path, whether or not a switch occurs.
The warning clears when the forced state is cleared by management
command or by a higher-priority automatic switching command.


Step Action
alarm, and note the port that displays the LAPS forced switch to protect
warning.
3 Under the Go > Protection > Line Level > APS/MSP > APS (or MSP) Group
tab, select the APS or MSP group identified in Step 2.
4 Click Administer. The Administer Group dialog box opens. In the table, click
the working line to be cleared.
5 In the Operations group box, select Forced or Manual from the Switch Type
drop-down list.
6 In the Operations group box, click Release Protection.

— A Confirmation dialog box opens.

— In the Results group box, the Protection Status box displays the
status of the operation being performed on the working or protect
line.
7 Click Yes to reload the changed object and return to the APS Groups screen.
The Protection Status column displays the status of the request: No
Request.
—end—

Procedure 2-66
LAPS forced switch to working
Probable Cause: APS Force Switch to Work
NM Probable Cause: APS Force Switch to Work
NM Additional Text:
Condition Description: APS Forced Switch to Work
TL1 String: FRCDPRSWBK
A Forced Switch To Working warning occurs when a management operation

causes a linear APS group to enter a non-automatic state. A Forced Switch To
Working condition is raised against a LAPS protection group when a user
operates a forced switch to the work path, whether or not a switch occurs. The
warning clears when the manual state is cleared by management command
or by a higher-priority automatic switching command.


Step Action
alarm, and note the port that displays the LAPS forced switch to working
warning.
drop-down list.


line.
Request.
—end—

Procedure 2-67
LAPS invalid APS mode
Probable Cause: Invalid APS Mode Failure
NM Probable Cause: Invalid APS Mode Failure
NM Additional Text:
Condition Description: Invalid APS Mode
TL1 String: APSB
LTE monitors the mode of operation indicators in the incoming K2 byte for
invalid APS Modes. An invalid mode condition is raised when five consecutive
samples (which may or may not be consecutive frames) contain '000', '001',
'010' or '011' in bits 6 through 8 of K2. An invalid mode clears when five
consecutive samples (which may or may not be consecutive frames) contain
'100' or '101' in bits 6 through 8 of K2. This defect is not cleared when an
associated AIS-L or RDI-L exists.
The invalid mode condition is raised if the invalid mode condition persists for
2.5 (¬± 0.5) seconds and clears when the invalid mode condition is absent for
10 (¬± 0.5) seconds.


Step Action
alarm, and note the port that displays the LAPS invalid APS mode warning,

4 Check the downstream far end LTE (in accordance with the guidelines of the
downstream LTE technology) to verify that the LTE is sending valid APS
modes in the K2 byte.
—end—

Procedure 2-68
LAPS lockout of protection
Probable Cause: APS Lockout of Protect
Condition Description: APS Lockout of Protect
The Lockout Of Protection warning appears whenever a user locks a

protection line in an APS/MSP protection group.


Step Action
alarm, and note the port that displays the LAPS lockout of protection
warning.
3 From the list under the Go > Protection > Line Level > APS/MSP > APS (or
MSP) Group tab, select the APS or MSP group identified in Step 2.
4 Click the Administer button.
5 Choose the locked out protection line.
6 Click the Release Protection button.
7 Click Accept.
8 Select the Traffic Flow tab.
9 Ensure that the working line is No Request and the protect line is Idle.
—end—

Procedure 2-69
LAPS lockout of working
Probable Cause: APS Lockout of Work
NM Probable Cause: APS Lockout of Work
NM Additional Text:
Condition Description: APS Lockout of Working
TL1 String: LOCKOUTOFWK
The Lockout Of Working warning appears whenever a user locks a working

line in an APS/MSP protection group.


Step Action
alarm, and note the port that displays the LAPS lockout of working warning.
3 From the list under the Go > Protection > Line Level > APS/MSP > APS (or
MSP) Group tab, select the APS or MSP group identified in Step 2.
4 Click the Administer button.
5 Choose the locked out working line.
6 Click the Release Protection button.
7 Click Accept.
8 Select the Traffic Flow tab.
9 Ensure that the working line is No Request and the protect line is Idle and
end this procedure.


—end—

Procedure 2-70
LAPS manual switch to protect
Probable Cause: APS Manual Switch to Protect
NM Probable Cause: APS Manual Switch to Protect
NM Additional Text:
Condition Description: APS Manual Switch to Protect
A Manual Switch To Protect warning occurs when a management operation

causes a linear APS group to enter a non-automatic state. A Manual Switch
To Protect condition is raised against a LAPS protection group when a user
operates a manual switch to the protect path, whether or not a switch occurs.
The warning clears when the manual state is cleared by management


Step Action
alarm, and note the port that displays the LAPS manual switch to protect
warning.
drop-down list.


line.
Request.
—end—

Procedure 2-71
LAPS manual switch to working
Probable Cause: APS Manual Switch to Work
NM Probable Cause: APS Manual Switch to Work
Condition Description: APS Manual Switch to Work
TL1 String: MANPRSWBK
A Manual Switch To Working warning occurs when a management operation

causes a linear APS group to enter a non-automatic state. A Manual Switch
To Working condition is raised against a LAPS protection group when a user
operates a manual switch to the work path, whether or not a switch occurs.
The warning clears when the manual state is cleared by management


Step Action
alarm, and note the port that displays the LAPS manual switch to working
warning.
drop-down list.

line.
Request.
—end—

Procedure 2-72
LAPS mode mismatch
Object Class: APS
Probable Cause: APS Mode Mismatch Failure
NM Probable Cause: APS Mode Mismatch Failure
NM Additional Text: Linear APS Mode Mismatch
Condition Description: APS K2 byte mode mismatch detected.
TL1 String: APSMM
LTE monitors the mode of operation indicators in the incoming K2 byte for APS
Mode Mismatch failures, unless working in a 1+1 unidirectional mode. A
mismatch occurs when LTE configured for 1+1 receives an indication from a
far end LTE that is configured for 1:N or vice versa, or when an LTE configured
for bidirectional switching receives an indication from a far end LTE that is
configured for unidirectional switching or vice versa. This defect is not raised
or cleared when an associated AIS-L exists.
The mode mismatch failure is raised if the mode mismatch defect persists for
2.5 (± 0.5) seconds and clears when the mode mismatch defect is absent for
10 (± 0.5) seconds.


Step Action
LAPS mode mismatch alarm, and note the port that displays the warning,

4 Change the configuration parameters to match the local or far end as required
then click Accept.
—end—

Procedure 2-73
LAPS protection switch byte failure
Probable Cause: APS Protection Switch Byte Failure
NM Probable Cause: APS Protection Switch Byte Failure
NM Additional Text: Linear APS Protection Byte Failure
Condition Description: K1 Protection Switching byte failure.
TL1 String: APSB
The LTE monitors the K1 Protection Switching byte for failure. A defect is
declared if an Inconsistent Code (no 3 consecutive bytes are the same in the
past 12 bytes) or an Invalid Code (non-defined) is received for three
consecutive frames.
A Protection Switch Byte Failure is raised if the defect persists for 2.5 seconds
and clears when the defect is absent for 10 (¬± 0.5) seconds. This defect is
not raised or cleared when an associated AIS-L exists.


Step Action
LAPS protection switch byte failure alarm, and note the port that displays
the warning, the source name, and additional information.

3 Check the downstream far end LTE Receiver (in accordance with the
guidelines of the downstream LTE technology) to identify any Receiver
equipment failure alarms, Near End APS alarms, or incoming line facility
defect alarms.
— If no Receiver equipment failure alarms, Near End APS alarms, or
LTE, go to the next step.
— If any Receiver equipment failure alarms, Near End APS alarms, or
LTE, discontinue this procedure and clear the noted equipment or
facility defect alarm in accordance with the downstream technology
guidelines.
—end—

Procedure 2-74
LCH
Object Class: TTP
Probable Cause: LCH
NM Probable Cause: LCH
NM Additional Text: Provisioned Channel Power Low
Default Severity: Dynamic - MN/NSA for ports with no cross-connection

provisioned, MN/NSA for ports with protected status, or CR/SA for ports with
unprotected status.
TL1 String: LCH
The LCH alarm is raised when the received optical power for the provisioned
optical channel is below the LOS threshold.
The LCH alarm clears when the received optical power for the provisioned
optical channel is 1.0 dBm above the LOS threshold.


Step Action
alarm, and note the port that displays the LCH alarm.

4 Verify that the received light level at the provisioned wavelength is within
specification, in accordance with interface Specifications listed in the 5400
Switch System Description Manual. Because this interface may contain
multiple wavelengths, the wavelength received light level must be verified with
an Optical Spectrum Analyzer.
—end—

Procedure 2-75
LOC
Object Class: TTP
Probable Cause: LOC
NM Probable Cause: LOC
NM Additional Text: Loss of Clock

provisioned, MN/NSA for ports with protected status, or MJ/SA for ports with
unprotected status.
TL1 String: LOC
The LOC alarm is raised when is raised when the measured frequency of the
input client clock exceeds the allowed frequency deviation outlined by the
corresponding standard or when the provisioned line rate at the far-end circuit
pack does not match the line port rate at the near-end circuit pack.
The LCH alarm clears when the incoming clock of the OTU payload is
recovered.


Step Action
alarm, and note the port that displays the LOC alarm.
3 Ensure the subtending equipment is working properly and providing an error-
free signal that meets the allowed frequency deviation specifications.
4 Ensure that all of the optical fibers between the subtending equipment Tx port
and the Rx port are correctly connected.
5 Ensure that the line rate or the client type is the same for both ends of the link

6 Use an optical power meter to measure the received power level at the Rx
port of the alarmed circuit pack. Verify if the Rx power level is within the
operational threshold. Record the value.
7 Use a cleaning kit to clean all the connectors between the subtending
equipment Tx port and the alarmed Rx port.
8 Record the operating power level after cleaning each connector and compare
it to the value recorded in Step 6.
— If the original alarm has cleared then go to Step 10.
— If the original alarm exist then go to Step 9.
9 Warm restart the alarmed circuit pack.
—end—

Procedure 2-76
LOF
Object Class: TTP
Probable Cause: LOF
NM Probable Cause: LOF
NM Additional Text: Loss of Frame
Condition Description: LOF detected.

unprotected status
TL1 String: LOF
Unless a LOS defect is also present, an LOF alarm is declared when an LOF
defect persists for 2.5 (±0.5) seconds and an LOS alarm is not present (LOF
is inhibited when LOS is declared). If the LOS clears and the LOF conditions
are still present, the LOF alarm is declared.
An LOF alarm clears when the LOF defect is absent for 10 (± 0.5) seconds.
ATTENTION
The alarm cause information reflects the conditions at the time the failure
occurred.


Step Action
alarm, and note the port that displays the LOF alarm.


— The laser should not be locked. (Corrective action: unlock the port.)
go to Step 21.
— If the far end upstream LTE or MSTE laser and optical multiplexer test
good, go to Step 5.
CAUTION
CAUTION
ESD procedures.

ATTENTION
as light level.
(between the transmit LTE or MSTE checked in Step 4 and the Receive LTE
or MSTE in alarm).
12.
to Step 21.
go to Step 23.

port in alarm.
rate is selected.
Step 22.
—end—

Procedure 2-77
LOP
Object Class: CTP (SONET/SDH)
Probable Cause: Loss of Pointer
NM Probable Cause: Loss of Pointer
NM Additional Text: Concatenation Mismatch, Loss of Pointer
Condition Description: LOP detected
Default Severity: Dynamic - MJ/NSA for ports with protected status, or CR/
SA for ports with unprotected status.
TL1 String: LOP
An LOP (LOP) is declared when a valid pointer is not discovered for between
8<N<10 consecutive frames or when there are N consecutive frames with
New Data Flags (NDFs) set. An LOP alarm is raised if an LOF defect condition
persists for 2.5 seconds.
The 5400 Switch reports LOP for line side SNC CTPs. The SNC CTP alarms
are critical and service affecting. All other CTPs are not reported and not
service affecting.


Step Action
alarm, and note the port that displays the LOP alarm.

4 Check the status of the PTE or LTE or MSTE connected to the port to ensure
that the payload mapping matches the SNC/XCON payload mapping.
— If the payload mapping matches, go to Step 5.
— If the payload mapping does not match, go to Step 6.
CAUTION
CAUTION
ESD procedures.
ATTENTION
5 Remove the port receive fiber and connect the fiber to a SONET test set.
Determine if a LOP is incoming.
— If the test set reports an incoming LOP, the trouble is external. Isolate
and repair the upstream fiber or connector problem before
proceeding to Step 6. Consult the next level of support if needed.
— If the test set does not report an incoming LOP, go to Step 6.
—end—

Procedure 2-78
Loss of PCS
Object Class: TETTP
Probable Cause: Loss-of-PCS-Out
NM Probable Cause: Loss-of-PCS-Out
NM Additional Text: Ethernet Loss of PCS out

unprotected status.
TL1 String: LOSS-OF-PCS-OUT
A 40GbE Ethernet client will raise the Loss of PCS-Out alarm when a 1024B/
1027B to 64B/66B trans-decoding failure is detected in the egress
Transcoding ODUk/40GbE adaptation source function.
ATTENTION
occurred.


Step Action
alarm, and note the port that displays the Loss of PCS alarm.
3 Trace the remote end of the circuit/SNC and verify that remote Ethernet port
is 40GBE and the mapping used is PCS_TRANSPARENT
4 Verify the tunnel Peer of the above TETTP which is ODU CTP has the
payload set to PCS_TRANPARENT(0x07).

5 Correcting the above condition clears the issue.

—end—

Procedure 2-79
LOS
Object Class: TTP
Probable Cause: LOS
NM Probable Cause: LOS
NM Additional Text: Loss of Signal
Condition Description: No signal detected.

provisioned, MN/NSA for ports with protected status, or CR/SA for ports with
unprotected status.
TL1 String: LOS
A Loss of Signal (LOS) alarm is declared when the LOS defect persists for 2.5
(±0.5) seconds or an LOS defect is present when the conditions for declaring
an LOF failure are also met (LOF is inhibited when LOS is declared). The LOS
alarm is cleared when the line recovers or the port is admin locked.
When a node detects LOS on an incoming signal, it generates AIS-P on the

outgoing CTPs and sends the RDI-L signal back toward the peer to indicate
that the node has detected an AIS-L or lower layer defect on the signal that
the peer originated.


Step Action
alarm, and note the port that displays the LOS alarm.


transmit 5400 Switch port, expand the Node Manager configuration
tree and select the port, click Go > Configuring > Trail TPs and
ensure that the provisioned optical rate is correct by viewing the list
frame Rate. Always lock the port before correcting and unlock when
completed.)
(Corrective action: clean the transmit SFP/XFP/CFP fiber connector,
replace the SFP/XFP/CFP, and/or correct improper Line Build Out
(LBO) if not a 5400 Switch technology.)
If the far end upstream LTE or MSTE laser and optical multiplexer test good,
go to Step 5. .
CAUTION

CAUTION
ESD procedures.
ATTENTION
5 Remove the receive fiber and insert the receive fiber into a test set capable
of reading bit errors, as well as light level.
Equipment Safety Practices, and reinsert receive fiber into the test set.
or MSTE in alarm).
— If no WDM line systems were in the upstream path, go to Step 11.
— If any WDM line systems were in the upstream path, go to Step 13.
Step 11.
— If no defective or dirty fibers or connectors was cleaned or repaired

19 From within the Node Manager application, expand the equipment tree and
select the port in alarm.
20 Click Go > Configuring > Trail TPs.
selected.
25 Replace the module then go to Step 28.
26 If required, reinsert the fiber from the test set then determine if the test set is
reporting bit errors or a light level is not within specification defined in SFP/
XFP/CFP Specifications in the 5400 Switch System Description Manual.

Step 27.
28 If required, reinsert the fiber from the test set then verify that the alarm
cleared at the Node Manager workstation.
—end—

Procedure 2-80
LSC
Object Class: TTP (CBR)
Probable Cause: LSC
NM Probable Cause: LSC
NM Additional Text: Input Clock Not Recoverable
Condition Description: Loss of Clock
Default Severity: Dynamic - Warning/NSA for ports with no cross connection

provisioned, Minor/NSA for ports with protected status, or MJ/SA for ports with
unprotected status
TL1 String: LSC
The CBR LSC alarm is raised when a dLSC defect persists for 2.5 (±0.5)
seconds.


Step Action
alarm, and note the NE that displays the LSC alarm.


go to Step 21.
— If the far end upstream LTE or MSTE laser and optical multiplexer test
good, go to Step 5.
CAUTION
CAUTION
ESD procedures.
ATTENTION
as light level.


or MSTE in alarm).
12.
to Step 21.
go to Step 23.

port in alarm.
rate is selected.
specification defined in SFP/XFP/CFP Specifications listed in the 5400
Switch System Description Manual.
Step 22.
—end—

Procedure 2-81
Maximum discovered route limit reached
Object Class: OSPFCONFIG
NM Probable Cause: Maximum Discovered Route Limit Reached
TL1 String: ROUTELIMITREACHED
This condition is raised when the size of the forwarding table reaches the
maximum number of routes as defined in the Performance Section.
The condition is cleared when the size of the forwarding table reaches 95% of
the maximum number of routes as defined in the Performance Section.


Step Action
3 Select the Maximum discovered route limit reached alarm, and note the
number of configured routes and maximum routes from the alarm additional
info text. To clear the condition, the number of configured routes need to be
less than or equal to 95% of the maximum routes.
4 Disable OSPF with some of the neighbors which have alternate path in the
network.
If a directly subtended neighbor a.b.c.d is also reachable via another
subtended neighbor x.y.z.w, then disable OSPF for the subtended neighbor
a.b.c.d.
5 Click OSPF and select the Subtended Neighbor Tab and uncheck the Ospf
enabled Checkbox.
—end—

Procedure 2-82
NDP adjacency down
Object Class: TTP
NM Probable Cause: Adjacency Down
NM Additional Text: NDP Adjacency is in a Down State
TL1 String: ADJACENCYDOWN
This condition is raised when neighbor connectivity over a TTP that is enabled
for NDP over GCC is lost. The condition is not raised if the TTP already has
an alarm, or the TTP is locked, or the PTP is locked.
The condition is cleared when neighbor connectivity over a TTP that is

enabled for NDP over GCC is restored.


Step Action
2 Click Go > Monitoring > Alarms & Events, select the Alarms tab and note
the port that displays the NDP adjacency down condition.
no equipment alarms exist. If an equipment alarm exists, discontinue this
procedure and perform the TCP for the alarmed equipment.
4 Ensure that the alarmed port e is alarm free at the OTU layer. If an OTU layer
alarm exists, discontinue this procedure and perform TCP for the OTU alarm.
5 Ensure that the OTN FEC type matches at both the endpoints.
6 Go > Configuring > Trail TPs > OTN TTPs > OTU TTPs and select the
relevant TTP.
7 Select the Basic tab and change the Admin State to locked.

8 Select the FEC type to match the remote endpoint FEC type
9 Ensure the OTU TTP is Unlocked.
– If the alarm clears, proceed to next Step 14.
– If the alarm exists, go to Step 10
10 Verify the NDP is configure correctly at both the endpoints of the link.
11 Click Go > Configuring > Trail TPs > OTN TTPs > OTU TTPs and select the
relevant TTP.
12 Select the Protocols tab and check the subtended neighbor configuration.
13 Ensure all configurations match the configurations of the remote node.
—end—

Procedure 2-83
NDP duplicate subtended neighbor condition
Object Class: MoSubtendedNeighbor
NM Probable Cause: Duplicate Subtended Neighbor
NM Additional Text: Duplicate Subtended Neighbor configured on multiple

NDP links with same discovered destinations Default, List: 1-A-1-1, 1-A-1-2
Condition Description: Duplicate Subtended Neighbor configured on

multiple NDP links with same discovered destination
TL1 String: Duplicate Subtended Neighbor
The alarm is raised when multiple SN profiles are configured for the same
remote node.


Step Action
1 Lock the admin state of NDP on the TTP .

2 Disable NDP profile on duplicate links (which are indicated by the alarm's
additional text).
—end—

Procedure 2-84
Network configuration changes inhibited
Object Class: OsrpNode
Probable Cause: Network configuration changes are inhibited
NM Probable Cause: Network configuration changes are inhibited
NM Additional Text:
Condition Description: Managed Element Network Config Changes

Inhibited condition detected
The Network Config Changes Inhibited condition is raised when the node
cannot configure the data path for new or changed cross-connections due to
an LM control plane reset and time is needed until configuration changes can
once again be made. When the node successfully configures the data path for
the previously blocked change request, the warning is cleared automatically.


Step Action
alarm, and note the LM that displays the Network configuration changes
inhibited condition.
3 Observe that the warning clears within five minutes.
—end—

Procedure 2-85
Nodes per area exceeded
Category: OSI Communication
Object Class: OSIBASIC
Probable Cause: Nodes per Area Exceeded
NM Probable Cause: Nodes per Area Exceeded
NM Additional Text: Nodes per Area Limit exceeded. Area_Prefix: <Area>

Configured: <configured value> Current: <current value>
Condition Description: OSI alarm, raised when number of nodes in an area

exceeds the limit.
TL1 String: NODESPERAREA
The alarm is raised if any one of the current count of nodes, maintained in the
mCurNodesPerArea parameter for a given area is greater than the configured
value in the mCnfNodesPerArea parameter for that area.
ATTENTION
There can be up to three areas, each of max. size 512 nodes; the Nodes per
Area Alarm is raised if any one area exceeds to the configured value in the
mCnfNodesPerArea parameter for that area.
The warning is cleared when the current counts of nodes in an area

maintained in the mCurNodesPerArea parameter is less than or equal to the
configured value in the mCnfNodesPerArea parameter, for all areas.
ATTENTION
There can be up to threeareas, each of max. size 512 nodes; an alarm is
cleared if all three areas have the number nodes per area falls below the
mCnfNodesPerArea parameter for that area.



Step Action
alarm that displays the source as OSIBASIC and probable cause as Nodes
Per Area Exceeded condition.
3 Click Go > Provisioning > OSI and select the General Settings tab and
increase the the value of Nodes in the Nodes Per Area field.
4 Verify that the alarm has cleared. If the alarm has not cleared then go to Step
5.
5 Check the value of Area Prefix of all the nodes in the network (where OSI is
enabled) to verify the number of nodes in a particular area does not exceed
the configured value.
7.
7 From the CLI Maintenance Menu, disable the OSI and reboot the Primary
CTM.
8 Verify that the alarm has cleared.
—end—

Procedure 2-86
ODU AIS
Object Class: TTP, CTP (ODUk)
Probable Cause: ODU AIS
NM Probable Cause: ODU AIS
NM Additional Text: Alarm Indication Signal
Default Severity: Dynamic - WN/NSA for ports with no cross connection

unprotected status
TL1 String: ODU-AIS
An ODU AIS alarm indicates that upstream equipment has experienced a

ODU AIS alarm in the reporting node.
When the 5400 Switch detects an ODU fault on an incoming signal or that a
trace mismatch alarm exists, the 5400 Switch generates an AIS on the
outgoing CTPs. When ODU AIS is detected on a TTP, a BDI signal is sent
back toward the peer to indicate that the 5400 Switch has detected an ODU
AIS or lower layer defect on the signal that the peer originated.


Step Action
alarm, and note the port that displays the ODU AIS alarm.


CAUTION
— The following steps are performed at the 5400 Switch.

set.
— If test set reports incoming ODU AIS or any other line signal defect,
the section trouble is external. The source of the upstream AIS must
be manually isolated.
ATTENTION
If a signal defect is isolated to the upstream node, check the upstream node
— If the test set does not report incoming AIS or any other line signal
5 Reconnect fiber, reinstall OM, SFP/XFP/CFP, and recheck alarm status.
6 Replace the OM, SFP/XFP/CFP.
7 Verify that alarm cleared.
—end—

Procedure 2-87
ODU BDI
Probable Cause: ODU BDI
NM Probable Cause: ODU BDI
NM Additional Text: Backward Defect Indication

unprotected status
TL1 String: ODU-BDI
An ODU BDI is a maintenance signal used to alert upstream equipment that

a defect (for example, LOS or LOF) has been detected. This signal informs an
upstream node that the downstream node detected an AIS that the upstream
node originated. Resolving the fault in the adjoining node clears the ODU BDI
alarm in the reporting node. An ODU BDI defect is propagated within 125
microseconds of detecting the defect.


Step Action
ODU BDI alarm, and note any additional port alarm information.
(SNC) alarms.

— If an alarm exists, discontinue this procedure and perform the

Unavailable (SNC) alarm TCP.
incoming drop or the outgoing drop and perform the associated
upstream or downstream TCP.
4 Check the far end laser in accordance with upstream technology guidelines
for this line to identify the node that may be generating this alarm.
—end—

Procedure 2-88
ODU DEG
Probable Cause: ODU DEG
NM Probable Cause: ODU DEG
NM Additional Text: Degrade, Exceeded the Percent of Errored Blocks

errored blocks in the in Consecutive Seconds.
Default Severity: Dynamic - MN/NSA for services with no cross-connection

provisioned, MN/NSA for services with protected status, or MJ/SA for services
with unprotected status
TL1 String: ODU-DEG
An ODU DEG alarm is raised when the number of errored blocks per second
exceeds the provisioned threshold.


Step Action
alarm, and note the port that displays the ODU DEG alarm.


be correct. (Corrective action: replace port or equivalent with
or equivalent.)
Manual. (Corrective action: clean the transmit port or equivalent
fiber connector, replace the port or equivalent, and/or correct
improper LBO if not a 5400 Switch technology.)
go to Step 25.
CAUTION
CAUTION
ESD procedures.

ATTENTION
(between the transmit node checked in Step 4 and the receive node in alarm).
12.
11 The output of the far end upstream node was previously tested in Step 4. The
low light level and resulting bit errors must be the result of a dirty or defective
fiber or connector between (but not including) the transmit node and the
receive 5400 Switch node. Isolate and clean/repair the fiber or connector
to Step 22.
go to Step 24.
the upstream transmit node and the receive 5400 Switch node in alarm in
accordance with internal guidelines. In addition to checking for higher rate
WDM system alarms and PM data, this isolation should include checking any
fibers and connectors on the input to the first WDM system and fibers and
connectors between multiple WDM systems, as well as output lasers from
one WDM system to another.


port in alarm.
18 View the Service Type box and ensure that the correct optical rate is
selected.
19 Reconnect the receive fiber and if applicable, reinstall the SFP in accordance
with the 5400 Switch Service Manual.
— If the alarm cleared, end this procedure. If the alarm did not clear, go
to Step 21.
21 Replace the module, then go to Step 24.
23 Reconnect the receive fiber and, if applicable, reinstall the SFP in accordance
—end—

Procedure 2-89
ODU LCK
Probable Cause: ODU LCK
NM Probable Cause: ODU LCK
NM Additional Text: Lock
Default Severity: Dynamic - WN/NSA for services with no provisioned cross-

connect, MN/NSA for services with protected status, or MJ/SA for services
TL1 String: ODU-LCK
An ODU LCK alarm is raised when the upstream TTP is administratively

locked. This signal informs an upstream node that the downstream node
detected an AIS that the upstream node originated.


Step Action
alarm, and note the module that displays the ODU LCK alarm.
3 Expand the equipment tree in the upstream node, until the alarmed unit is
displayed and note the shelf and slot designation.
5 Select Unlocked from the Admin State drop-down menu and click Accept.
6 Verify the Admin State in the Status field indicates Unlocked. Click Accept.
—end—

Procedure 2-90
ODU LOF
Probable Cause: ODU LOF
NM Probable Cause: ODU LOF
NM Additional Text: Loss of Frame, LOFLOM

unprotected status
TL1 String: LOF
An ODU LOF is raised when an ODU signal experiences loss of frame and
multiframe.
ATTENTION
occurred.


Step Action
alarm, and note the port that displays the ODU LOF alarm.

4 Check the far end upstream node laser and optical line multiplexer in
interior 5400 Switch/CoreDirector Switch network, the upstream node is
another 5400 Switch/CoreDirector Switch. If the line in alarm is a network
drop, the upstream technology is typically an Aggregator/MUX. The far end
upstream node laser should be checked for the following:
– OM and LM (or equivalent if other technology) equipment failures
action: replace SFP/XFP/CFP, LM, or equivalent.)
be correct. (Corrective action: replace SFP/XFP/CFP with correct
rate, wavelength, and reach. To check/correct provisioned rate of
a transmit 5400 Switch/CoreDirector Switch port, select the port,
expand the Node Manager configuration tree, click Go >
Configuring and select the Physical TP tab, then ensure that the
port.)
LBO if not a 5400 Switch/CoreDirector Switch technology.)
— If the far end upstream node laser or optical multiplexer tests bad,
repair in accordance with upstream technology guidelines, then go to
Step 21.
— If the far end upstream node laser and optical multiplexer test good,
go to Step 5.
CAUTION

CAUTION
ESD procedures.
ATTENTION
5 Remove the receive fiber in accordance with Removing and Installing an

SFP/XFP/CFP in the 5400 Switch Service Manual. Insert the receive fiber
into a test set capable of reading bit errors, as well as light level.
(between the transmit node checked in Step 4 and the Receive node in
alarm).
12.
receive 5400 Switch/CoreDirector Switch. Isolate and clean/repair the fiber or
connector trouble in accordance with internal guidelines.
to Step 21.
go to Step 23.

alarmed 5400 Switch/CoreDirector Switch OM or port in alarm. Correct any
problems that are found.
the upstream transmit node and the receive 5400 Switch/CoreDirector Switch
node in alarm in accordance with internal guidelines. In addition to checking
14 Clean the OM or port fiber connector in accordance with Ciena Standard
Cleaning & Equipment Safety Practices.
15 Check that the installed receive OM or port is the correct type (rate,
wavelength, and reach) by verifying the part number.
OM or port in alarm.
17 Click Go > Configuring and select the Physical TP tab, then ensure that the
provisioned optical rate is correct by viewing the Configured Rate box to
ensure that the correct optical rate is selected.
18 Reconnect the receive fiber and if applicable, reinstall the OM in accordance
with Removing and Installing an SFP/XFP/CFP in the 5400 Switch Service
Manual.
Step 22.


with Removing and Installing an SFP/XFP/CFP listed in the 5400 Switch
Service Manual.
—end—

Procedure 2-91
ODU OCI
Probable Cause: ODU OCI
NM Probable Cause: ODU OCI
NM Additional Text: Open Connection Indication

TL1 String: ODU-OCI
An ODU OCI alarm is raised when an upstream ODU timeslot is unequipped

because a cross-connect or TTP is not provisioned. This signal informs an
node originated.


Step Action
alarm, and note the module that displays the ODU OCI alarm.
4 Click Go > Provisioning > Cross connect.
5 Verify that the cross connect is provisioned.
— If the cross connect is not provisioned then go to Step 6.
— If the cross connect is provisioned then create cross connect.

6 From the cross connect screen select the New tab and provision the cross-
connect.
—end—

Procedure 2-92
ODU PLM
Object Class: TTP, PT-CTP (ODUk)
Probable Cause: ODU PLM
NM Probable Cause: ODU PLM
NM Additional Text: Payload Label Mismatch, Expected PT Code

<Provisioned PT>, Actual PT Code <Received PT>
TL1 String: ODU-PLM
An ODU PLM alarm is raised when one of the following conditions exists:
• Ports are incorrectly connected

• Cross-connects are incorrectly created
• Expected payload type provisioned on the ODU TTP does not match the
received payload type

ATTENTION
Maintenance procedures are located in the 5400 Switch Service Manual.
Step Action
alarm, and note the module that displays the ODU PLM alarm.
3 Verify the payload type is correct.
4 Click Go > Configuring > Trail TPs > OTN TTPs > ODU TTPs and select the
Basic tab.

5 Verify the Ex. Payload Type and Rx. Payload Type in the detail frame.
6 Check the connectivity to the upstream TTP and the client interface.
ATTENTION
ODU TTI message can be used to verify connectivity.

—end—

Procedure 2-93
ODU TIM
Object Class: TTP, PT-CTP (ODUk)
Probable Cause: ODU TIM
NM Probable Cause: ODU TIM
NM Additional Text: Trail Trace Identifier Mismatch, Received SAPI:

<rcvd_sapi>. Expected SAPI: <expt_sapi>, Received DAPI: <rcvd_dapi>.
Expected DAPI: <expt_dapi>
TL1 String: ODU-TIM
An ODU TIM is a connectivity defect caused by provisioning problems within

the network. The 64-byte SM TTI string which includes the Source Access
Point Identifier (SAPI) field and Destination Access Point Identifier (DAPI) field
as specified in ITU-Y G.709, is compared to an expected identifier, and
persistent mismatches are reported.
An ODU-TIM alarm is raised when an ODU layer dTIM Mismatch defect

persists for 2.5 (±0.5) seconds.


Step Action
alarm, and note the port that displays the ODU TIM alarm.
3 Verify that the node received trace string value matches the expected value
in the TTP section trace screen.
4 Correction of the condition from Step 3 clears the alarm. If a condition did not
exist, the alarm clears within 30 seconds.


— If the alarm clears, end this procedure.
—end—

Procedure 2-94
Operation out of spec
Category: Equipment
Object Class: PTP
Probable Cause: Operation Out of Spec
NM Probable Cause: Transmitter Operation Out of Spec
NM Additional Text:
TL1 String: OUTOFSPEC
The warning is raised when a coherent optical interface detects the operating
reach and/or PMD is above the supported reach and/or PMD.


Step Action
alarm, and note the port that displays the Operation out of spec alarm.
3 Change the fiber or the environment the fiber is located.
—end—

Procedure 2-95
OPU CSF
Object Class: ODU CTP
Probable Cause: OPU CSF
NM Probable Cause: OPU CSF
NM Additional Text: Client Signal Fail
TL1 String: OPU-CSF
An OPU k CSF alarm is raised when the remote end client TETTP/CBR TTP/
TransSTTP has a client signal failure it sends the OPU CSF towards the near
end.


Step Action
alarm, and note the port that displays the OPU CSF warning.
3 Trace the remote end of the circuit/SNC and go to the ODU CTP menu.
4 On the ODU CTP tab, click on TunnelPeer field. Node Manager should now
display the corresponding TETTP/CBR TTP/TransSTTP.
5 Verify the object is alarm free by clicking Go > Monitoring > Alarms &
Events Tab
6 Clearing any existing alarm on above object will clear the OPU CSF at the
near end.
7 If there are no alarms seen in Step 5, check if the TETTP/CBR TTP/Trans
STTP displays the Availability Status as DEPENDENCY. Clearing the
dependency condition will clear the near end OPU CSF alarm. TETTP/CBR

TTP/Tran STTP will go into dependency availability status when PTP is

locked or there are equipment related failures on SFP/XFP/CFP or circuit
pack.
—end—

Procedure 2-96
OPU MSI mismatch
Object Class: TTP (ODUk), CTP (ODUj)
Probable Cause: OPU MSI Mismatch
NM Probable Cause: OPU MSI Mismatch
NM Additional Text: Server Layer MSIM Mismatch
TL1 String: OPU-MSIM
An OPU-MSIM alarm is raised when an OPU layer MSIM defect persists for
2.5 (±0.5) seconds and clears when the defect is absent for 10 (±0.5)
seconds.


Step Action
alarm, and note the port that displays the OPU MSI mismatch alarm.
3 Check the far end upstream ODU TTP timeslots configured is similar to the
timeslots configured in the node raising the alarm.
4 Ensure both nodes have identical timeslots configured.
—end—

Procedure 2-97
OPR out of range
Object Class: PTP
Probable Cause: OPR Out of Range
NM Probable Cause: OPR Out of Range
NM Additional Text: OPR Out of Range <High or Low>
TL1 String: OPROOR
The warning is raised when the Rx power is outside the minimum and
maximum receive optical power range.
The warning is cleared when the Rx power is within the minimum and
maximum receive optical power range.


Step Action
alarm, and note the port that displays the OPR out of range alarm.
3 Locate the receive port that is in alarm and use an attenuator to lower the
power.
—end—

Procedure 2-98
Optical trace mismatch
Object Class: PTP
Probable Cause: Optical Trace Mismatch
NM Probable Cause:
NM Additional Text: Transmit/Receive Optical Echo Trace Mismatch
TL1 String: TIM
The warning is raised when the TR control receives a TxID from the far-end
receiver that does not match its own TxID. This indicates a crossed fiber.
The warning is cleared when the TR control receives a TxID from the far-end
receiver that matches its own TxID, or when TR control receives no TxID from
the far-end receiver.


Step Action
alarm, and note the port that displays the Optical trace mismatch alarm.
3 Verify that the transmit and receive fibers are connected to the appropriate
ports.
—end—

Procedure 2-99
OSI communications failure
Object Class: TtpProtocols
Probable Cause: OSI communications failure
NM Probable Cause: OSI communications failure
NM Additional Text: ISIS Adjacency is down. Communications Failure
Condition Description: IS-IS adjacency down
TL1 String: OSIFAIL
The alarm is raised when the OSI link between two nodes (OSI is enabled on
both nodes) is down.
The alarm is cleared when the OSI link between two nodes are restored..


Step Action
alarm that displays the OSI Communication failure condition .
3 Verify TTP operation state is normal by unlocking the PTP and TTP on both
the nodes and verifying correct fiber connectivity between them.
5.
5 Configure the correct LAPD parameters on the TTP of both nodes.
7.
CTM.


—end—

Procedure 2-100
OSPF adjacency down
Category: COMMUNICATION
Object Class:
NM Probable Cause: Adjacency Down
NM Additional Text: OSPF Adjacency is in a Down State
Condition Description: This alarm is raised when the OSPF adjacency on

the link between two nodes is not in FULL state.
TL1 String: ADJACENCYDOWN
This condition is raised when a neighbor that is enabled for OSPF is lost. The
condition is not raised if the TTP already has an alarm, or the TTP or PTP is
locked.
The condition is cleared when neighbor connectivity that is enabled for OSPF
is restored.


Step Action
alarm, and note the port that displays the OSPF adjacency down warning.
3 Select Go > Provisioning > OSRP > OSRP Lines and select appropriate
port identified in Step 2. Note the neighbor node name, supporting TP,
neighbor containing link ID.
4 Re-provision the OSPF link by referring to the 5400 Switch Node manager
User Guide.
—end—

Procedure 2-101
OSRP advertised bandwidth mismatch condition
Object Class: MoOsrpLtp
Probable Cause: OSRP LTP Misconfigured Bandwidth Limitation
NM Probable Cause: OSRP LTP Misconfigured Bandwidth Limitation
NM Additional Text: AdvertismentLimit=, RemoteAdvertismentLimit=
Condition Description: Advertised LTP bandwidth limits mismatch between

local and remote nodes detected
TL1 String: OSRPLTPBWMM
An Advertised Bandwidth Mismatch condition is raised on an OSRP link when

advertised bandwidth limits provisioned on a local link end-point do not match
the advertised bandwidth limits on a remote link end-point. Advertised
bandwidth limits include the following parameters: Concatenation (OOB only)
and Min_Connection Size (OTN only).


Step Action
alarm, and note the port that displays the OSRP advertised bandwidth
mismatch condition warning.
4 Select Go > Provisioning > OSRP > OSRP Links.
5 In the list frame, select Local Links and then in the details frame, select Link.
6 Note the Advertised BW Limit.

7 Launch node manager on the remote node identified in Step 3.

10 Note the Advertised BW Limit.
11 verify that the Advertised BW Limit are consistent at both the local and
remote nodes.
12 Click Accept.
—end—

Procedure 2-102
OSRP concatenation mismatch condition
Object Class: MoOsrpCtp
Probable Cause: OSRP CTP Misconfigured Concatenation
NM Probable Cause: OSRP CTP Misconfigured Concatenation
NM Additional Text: Concatenation misconfiguration

StandardConcat:<stdConcat>Remote
StandardConcat:<remoteStdConcat>TransparentConcat:<transpConcat>Re
mote TransparentConcat:<remoteTranspConcat>
Condition Description: Configuration Mismatch due to concatenation type

mismatch between two OSRP lines.
TL1 String:
This alarm is generated due to concatenation mismatch between local and

remote lines, when an OSRP line is configured as standard concatenation at
one node and transparent concatenation at the other node.


Step Action
alarm, and note the port that displays the OSRP concatenation mismatch
condition alarm. The alarm will contain the local and remote nodes and
associated ports.
3 Click Go > Configuring > Trail TPs > SONET/SDH TTPs, select the Basic
tab, and note concatenation status.
4 Launch Node Manager and establish a session with the remote node.
5 Click Go > Configuring > Trail TPs > SONET/SDH TTPs, select the Basic
tab, and note concatenation status.

— If transparent concatenation and flexible concatenation parameters

are consistent at both nodes then go to Step 7.
6 Adjust concatenation as required at the remote or local node.
—end—

Procedure 2-103
OSRP CTP bandwidth locked
Object Class: OsrpCtp
Probable Cause: OSRP CTP Bandwidth Locked
NM Probable Cause: Bandwidth locked for this OSRP CTP
NM Additional Text: Bandwidth locked for this OSRP CTP
Condition Description: Bandwidth locked for this OSRP CTP
TL1 String: OSRPCTPBWLCK


Step Action
2 Click Go > Monitoring > Alarms & Events, select the Alarms tab, and select
the alarm and note the port that displays OSRP CTP bandwidth locked
alarm.
3 Click Go > Provisioning > OSRP Lines and note the Bandwidth Lockout
is checked in the detail field.
4 Click Accept.
—end—

Procedure 2-104
OSRP CTP misconfigured bandwidth lockout
Probable Cause: OSRP CTP Misconfigured Bandwidth Lockout
NM Probable Cause: OSRP CTP Misconfigured Bandwidth Lockout
NM Additional Text: Bandwidth State Misconfiguration - Bandwidth:

LOCKED Remote Bandwidth: UNLOCKED
Condition Description: Bandwidth State Misconfiguration - Bandwidth:

LOCKED Remote Bandwidth: UNLOCKED
TL1 String: OSRPCTPMISCBWLCK


Step Action
the alarm and note the port that displays OSRP CTP misconfigured
bandwidth lockout alarm.
check boxes in the detail field.
6 Verify that both check boxes are consistent at both nodes.
7 Click Accept.
—end—

Procedure 2-105
OSRP link ID mismatch condition
Object Class: TTP
Probable Cause: OSRP LTP Misconfigured Link ID
NM Probable Cause: OSRP LTP Misconfigured Link ID
NM Additional Text: OSRP aggregate connected to multiple far-end

aggregates.
Condition Description: Configuration Mismatch due to link ID
Default Severity: Critical, Non service affecting
TL1 String: OSRPLTPMISCONFIGURED
This alarm is generated due to Link ID Mismatch mismatch between local and
remote links.


Step Action
alarm, and note the port that displays the OSRP link ID mismatch condition
alarm.
6 Compare the Link ID values in both the local and remote nodes and ensure
both are the same. Adjust if necessary.

—end—

Procedure 2-106
OSRP LTP misconfigured bandwidth mismatch
Probable Cause: OSRP LTP Misconfigured Bandwidth Limitation
NM Probable Cause: OSRP LTP Misconfigured Bandwidth Limitation
NM Additional Text: "LocalAdvertisementLimit=<local>,

RemoteAdvertisementLimit=<remote>")
TL1 String: OSRPLTPBWMM


Step Action
the alarm and note the port that displays OSRP LTP misconfigured
bandwidth mismatch alarm.
6 Verify that both check boxes are consistent at both nodes.
7 Click Accept.
—end—

Procedure 2-107
OSRP LTP misconfigured bandwidth threshold limit
reached condition
Object Class: OsrpLtp
Probable Cause: OSRP LTP Misconfigured BW Thresholds
NM Probable Cause: OSRP LTP Misconfigured BW Thresholds
NM Additional Text: Bandwidth threshold misconfiguration, local : <local>,

remote :;
Default Severity: : Warning, Non service affecting
TL1 String: CONFIGMISMATCH


the port that displays the OSRP LTP misconfigured bandwidth threshold
limit reached condition alarm.
3 Click Go > Provisioning > OSRP Links and select the Local Links tab.
4 From the list of local links, select the CTP in alarm and note the Bandwidth
Thresholds values in the detail frame.
7 From the list of local links, select the CTP in alarm and note the Bandwidth
Thresholds values in the detail frame.
8 Verify that the Bandwidth Thresholds values are consistent at both nodes.
9 Click Accept.
—end—

Procedure 2-108
OSRP LTP oversubscribed
Object Class: MoLtp
NM Probable Cause: OSRP LTP Oversubscribed
NM Additional Text: Bandwidth Oversubscription
Default Severity: : Warning, Non service affecting
TL1 String: LTPOverSub
OSRP LTP Oversubscribed condition is raised if:
• Normal Priority Bandwidth on a Link is reduced below zero.

• a SNC Preempts Reserved Home Path Bandwidth on a Link during
restoration.
The OSRP LTP Oversubscribed condition is cleared when:
• the Normal Priority Bandwidth on a Link returns to zero or greater than

zero.
• when the Preempting SNC is removed from the Link.
• if the OSRP Link is deleted.

Step Action
the port that displays the OSRP LTP oversubscribed alarm.
4 Locate the SNCs which are using the RHP Priority, but are not in RHP Active
condition and note their originating node.
5 Launch Node Manager and establish a session with that node.

7 Locate the alarmed SNCs and move them to either their home path or new
path to clear the BW on the existing link.
8 Click Accept.
—end—

Procedure 2-109
OSRP misconfigured admin state condition
Probable Cause: OSRP CTP Misconfigured Admin State
NM Probable Cause: OSRP CTP Misconfigured Admin State
NM Additional Text: Admin State Misconfiguration AdmSt:<UNLOCKED/

LOCKED> Remote AdmSt:<LOCKED/UNLOCKED>
Condition Description: Configuration Mismatch due to admin state

mismatch between adjacent OSRP lines.
TL1 String: OSRPCTPADMINSTATE
An Admin State Mismatch condition is raised on an OSRP line when the near
end and far end admin states are different and clears when admin states of
near end and far end OSRP lines are the same.


Step Action
alarm, and note the port that displays the OSRP misconfigured admin state
condition alarm. The alarm will contain the local and remote nodes and
associated ports.
3 Compare the admin states in both the local and remote nodes to confirm
consistency.
4 Click Go > Configuring > Physical TPs, select the Basic tab, to verify admin
status.
— Set the Admin state at both nodes to be unlocked .


—end—

Procedure 2-110
OSRP misconfigured CID condition
Probable Cause: OSRP CTP Misconfigured CID
NM Probable Cause: OSRP CTP Misconfigured CID
NM Additional Text: Common Id Misconfiguration CID:<localVal>

RemoteCID:<remoteVal>
Condition Description: Local and remote node OSRP Link Termination

Points mismatch detected.
TL1 String: OSRPCTPMISCONFIGUREDCID
An OSRP Misconfigured CID occurs before NOC personnel have identified

the remote OSRP Line Termination Point (OLTP) or the identification is in
error. This warning appears on the local and remote node elements and each
node displays the condition on both ends. It will clear itself when both ends of
the OLTP match.


Step Action
alarm, and note the port that displays the OSRP misconfigured CID
condition alarm
port identified in Step 2.
4 In the details frame, compare the local and neighbor Common Line ID.
5 Of the two, select the one that does not conform to the network design.
— If both CIDs conform to the network design, the design itself may be
in error.

6 On the node with the non-conforming at the Go > Provisioning > OSRP
Lines and from the OSRP Lines screen, select the OCTP with the
misconfigured CID from the List Frame.
7 Change Admin State to Unlocked and click Accept.
8 Change Common Line ID to correct value (valid range 1-65534) and click
Accept.
9 Change Admin State to Unlocked and click Accept.
—end—

Procedure 2-111
OSRP misconfigured condition
Probable Cause: OSRP LTP Misconfigured
NM Probable Cause: OSRP LTP Misconfigured
NM Additional Text: Based on underlying cause:
• Bundle ID Mismatch
• Admin Weight Mismatch
• Link ID Mismatch
• Manually configured Link Delay Mismatch
Condition Description: Configuration Mismatch due to either admin weight
or bundleId between adjacent OSRP links.
TL1 String:
This alarm is generated due to Bundle ID Mismatch, Admin Weight Mismatch,

or Link ID Mismatch mismatch between local and remote links. It is also
generated due to manually configured Link Delay Mismatch.


Step Action
alarm, and note the port that displays the OSRP misconfigured condition
alarm.


6 Compare the Bundle ID, Admin Weight, and Link ID values in both the local
and remote nodes and ensure both are the same. Adjust if necessary.
—end—

Procedure 2-112
OSRP misconfigured node name condition
Probable Cause: OSRP LTP Misconfigured Node Name
NM Probable Cause: OSRP LTP Misconfigured Node Name
NM Additional Text: OSRP aggregate connected to multiple far-end NEs.
Condition Description: Configuration Mismatch due to mismatch in

aggregated Osrp line nodeIds between adjacent OSRP links
TL1 String: OOSRPLTPMISCONFIGNODE
The OSRP Misconfigured Node Name alarm is generated when the

containing OLTP of the OCTP contains OCTPs connected to different remote
nodes. The remote OLTP(s) will not generate the alarm in this case.


Step Action
alarm, and note the port that displays the OSRP misconfigured node name
condition alarm.
3 Compare the LTPs and CTPs to the network design. Note both the Nodes and
LTP that the CTP should be associated with.
4 Expand the Equipment tree and select the appropriate port.
5 At Go > Configuring > Physical TPs and select the Basic tab, change the
Admin State to Locked to disable the laser.
6 Click Accept.
7 At Go > OSRP > OSRP Links and click appropriate LTP from List Frame,
click Add/Remove Lines.

8 At appropriate CTP from the Included Table and click Remove, click Apply.
9 Click Accept.
CAUTION
ESD procedures.
10 Remove fiber from the current node and attach to correct node.
11 Expand the equipment tree and select appropriate port.
12 At Go > Configuring > Physical TPs and select the Basic tab, change
Admin State to Unlocked to enable laser.
13 Click Accept.
14 Repeat Step 11 through Step 13 for the other node.
16 From Go > Provisioning > OSRP > OSRP Links, select the appropriate LTP
from the list frame and click Add/Remove Lines.
17 Select the appropriate CTP from the Available Table and click Add.
18 Click Apply.
19 Click Accept.
—end—

Procedure 2-113
OSRP OVPN ID mismatch conditions
Object Class: LTP
Probable Cause: OSRP LTP Misconfigured OVPN ID
NM Probable Cause:
NM Additional Text: OSRP Link OVPN ID Mismatch
Condition Description: Configuration Mismatch due to OVPN ID
TL1 String: OSRPLTPMISCONFIGURED
An OSRP OVPN ID Mismatch condition is generated on a Link when the two

ends of a Link are configured with different OVPN ID's


Step Action
the port that displays the OSRP OVPN ID mismatch conditions warning.
3 Click Go > Provisioning > OSRP> OSRP Links, select the Local Links tab.
4 From the Local Links list, select the link in alarm.
5 In the Detail frame, note the OVPN ID in the Originating End Point and
Terminating End Point sections.
6 Verify that the OVPN ID values are not configured the same.
7 Click Accept.
—end—

Procedure 2-114
OSRP port capability mismatch
Probable Cause: OSRP Port Capability Mismatch
NM Probable Cause: OSRP Port Capability Mismatch
NM Additional Text: The capabilities of the near-end and far-end OSRP Line
ports are not compatible.
Condition Description: Configuration Mismatch due to port capability

mismatch between two ends of an OSRP line.
Default Severity: Warning. Non service affecting
TL1 String:
An Port Capability Mismatch alarm is generated when there is a Payload type

incompatibility between two ends of an OSRP line.


Step Action
the port that displays the OSRP port capability mismatch alarm.
3 Click Go > Configuring > Trail TPs > OTN TTPs > ODU TTPs.
4 Select the TTP in alarm and click the Basic tab.
5 In the detail frame verify the Payload Type.
6 Verify both ends of the OSRP line payloads are consistent.
7 Click Accept.
—end—

Procedure 2-115
OSRP remote unreachable condition
Probable Cause: OSRP CTP No Communication
NM Probable Cause: OSRP CTP No Communication
NM Additional Text: Communications Lost to Remote OSRP Node
Condition Description: OSRP CTP No Communication from Remote Node

and MiniHello time out occurred.
TL1 String: OSRPREMOTEUNREACHABL
The OSRP Remote Unreachable alarm occurs when the OSRP LTP link
between two 5400 Switch/CoreDirector Switches becomes unusable or when
OSRP is enabled on the near end of a link but not the far end. All other alarms,
warnings, alerts, and warnings associated with the CTPs on the aggregated
link will be cleared automatically before asserting this alarm. This alarm can
also be caused if a manually created far end OSRP CTP is deleted or if the far
end LM or CTM is rebooting. If the far end LM or CTM is rebooting, the alarm
clears within five minutes.


ATTENTION
If alarm is in response to removing a fiber loopback after testing, lock the
OSRP Line (Go > Provisioning > OSRP > OSRP Lines, select the line, and
set Admin State to Locked), delete the OSRP line (Go > Provisioning >
OSRP > OSRP Lines, select the line, and click Delete), and delete the
OSRP link (Go > Provisioning > OSRP > OSRP Link, select the link, and
click Delete).
Step Action

alarm, and note the port that displays the OSRP remote unreachable
condition alarm.
ATTENTION
If the information is not available or unknown, then the remote node
information must be determined before proceeding. Refer to the network
topology information and obtain the information before proceeding to Step 4.
4 If remote node OSRP CTP was deleted or not created, launch node manager
on the remote node identified in Step 3 and recreate the OSRP CTP then go
to Step 10.
5 Select Go > Configuring > Physical TPs > DCC and verify port DCC setting
identified in Step 3.
6 Launch node manager on the remote node identified in Step 3.
7 Expand the equipment tree and highlight the port identified in Step 3 as the
neighbor supporting TP.
8 Verify settings against settings noted in Step 5. Both sides need to be the
same for the alarm to clear.
— If the ports are not configured correctly, change appropriate side to
the correct setting then go to Step 10.
9 Verify that LM is in a reboot state.
— If LM is in reboot state, wait five minutes for the LM to complete boot
cycle.
10 Verify that the alarm cleared on the local node.
— If alarm cleared, end this procedure.
—end—

Procedure 2-116
OTU AIS
Object Class: TTP (OTUk)
Probable Cause: OTU AIS
NM Probable Cause: OTU AIS
Default Severity: Dynamic - WN/NSA for ports with no cross-connection

unprotected status
TL1 String: OTU-AIS
An OTU AIS alarm is raised when a generic AIS signal is received on an OTU
TTP.


Step Action
alarm, and note the OM or port that displays the OTU AIS alarm.
3 Expand the 5400 Switch equipment tree until the alarmed OM or port is
displayed and verify that no equipment alarms exist.

CAUTION
— The following steps are performed at the 5400 Switch.
4 Remove the incoming fiber to the OM or port and connect the fiber to an
optical test set.
— If test set reports incoming OTU AIS or any other line signal defect,
ATTENTION
5 Reconnect fiber, reinstall OM, SFP/XFP/CFP, and recheck alarm status.
6 Replace the OM, SFP/XFP/CFP.
—end—

Procedure 2-117
OTU BDI
Probable Cause: OTU BDI
NM Probable Cause: OTU BDI

unprotected status
TL1 String: OTU-BDI
An OTU BDI alarm is a maintenance signal used to alert upstream equipment

that a defect (for example, LOS or LOF) has been detected. This signal
informs an upstream node that the downstream node detected an AIS that the
upstream node originated. Resolving the fault in the adjoining node clears the
OTU BDI alarm in the reporting node.


Step Action
OTU BDI alarm, and note any additional OM or port alarm information.
(SNC) alarms.
Unavailable (SNC) alarm trouble clearing procedure.


upstream or downstream trouble clearing procedure.
—end—

Procedure 2-118
OTU DEG
Probable Cause: OTU DEG
NM Probable Cause: OTU DEG
NM Additional Text: Degrade, Exceeded <Percent of Errored Blocks>%

errored blocks in
<DEGM = 2-10> seconds
Condition Description: Degrade, Exceeded the Percent of Errored Blocks

errored blocks in the in Consecutive Seconds.
Default Severity: Dynamic - WN/NSA for services with no cross-connection

TL1 String: OTU-DEG
An OTU DEG alarm is raised when the number of errored blocks per second
exceeds the provisioned threshold.


Step Action
alarm, and note the OM or port that displays the OTU DEG alarm.
3 Expand the equipment tree until alarmed OM or port is displayed and verify

action: replace the OM, LM, or equivalent.)
be correct. (Corrective action: replace OM or equivalent with
rate of a transmit 5400 Switch/CoreDirector Switch OM or port,
expand the Node Manager configuration tree and select the OM or
port, click Go > Configuring > Ptp and select the Basic tab, then
– The laser should not be locked. (Corrective action: unlock the OM
or port.)
XFP/CFP Specifications listed in the 5400 Switch System
Description Manual. (Corrective action: clean the transmit OM or
port fiber connector, replace the OM or equivalent, and/or correct
improper LBO if not a 5400 Switch/CoreDirector Switch
technology.).
Step 22.
— If the far end upstream node laser and optical multiplexer tests good,
go to Step 5.
CAUTION

CAUTION
ESD procedures.
ATTENTION
5 Remove the OM or port receive fiber in accordance with Removing and

Installing an SFP/XFP/CFPlisted in the 5400 Switch Service Manual. Insert
the receive fiber into a test set capable of reading bit errors, as well as light
level.
9 Verify that the received light level is within specification defined in SFP/XFP/
12.
to Step 22.
go to Step 24.

14 Clean the OM or port fiber connector in accordance with the procedures listed
in the 5400 Switch Service Manual.
17 Click Go > Inventory and select the Physical TP tab.
selected.
19 Reconnect the receive fiber and, if applicable, reinstall the OM in accordance
with the procedures listed in the 5400 Switch Service Manual.
23 Reconnect the receive fiber in accordance with Removing and Installing an
SFP/XFP/CFP procedures listed in the 5400 Switch Service Manual. If
applicable, reinstall the OM or SFP.


—end—

Procedure 2-119
OTU LOF
Probable Cause: OTU LOF
NM Probable Cause: OTU LOF
NM Additional Text: Loss of Frame

unprotected status
TL1 String: LOF


Step Action
alarm, and note the port that displays the OTU LOF alarm.


equivalent.)
a transmit 5400 Switch port, select the port, expand the Node
Manager configuration tree, click Go > Inventory and select the
Basic tab, then ensure that the provisioned optical rate is correct.
completed.)
port.)
Step 21.
go to Step 5.
CAUTION
CAUTION
ESD procedures.
ATTENTION

5 Check if the service type of end upstream LTE or MSTE laser or optical
multiplexer is set to OTUk (k=1,2,3).
— If service type indicates OTUk (where k matches with the port
configuration of receive 5400 switch in alarm) go to next step. If not
correct the service type in accordance with procedures listed in the
5400 Switch Service Manual, go to Step 24.
6 Remove the receive fiber in accordance with procedures listed in the 5400
Switch Service Manual. Insert the receive fiber into a test set capable of
reading bit errors, as well as light level.
alarm).
13.
receive 5400 Switch. Isolate and clean/repair the fiber or connector trouble in
to Step 22.
go to Step 24.


18 Click Go > Configuring and select the Trail TPs tab, then ensure that the
provisioned optical rate is correct by viewing the List Frame Rate to ensure
that the correct optical rate is selected.
accordance with procedures listed in the 5400 Switch Service Manual.
Step 23.
— If the alarm cleared, end this procedure
—end—

Procedure 2-120
OTU LOL
Probable Cause: OTU LOL
NM Probable Cause: OTU LOL
NM Additional Text: Loss of Lane Alignment

unprotected status
TL1 String: LOL
The Loss of Lane Alignment failure is raised if the loss of lock defect persists
for 2.5 (± 0.5 seconds and clears when the loss of lock defect is absent for 10
(± 0.5) seconds.


Step Action
alarm, and note the port that displays the OTU LOL alarm.

another 5400 Switch. If the line in alarm is a network drop, the upstream
technology is typically an Aggregator/MUX. The far end upstream node laser
equivalent.)
a transmit 5400 Switch port, select the port, expand the Node
Manager configuration tree, click Go > Inventory and select the
Basic tab, then ensure that the provisioned optical rate is correct.
completed.)
port.)
Step 21.
go to Step 5.
CAUTION
CAUTION
ESD procedures.

ATTENTION
5 Check if the service type of end upstream LTE or MSTE laser or optical
multiplexer is set to OTUk (k=1,2,3).
— If service type indicates OTUk (where k matches with the port
configuration of receive 5400 Switch in alarm) go to next step. If not
correct the service type in accordance with procedures listed in the
5400 Switch Service Manual, go to Step 24.
6 Remove the receive fiber in accordance with procedures listed in the 5400
Switch Service Manual. Insert the receive fiber into a test set capable of
reading bit errors, as well as light level.
alarm).
13.
receive 5400 Switch. Isolate and clean/repair the fiber or connector trouble in
to Step 22.
go to Step 24.

18 Click Go > Configuring and select the Trail TPs tab, then ensure that the
provisioned optical rate is correct by viewing the List Frame Rate to ensure
that the correct optical rate is selected.
Step 23.


—end—

Procedure 2-121
OTU PFSD
Probable Cause: OTU PFSD
NM Probable Cause: OTU PFSD
NM Additional Text: Pre-FEC Signal Degrade

TL1 String: PFSD
The PFSD alarm appears when the FEC Error Correction process records a
number of corrected errors (total of 1's and 0's) above the threshold for
consecutive 1 second intervals. The threshold value is dependent on the FEC
error correction scheme as defined by the user.
The PFSD alarm clears when the number of Corrected FEC Errors remains
below the provisioned threshold value during the number of consecutive one
second windows defined by the user.


Step Action
alarm, and note the OM or port that displays the OTU PFSD alarm.


or port.)
Manual. (Corrective action: clean the transmit OM or port fiber
connector, replace the OM or equivalent, and/or correct improper
LBO if not a 5400 Switch/CoreDirector Switch technology.).
Step 22.
go to Step 5.
CAUTION

CAUTION
ESD procedures.
ATTENTION

Installing an SFP/XFP/CFP in the 5400 Switch Service Manual. Insert the
receive fiber into a test set capable of reading bit errors, as well as light level.
14.
to Step 22.
go to Step 24.


14 Clean the OM or port fiber connector in accordance with the 5400 Switch
Service Manual.
selected.
SFP/XFP/CFP in the 5400 Switch Service Manual. If applicable, reinstall the
OM or SFP/XFP/CFP.
—end—

Procedure 2-122
OTU PFSF
Probable Cause: OTU PFSF
NM Probable Cause: OTU PFSF
NM Additional Text: Pre-FEC Signal Degrade

TL1 String: PFSF
The PFSF alarm is raised when number of Corrected FEC Errors remains
equal to or above the provisioned threshold value during the interval.
The PFSF alarm clears when number of Corrected FEC Errors remains below
the provisioned threshold value during the interval.


Step Action
alarm, and note the OM or port that displays the OTU PFSF alarm.

or port.)
Manual. (Corrective action: clean the transmit OM or port fiber
connector, replace the OM or equivalent, and/or correct improper
LBO if not a 5400 Switch/CoreDirector Switch technology.).
Step 22.
go to Step 5.
CAUTION

CAUTION
ESD procedures.
ATTENTION

Installing an SFP/XFP/CFP in the 5400 Switch Service Manual. Insert the
receive fiber into a test set capable of reading bit errors, as well as light level.
14.
to Step 22.
go to Step 24.


14 Clean the OM or port fiber connector in accordance with the 5400 Switch
Service Manual.
selected.
SFP/XFP/CFP in the 5400 Switch Service Manual. If applicable, reinstall the
OM or SFP/XFP/CFP.
—end—

Procedure 2-123
OTU TIM
Probable Cause: OTU TIM
NM Probable Cause: OTU TIM

TL1 String: OTU-TIM
An OTU TIM alarm is a connectivity defect caused by provisioning problems

within the network. The received OTU Trail Trace String (64 bytes) is
compared to an expected section trace string, and persistent mismatches are
reported.
The node detects a OTU Trail Trace Mismatch (TTM) defect within 30 seconds
when none of the sampled 64 or 16-byte STS path trace strings match the
provisioned value.
ATTENTION
An OTU TIM alarm may fail to clear on FSLM when using a test set trace
message. FSLM requires eight consecutive good (that is, ending with CR
and LF) trace messages before clearing. When the test set trace message is
disabled, a CR-LF is not sent and the received trace is never updated.


Step Action
1 At the Node Manager workstation, launch the NM application and log on to

the desired node.

alarm, and note the module that displays the OTU TIM alarm.
CAUTION
3 Verify that the node received section trace string value matches the expected
value in the PTP section trace screen.
4 Correction of the condition from Step 3 clears the alarm. If no condition
existed, the alarm clears within 30 seconds.
—end—

Procedure 2-124
Out-of-range
Category: Equipment
Object Class: PTP
Probable Cause: OOR
NM Probable Cause: OOR
NM Additional Text:
TL1 String:

Out-of-range (OOR) alerts for OPT and OPR are generated when the
monitored LBCnormal crosses the upper threshold setting and when
monitored OPTnormal falls outside the range specified by upper and lower
threshold settings. The warning for LBC-OOR indicates the need for replacing
the optical interface as it is approaching end-of-life.

Step Action

the desired node.
alarm, and note the OM or port that displays the Out-of-range alarm.
3 At the node, replace CFP/SFP/XFP in accordance with the “Removing and
Installing an SFP/XFP/CFP” procedure detailed in the 5400 Switch Service
Manual.
—end—

Procedure 2-125
PDI-P
Object Class: CTP (SONET)
Probable Cause: PDI-P
NM Probable Cause: PDI-P
NM Additional Text: Payload defect: observed xx VTx PDs
Condition Description: PDI-P detected
TL1 String: PDI-P
The node reports a Payload Defect Indication (PDI) against provisioned

SONET circuits. The node can monitor paths non-intrusively; however, it does
not normally function as path-terminating equipment. The 5400 Switch
mapping creates a terminated VC4, but the VC4 managed object is not
exposed to the management interface.


Step Action

the desired node.
alarm, and note the port that displays the PDI-P alarm.
3 In accordance with local practices, ensure proper provisioning on the drop
side equipment at both the ingress end and egress end of the path.
—end—

Procedure 2-126
PLM-P
Object Class: CTP (SONET/SDH)
Probable Cause: PLM
NM Probable Cause: PLM
NM Additional Text: Payload label mismatch - expected, observed
Condition Description: Payload label mismatch detected
TL1 String: PLM
Payload label mismatch is reported against provisioned SONET/SDH paths.

The node can monitor paths non-intrusively; however, it does not normally
function as path-terminating equipment. The 5400 Switch mapping creates a
terminated VC4, but the VC4 managed object is not exposed to the
management interface.
The PLM condition clears when the PLM-P defect clears, the CTP is
administratively locked, or the path is deleted.


Step Action
alarm, and note the port that displays the PLM-P warning and note any
additional text.
side equipment at both the ingress end and egress end of the path.
—end—

Procedure 2-127
Provisioning required
Object Class: PTP (Tunable DWDM Only)
Probable Cause: Provisioning Required
NM Probable Cause:
NM Additional Text: Provisioning Required
TL1 String: PROVREQ
The warning is raised when a Tunable Optical Interface does not have a
wavelength provisioned.
The warning is cleared when a valid wavelength is provisioned on the Tunable

Optical Interface and the PTP is placed in Administrative Lock or ARC Lock.


Step Action

the desired node.
alarm, and note the module that displays the Provisioning required alarm.
CAUTION

4 In the parameters section, select the desired frequency from the Frequency-
Wavelength drop-down menu.
5 Click Accept.
—end—

Procedure 2-128
RDI/MS-RDI
Probable Cause: RFI-L (SONET) or RDI (SDH)
NM Probable Cause: RFI-L (SONET) or RDI (SDH)
NM Additional Text:
Default Severity: Dynamic - Minor/Non service affecting for ports with

protected status, or Major/service affecting for ports with unprotected status
TL1 String:
• SONET- RFI-L
• SDH- RDI
RDI indicates the far end equipment is experiencing facility failure on the
signal being received from the near end. This could indicate an undetected
near end equipment failure (for example, optical output failure) or a media
failure (fiber cut) between the near end and the far end. Although conditions
are defined for these faults, they are typically only logged and not reported,
because the node that detected the root cause of the failure will have reported
the failure. Protection services use these defects to determine when a
protection switch is required.


Step Action
alarm, and note any additional port alarm information.


(SNC) alarms.
— If a SNC related alarm exists, discontinue this procedure and perform
the Unavailable (SNC) alarm TCP.
for this line to identify the LTE/PTE that may be generating this alarm.
—end—

Procedure 2-129
Remote nodes per system exceded
Object Class: OSIBASIC
Probable Cause: Remote Nodes per System Exceeded
NM Probable Cause: Remote Nodes per System Exceeded
NM Additional Text: Remote Nodes per System Limit exceeded. Configured:

<configured value> Current: <current value>
Condition Description: OSI alarm, raised when Remote Nodes per System
limit exceeds.
TL1 String: REMOTENODEPERSYSTEM
The alarm is raised if the count of the remote nodes, maintained in the
mCurNodesPerSystem parameter is greater than the configured value in the
mCnfNodesPerSystem parameter (i.e. Remote Nodes Per System).
The alarm is cleared when the count of remote nodes maintained in

mCurNodesPerSystem parameter is less than or equal to the configured value
in the mCnfNodesPerSystem.


Step Action
alarm that displays the source as OSIBASIC and probable cause as Remote
Nodes Per System Exceeded condition.
3 Click Go > Provisioning > OSI and select the General Settings tab and
increase the the value of remote nodes in the Remote Nodes Per CD field.
5.

5 Decrease the NSAP entries on the OSI Route page. This can be done either
by deleting the manually created OSI Routes or by setting the values of area
prefix on all the nodes in the network (on which OSI is enabled). This will
decrease the number of NSAP entries in the OSI Routes page.
7.
CTM.
—end—

Procedure 2-130
Reference failed
Object Class: Sync PU
Probable Cause: Reference Failed
NM Probable Cause: Reference Failed
NM Additional Text: <Sync PU Name > <Fault> on synchronization

reference on <A|C>-CTM
Condition Description: A failure is detected on an active interface

provisioned as a Sync PU.
TL1 String: REFFAILED
A Reference Failed alarm occurs when a source reference fails or when the
user removes a reference. The System declares a Reference Failed condition
when an active Synch PU is considered failed or unavailable for a period of
2.5 seconds or greater. Criteria to declare reference failed includes the
following conditions for both line and external references:
• LOS
• LOF
• AIS
• Frequency Out of Range
• Received SSM quality level below the quality level of the internal clock
• Received Invalid SSM
ATTENTION
In rare circumstances, failures involving both primary and secondary CTMs
cannot be reported directly through a Replaceable unit problem alarm.
Instead, this alarm may be reported against a timing source, with
timing_input_ref additional text indicating CLK_LOS for the CTM failure. If
the TCP below does not clear the alarm, follow the TCP in section
Replaceable unit problem.



Step Action

the desired node.
alarm, and note the internal or external source reporting the alarm. Note any
CTM equipment failures or Reference Failed alarms reporting on either CTM.
3 If any CTM equipment failures alarms are reporting on either CTM, perform
the associated TCP to clear the alarm.
4 View the alarm and event summary and details screen and note the failure
reason for the alarm (LOS, LOF, AIS, Frequency Out of Range, Received
SSM quality level below the quality level of the internal clock, Received Invalid
SSM).
5 If the alarm is caused by LOS, LOF, AIS, Frequency Out of Range, Received
SSM quality level below the quality level of the internal clock, Received Invalid
SSM, refer to the appropriate procedure and clear the alarm.
ATTENTION
occurred.
6 Click Go > Administration >Timing Reference > Station Clock/BITS

Input, and select the failed reference.
ATTENTION
The information shown on the config screen is the up to date status of the
reference. It does not reflect the contents of the alarm. The alarm reflects the
conditions at the time the reference failed.
7 Verify that the SF/ESF and AMI/B8ZS formats are correctly provisioned in
accordance with internal guidelines. Correct as necessary.
8 Verify that the SF/ESF or AMI/B8ZS settings were corrected in Step 7.
— If the SF/ESF or AMI/B8ZS settings were corrected, go to Step 9.
— If the SF/ESF or AMI/B8ZS settings were not corrected, go to Step
11.
9 Wait 20 seconds and go to Step 10 to verify the signal.

CAUTION
CAUTION
ESD procedures.
ATTENTION
10 Disconnect the affected input BITS connector/wires from the back of the
node. Using the proper connector pins (TIP, RING, and GND), connect the
DS1 signal to a test set.
— If the test set reports a valid DS1 signal with the proper SF/ESF and
AMI/B8ZS formats, reconnect the BITS connector/wires to the 5400
Switch bay and go to Step 11.
— If the test set does not report a valid signal with the proper SF/ESF
and AMI/B8ZS formats, correct external clock problem or BITS
cabling/connector problem in accordance with internal guidelines.
When the external problem is corrected, go to Step 14.
11 Wait 20 seconds and verify that the alarm cleared at the Node Manager
workstation.
12 Reset primary CTM.
13 Replace the standby CTM (CTM reset in Step 12) in accordance with the
Remove and Replace CTM procedure in the 5400 Switch Service Manual.
14 Wait 20 seconds and verify that the alarm cleared at the Node Manager
workstation.
—end—

Procedure 2-131
Replaceable unit mismatch
Category: Equipment
Object Class: Any Equipment
Probable Cause: Replaceable Unit Type Mismatch
NM Probable Cause: Replaceable Unit Type Mismatch
NM Additional Text:
• <equipment AID>, <expected_part_code > expected,

<actual_part_code> installed.
• Unknown part number installed. <part code> Rev <rev> not supported by
this software release.
Condition Description: Replacement module is not the same type as the
module replaced
TL1 String: REPLUNITMISMATCH
The Replaceable Unit Type Mismatch alarm appears when a replacement

module, typically an SFP/XFP/CFP, is not the same type as the module
replaced. If the replacement module is not a compatible type, the module is
not activated and the Replaceable Unit Type Mismatch alarm is reported.
This alarm occurs under two scenarios: the wrong replacement module is
installed or when the intent is to change the module type (for example when
replacing an IR SFP with an LR or when replacing an LM-12 with an LM-48).
To clear the alarm, the user must install the correct module or delete the
existing module from inventory.


Step Action

alarm, and note the module that displays the alarm and note any additional
text information.
— If the additional text information indicates that replaced module is an
unknown part number or not supported by this release, go to Step 6
and replace the module with one supported in this release.
— If the additional text information is empty or indicates that replaced
module is an unexpected part number, go to Step 3.
3 Expand the equipment tree until the alarmed replaceable unit module is
displayed. Click Inventory, then click the alarmed module from the equipment
tree. Verify that the correct module is installed in the alarmed slot by
comparing the information in the inventory display with information from the
internal facility records.
— If the correct module is not installed, go to Step 6.
— If the correct module is installed, go to Step 4.
CAUTION
ESD procedures.
4 If the replacement module is the correct type and is the same type as the
module removed, remove, then re-install module in accordance with the
appropriate 5400 Switch Service Manual procedure listed below.
5 If the replacement module is the correct type and but is not the same type as
the module removed, remove, delete from inventory, and then re-install
module in accordance with the appropriate 5400 Switch Service Manual
procedure listed below.
—end—

Procedure 2-132
Replaceable unit missing
Category: Equipment
Probable Cause: Replaceable Unit Missing
NM Probable Cause: Replaceable Unit Missing
NM Additional Text: <equipment AID>, <equipment_name >, <CLEI>

missing.
Condition Description: Equipment removed from the chassis without first

administratively locking the respective replaceable unit
Default Severity: Dynamic
• Critical, service affecting if the missing equipment causes a data plane failure and is not
protected or if declared against an SM.
• Major, service affecting if the missing equipment causes a data plane failure. Other
alarms related to the service are not correlated to this condition and will raise alarms
relative to the appropriate service impact.
• Minor, not service affecting if the missing equipment causes a failure of a PTP which is
administratively locked. This applies to line modules and optical modules.
• Minor, not service affecting for a missing CTM.
• Critical, service affecting for a missing SM.
• Minor, not service affecting for a missing PDU.
• Critical, service affecting for a missing fan module.
• Minor, not service affecting for a missing I/O Panel or Display Panel.
TL1 String: REPLUNITMISS
The Replaceable Unit Missing alarm is raised when any equipment is

removed from the chassis without first administratively locking the respective
replaceable unit.
ATTENTION
All circuit packs provide a Maintenance LED (MNT) which is illuminated
yellow to indicate the circuit pack has been administratively locked and can
be removed without causing a Replaceable Unit Missing condition.
All optical modules/SFP/XF/CFPP provide a tri-color LED which is

illuminated yellow to indicate the PTP has been administratively locked and
can be removed without causing a Replaceable Unit Missing condition.



Step Action
alarm, and note the alarm.
— If an Input Power alarm or Total Loss of Communications alarm is
present, discontinue this procedure and perform the TCP for the
appropriate alarm.
3 Expand the equipment tree until the alarmed Replaceable Unit is displayed
and note the shelf and slot designation.
CAUTION
CAUTION
ESD procedures.
5 Verify that there are no red LED alarms at the node.
— If there are no red LED alarms, go to Step 6.
— If there are red LED alarms, repeat Step 4 and replace the alarmed
circuit pack. If the circuit pack has already been replaced, go to Step
6.


— If the alarm did not clear, repeat the remove and install procedure in
accordance with the applicable procedure to reseat the circuit pack.
—end—

Procedure 2-133
Replaceable unit problem
Category: Equipment
Probable Cause: Replaceable Unit Problem
NM Probable Cause: Replaceable Unit Problem
NM Additional Text: Dynamic - (Refer to Additional Text below.)
Condition Description: A Replaceable Unit Problem (RUP) alarm occurs

when an installed circuit pack experiences failure or exceeds its max
operating temperature.
Default Severity: Dynamic - Service affecting if the equipment is carrying

service at the time of the failure, and as non service affecting otherwise. (Refer
to Severity below.)
TL1 String: REPLUNITPROB
Severity
The Replaceable Unit Problem (RUP) condition has the following severity
parameters:
• Critical, service affecting if the failure affects unprotected traffic.

• Critical, service affecting if the failed equipment causes a timing plane
failure and is not protected. The System changes the severity and service
indication to Major, Non service affecting if the failed equipment causes a
timing plane failure and is protected.
• Critical, service affecting for defects which result in a HIR or failed state for
a SM regardless of the protection status.
• Major, Non service affecting for a failed PDU.
• Minor, Non service affecting for a failed I/O Panel or Display Panel.
• Major, Non service affecting for Flash Card End of Life
Additional Text
When the System declares a Replaceable Unit Problem (RUP) condition
against equipment the RUP additional text field includes the equipment Serial
Number. The serial number is included in addition to any RUP specific
additional texts as described below. The serial number field is separated from
the other additional text by a comma:

SN=<Serial Number>
• When the System declares a Replaceable Unit Problem (RUP) condition
against equipment that is re-booting or in a marginal state with no further
root cause, the RUP additional text field is:
Please replace equipment if this condition does not clear in 15 min
against equipment that is re-booting with no further root cause, the RUP
additional text field is:
Re-booting - Please replace equipment if this condition does not clear in 15 min
against equipment that is in a Marginal State with no further root cause,
the RUP additional text field is:
Degraded State - Please replace equipment if this condition does not clear in 15 min
• Device Max Temperature is raised when the junction temperature of given
device on a circuit pack rises above its absolute max temperature
threshold. Each device can have its own threshold. For Control CPUs, the
threshold is [max operating temperature - 5C]. For data path and other
devices, the threshold is [max operating temp + 5C] or the absolute max
temperature if it is specified by the datasheet.
• Device Max Temperature is cleared when the junction temperature of the
given device on a circuit pack falls below [target setpoint + 5C].
• The System changes the additional text for a CTM Device Over
Temperature notification to:
Device Over Temperature - contains a device that exceeds its max operating
temperature
against equipment that has a Invalid DIP Switch Setting fault, the RUP
Invalid DIP Switch Setting
against equipment because of a TPFI, DPFI, or CPFI it also lists an
isolation mechanism code in the additional text. THe user should send this
code to Ciena support engineers to determine the underlying failure
condition and/or component.
• Flash Card End of Life is raised when the Flash Card on a CTM or LM has
2% or less available life remaining. Flash Card Life is determined by the
Remaining Erasures divided by the Available Erasures.
TPHF Additional Text
against equipment because of a TPFI condition the additional text includes an
isolation code as listed in Table 2-2. If the failure is isolated to a single port on

an LM, the port number is also listed in the additional text. The user should
record the additional text and the isolation code and forward the data to the
next level of support and to Ciena.

against equipment because of a TPFI Failure, the RUP additional text field
is:
TPHF,<Isolation Mechanism>;
against equipment because of a Port TPFI Failure, the RUP additional text
field:
PTPHF,<Port Identity>,<Isolation Mechanism>;
• For multiple conditions on the same port, the System the Isolation
Mechanisms following the Port Identity. For multiple conditions on multiple
ports, the System lists each port followed by the Isolation Mechanism(s).
• The Port Identity field indicates the Port Group and affected Ports where
the failure has been isolated:
<PG[1-12],Port[1-4]>
the failure has been isolated.
<PG[1,2,..x],Port[1,2..x]>
Table 2-2
5400 TPHF isolation mechanism codes /16/64/OC-3/12/48/192
Isolation TPFI failure

code
I40 Stratum 3E Module Failure
I41 BITS Hardware Failure
I42 Timing HW Failure
I43 Internal Timing Reference Distribution Failure
I44 SWSYNC Generation Failure
I45 SWSYNC Distribution Failure
I46 SWSYNC Phase Lock Failure
I47 Peer SWSYNC Input Failure
I48 SWCFG-EN Distribution Failure
I49 SWCFG Distribution Failure
I50 Partial Timing Reference Input Failure

Table 2-2
5400 TPHF isolation mechanism codes (continued)/16/64/OC-3/12/48/192

code
I51 Complete Timing Reference Input Failure
I52 SLP Timing Reference Distribution Failure
I53 SLP Port Timing Reference Distribution Failure
I54 Partial SWCFG Input Failure
I55 Complete SWCFG Input Failure
I56 LM Port Complete BITS Reference PLL Failure
I57 SFI-4.1 Port Timing Failure
I58 XAUI Port Timing Failure
I59 LM Port PLL Failure
I60 Partial SWCFG-EN Input Failure
I61 Complete SWCFG-EN Input Failure
I62 Timing Reference Input Oscillation
I63 SWCFG-EN Multi LM Failure
I64 SWCFG Multi LM Failure
I65 TMREF Multi LM Failure
I66 Partial SWSYNC Input Failure
I67 Complete SWSYNC Input Failure
I68 SWSYNC Multi LM Failure
Examples of the TPFI RUP notification additional text are listed as follows:
TPHF,I50;
PTPHF,PG1,Port1,I56;
PTPHF,PG1,Port1,2,PG2,Port7,8,PG3,Port9,10,11,12,I56;
DPHF Additional Text
against equipment because of a DPFI condition the additional text includes
the AID of the equipment where the failure has been isolated. The additional
text also lists an isolation code as listed in Table 2-3. The user should record
the additional text and the isolation code and forward the data to the next level
of support and to Ciena.


against equipment that is DPFI LM Subsystem Failure with no further root
cause, the RUP additional text field is:
Degraded State - Please replace equipment if this condition does not clear in 15 min
<Isolation Mechanism>
against equipment because of a DPFI Failure, the RUP additional text field
is:
DPHF,<Isolation Mechanism>,<optional: Error Type Bit Mask>,<optional: Link Bit
Mask>,<optional: Link Identity List>;
• The Link Identity List is comma delimited where each item in the list follows this format
(the '<' and '>' below denote "the value of"):
<AID of Tx Component>,<AID of Rx Component>
against equipment because of a Port DPFI Failure, the RUP additional text
field is:
PDPHF,<Port Identity>,<Isolation Mechanism>,<optional: Error Type Bit
Mask>,<optional: Link Identity List>,<optional: Component Number>,<optional:
Condition Type>;
• The Link Identity List is comma delimited where each item in the list follows this format
(the '<' and '>' below denote "the value of"):
<AID of Tx Component>,<AID of Rx Component>
• For multiple conditions on the same port, the System lists the Isolation
Mechanisms following the Port Identity. For multiple conditions on multiple
ports, the System lists each port followed by the Isolation Mechanism(s).
the failure has been isolated.
<PG[1-12],Port[1-4]>
ATTENTION
The Error Type Bit Mask and Link Identity Lists are optionally because some
errors do not produce them. For example, an STSX internal error will not
have any associated links.
Table 2-3
5400 DPHF isolation mechanism codes /16/64/OC-3/12/48/192

code
I01 InitFailureDetection
I02 Not Applicable
I03 STSXInternalFailureDetection

Table 2-3
5400 DPHF isolation mechanism codes (continued)/16/64/OC-3/12/48/192

code
I04 STSXInputLinkWarningIsolation
I05 STSXInputLinkFailureIsolation
I06 FramerFailureDetection
I07 LmHardFailedPowerFailureDetection
I08 LmHardFailedCpFailureDetection
I09 SmHardFailed
I10 BankSelectFailureDetection
I11 Not Applicable
I12 LmComponentFailureDetection
I13 Not Applicable
I14 Not Applicable
I15 ComProgramingFailureDetection
I16 LinkEnableFailureDetection
I17 DeviceOverTemperature
Examples of the DPHF RUP notification additional text are listed as follows:
DPHF,I03,0x400;
PDPHF,PG1,Port1,I05,0x4,1-A-1.1,1-A-1.a;
PDPHF,PG1,Port1,I05,0x4,1-A-1.1,1-A-1.a,PG4,Port4,I05,0x4,1-A-1.4,1-A-1.a;
PDPHF,PG1,Port1-4,I05,0x4,1-A-2.1,1-A-2.a,PG4,Port13-16,I05,0x4,1-A-2.4,1-A-2.a;
PDPHF,PG2,Port2,I06,0x8,0x4;
PDPHF,PG1,Port1-4,I05,0x4,1-A-2.1,1-A-2.a,PG4,Port13-16,I05,0x4,1-A-2.4,1-A-
2.a;DPHF,I05,0x4,1-A-2.a,1-B-1.a,1-A-2.a,1-B-1.b,1-A-2.a,1-B-1.c,1-A-2.a,1-B-2.a;
CPHF Additional Text
against equipment because of a CPFI condition the additional text contains an
isolation code as listed in Table 2-4. The user should record the additional text
and the isolation code and forward the data to the next level of support and to
Ciena.


against equipment that is Held in Reset with no further root cause, the
RUP additional text field is:
Held in Reset,<Isolation Mechanism>;
against equipment because of a CPFI Failure, the RUP additional text field
is:
CPHF,<Isolation Mechanism>;
against equipment because of a Invalid DIP Switch Setting condition, the
RUP additional text field is:
CPHF,<Isolation Mechanism>;
• When the system raises a Replaceable Unit Problem (RUP) condition
against equipment because of a Flash Card End of Life condition the RUP
CPHF,Flash Card End of Life <Isolation Mechanism>;
Table 2-4
5400 CPHF isolation mechanism codes /16/64/OC-3/12/48/192

code
I80 Re-booting
I81 Marginal State
I82 Held in Reset
I83 Slot ID/Internal Address Failure
I84 LM Ethernet Communications Failure
I85 Complete Internal Ethernet Communications Failure
I86 Network Switch Failure
I87 Switch Core Communications Failure
I88 Backplane Serial Bus Signal Failure
I89 Backplane Reset Signal Failure
I90 Backplane Primary Signal Failure
I91 I2C Bus Failure
I92 EEPROM Failure
I93 NVRAM Failure

Table 2-4
5400 CPHF isolation mechanism codes (continued)/16/64/OC-3/12/48/192

code
I94 CTM Ethernet Communications Failure
I95 Partial Internal Network Failure
I96 Boot Flash Failure
I97 Processor Failure
I98 Power Supply Failure
I99 Flash Card End 0f Life
Examples of the CPFI RUP notification additional text are listed as follows:
CPFI:
CPHF,I88;
ATTENTION
Once fault management declares a failure, it remains declared until the card
is removed. However, any condition that is reported externally is subject to
the rules concerning the admin lock state of the equipment (for example,
conditions are remitted when the module is placed in admin lock and
reasserted when the admin lock is removed). The normal procedure for
removing a card is to first place it in admin lock (remitting the condition) and
then to remove it. If the operator fails to place the card into admin lock prior
to removing it, the failure condition is still remitted when the card is removed
and a replaceable unit missing condition is asserted.
If the fault signature changes after the Replaceable Unit Problem has been
declared, the System l clears the condition on the TL1 interface, and re-assert
it with updated information.
If the fault signature changes after the Replaceable Unit Problem has been
declared, the System updates the condition on the CORBA interface with
updated information.
The System clears the Replaceable Unit Problem condition when the
equipment is administratively locked or removed.
The System raises the Replaceable Unit Problem condition when the fault
persists and the equipment is removed from an administratively locked state.



Step Action
alarm, and note the alarmed module and note any additional information.
— If Input Power or Total Loss of Communications alarms are present,
discontinue this procedure and execute the TCP for the appropriate
alarm.
— If additional information indicates circuit pack is rebooting or in a
degraded state, then wait indicated time and go to Step 6.
3 Expand the Equipment Tree until the alarmed Replaceable Unit is displayed
and note the shelf and slot designation.
— If the alarmed Replaceable Unit is an SFP/XFP/CFP, go to Step 4.
— If the alarmed Replaceable Unit is a LM, go to Step 9.
— If the alarmed Replaceable Unit is not a LM or SFP/XFP/CFP, go to
Step 11.
4 If multiple SFPs/XFPs on any one LM are reporting RUP alarms, contact the
next level of support. If only one SFP/XFP/CFP is affected then proceed with
Step 5.
5 Change the Administrative State of the SFP/XFP/CFP to Locked using the
Node Manager Inventory screen. Verify the Administrative State has changed
to Locked.
6 Change the Administrative State of the SFP/XFP/CFP to Unlocked using the
Node Manager Inventory screen. Verify the Administrative State has changed
to Unlocked.
7 Check that the Operational State and Availability Status are Enabled and
Acceptable, respectively. Check that the Alarm Status box is clear.
9 If four sequential LMs are reporting RUP alarms, verify that remaining LMs
are functioning properly.
— Refer to the 5400 Switch Service Manual and perform the Resetting
the Primary Control and Timing Module (CTM Switch) procedure.
— If LM RUP alarms clear, perform the Removing and Installing a
Control and Timing Module procedure in the 5400 Switch Service
Manual and replace the secondary CTM.

10 Wait five minutes. If the red LED on the LM is lit but goes off within five
minutes, the LM was rebooting. If the LED does not go off within five minutes,
the node will raise a RUP with DPHF additional text. In this case, clear the
new alarm by replacing the circuit pack in accordance with the appropriate
5400 Switch Service Manual procedure listed below:
CAUTION
CAUTION
ESD procedures.
ATTENTION
11 At the node, verify that the replaceable unit circuit pack in question has a red
LED illuminated. Replace the circuit pack in accordance with the appropriate
procedure as listed above.
12 When an SM is replaced but does not come up in 60 seconds, repeat the
replacement procedure to reseat the SM. If the SM still does not come up
within 60 seconds, replace and RMA the SM.
13 Verify red LED alarm cleared at node.
ATTENTION
The SM does not have a microprocessor and relies on dedicated hardware
to control LEDs. Under certain failure conditions the LEDs might get out of
sync with the alarm state as indicated by the CTM to Core Switching
Manager or Node Manager. Use Core Switching Manager and Node
Manager statements of alarms/conditions for SM related alarms/conditions.
— If success, go to Step 14.

— If failure, go to Step 15.

14 Verify alarm cleared at Node Manager workstation.
— If success, end this procedure.
15 If additional information noted in Step 2 indicates additional suspect circuit
packs, go to Step 11 and replace suspect circuit pack (one at a time) or go to
Step 16.
— If success, end procedure.
— If the alarm did not clear, repeat the remove and install procedure in
accordance with the applicable procedure in the 5400 Switch Service
Manual to reseat the circuit pack.
—end—

Procedure 2-134
SD/SF
Category: Quality Of Service
Object Class: TTP
Probable Cause: Degraded Signal/Excessive BER
NM Probable Cause: Degraded Signal/Excessive BER
NM Additional Text:
• SD- signal degrade threshold of 10E-XX crossed

• SF- signal failed threshold of 10E-XX crossed
Condition Description: SD or SF thresholds crossed
Default Severity: Dynamic - Minor, Non service affecting for ports with
protected status, or Major, service affecting for ports with unprotected status
TL1 String: BERSD/BERSF
A Signal Degrade (SD) condition is declared when the quality of an optical

signal exceeds the user definable BER signal degrade threshold. Signal Fail
(SF) condition is declared when the quality of an optical signal exceeds the
user definable BER signal fail threshold.

Step Action
alarm, and note the port that displays the SD/SF alarm.
accordance with the guidelines of that technology. If the line in alarm is in the

Switch or CoreDirector Switch. If the line in alarm is a network drop, the

upstream technology is typically an Aggregator/MUX. The far end upstream
LTE or MSTE laser should be checked for the following:
present. (Corrective action: replace the SFP/XFP/CFP, LM, or
equivalent.)
be correct. (Corrective action: replace SFP/XFP/CFP or equivalent
with correct rate, wavelength, and reach. To check/correct
provisioned rate of a transmit port, expand the Node Manager
configuration tree and select the port, click Go > Inventory and
select the Physical TP tab, then ensure that the provisioned
optical rate is correct. Always lock the port before correcting and
unlock when completed.)
– The laser should not be locked. (Corrective action: unlock the SFP/
XFP/CFP or port.)
Manual. (Corrective action: clean the transmit port fiber connector,
replace the SFP/XFP/CFP or equivalent, and/or correct improper
LBO if not a 5400 Switch or CoreDirector Switch technology.).
go to Step 22.
CAUTION
CAUTION
ESD procedures.

ATTENTION
5 Remove the port receive fiber and insert the receive fiber into a test set
capable of reading bit errors, as well as light level.
or MSTE in alarm).
12.
to Step 22.
go to Step 24.
alarmed port. Correct any problems that are found.


port in alarm.
17 Click Go > Configuring > Trail TPs.
selected.
—end—

Procedure 2-135
SD-P/SF-P
Category: Quality Of Service
Object Class: CTP
Probable Cause: Degraded Signal/Excessive BER
NM Probable Cause: Degraded Signal/Excessive BER
Condition Description: SD or SF thresholds crossed
TL1 String: BERSD/BERSF
The Signal Degrade -Path (SD-P) condition and Signal Fail - Path (SF-P) are
similar to the SD/SF on Page 293 only applied to the path layer.
To clear this alarm, perform the procedures discribed on Page 293 to clear
SD-P and SF-P.

—end—

Procedure 2-136
Secondary CTM initializing
Probable Cause: Secondary CTM Initializing
NM Probable Cause: Secondary CTM Initializing
NM Additional Text: Loss of CTM Redundancy; the Secondary CTM is

Initializing.
Condition Description: Loss of CTM Redundancy; the Secondary CTM is

Initializing.
TL1 String: SECCTMINIT
The Secondary CTM Initializing alarm is raised when the Secondary CTM is
synchronizing the database with the Primary CTM and there is no RUP CPHF
condition against the Secondary CTM.
The alarm clears under the following conditions:
• the Secondary CTM completes the synchronizing process with the

Primary CTM and it is available for switchover
• the Secondary CTM becomes the Primary CTM
• the Secondary CTM enters an Admin Locked state
• the Secondary CTM is reset or the control plane is restarted
• the system raises a RUP CPHF condition against the Secondary CTM
• the Secondary CTM is removed from the system

No action is required.
—end—

Procedure 2-137
Section trace mismatch
Object Class: TTP (SONET)
Probable Cause: Section Trace Mismatch
NM Probable Cause: Section Trace Mismatch
NM Additional Text: Received trace: <rcvd_trace>. Expected trace:

<expt_trace>
Default Severity: Dynamic (see below), Non service affecting
• Warning, NSA:
– Port has no cross-connection provisioned
– Services with unprotected status and AIS forward disabled
– Services with protected status, AIS forward enabled, and the
switch selector does not indicate the port
– Services with protected status, AIS forward disabled, and the
switch selector indicates the port
• Major:
– Services with unprotected status and AIS forward enabled, SA.
switch selector indicates the port, NSA.
TL1 String: TIM-S
A Section Trace Mismatch is a connectivity defect caused by provisioning

problems within the network. The received Section Trace String (STS) (the J0
byte) is compared to an expected section trace string, and persistent
mismatches are reported.

The STS PTE detects a Section Trace Identifier Mismatch (TIM-S) defect
within 30 seconds when none of the sampled 64 or 16-byte STS path trace
strings match the provisioned value. The 5400 Switch declares an Section
Trace Mismatch failure if a TIM-S defect persists for 2.5 seconds. The TIM-S
defect clears if it is absent for 10 seconds.


Step Action

the node.
alarm, and note the module that displays the Section Trace Mismatch alarm.
CAUTION
3 Verify that the LTE or MSTE received STS section trace string value matches
the expected value in the PTP section trace screen.
4 Correction of the condition from Step 3 should clear the alarm. If no condition
existed, the alarm should clear after no more than 30 seconds.
—end—

Procedure 2-138
Signaled SNCP automatic switch
Probable Cause: SSNCP Automatic Switch
NM Probable Cause: SSNCP Automatic Switch
NM Additional Text:
Condition Description: LOP/AIS-P/SF-P/SD-P detected on the work path

and the protect path is error-free
TL1 String: WKSWPR
A Signaled SNCP (S-SNCP) Automatic Switch condition is raised when a

revertive S-SNCP Protection Group automatically switches to protect or if a
protection group is provisioned from non-revertive to revertive, and if it is not
on the working line at the time of the provisioning change.
The S-SNCP Automatic Switch to Protect condition clears if a protection group

is provisioned from revertive to non-revertive and when the target object is no
longer automatically protected.


Step Action
alarm, and note the port that displays the Signaled SNCP automatic switch
condition.


or equivalent.)
go to Step 25.
ATTENTION
7 Clean the receive fiber in accordance with Ciena Standard Cleaning and


or MSTE in alarm).
14.
Step 12.

tabs.
selected.
21 Reconnect the receive fiber, then reinstall the port in accordance with the
23 Replace the port with a shelf spare, then go to Step 26.
—end—

Procedure 2-139
Signaled SNCP fail to switch
Probable Cause: SSNCP Failure to Switch
NM Probable Cause: SSNCP Failure to Switch
NM Additional Text:
Condition Description: Defects on both the Work and Protect paths prevent
protection switch
The S-SNCP Fail to Switch alarm is raised when a S-SNCP protection feature
is unable to perform an automatic protection switch. The alarm clears when
the switch succeeds or if the protection switch is no longer required because
the underlying failure cleared.


Step Action
3 Note and clear any path faults protection switch byte failure, Signaled SNCP
Failure to Switch, and far end protect line fail alarms.
—end—

Procedure 2-140
Signaled SNCP forced switch to protect
Probable Cause: SSNCP Force Switch to Protect
NM Probable Cause: SSNCP Force Switch to Protect
NM Additional Text: Force Switch to Protect
The S-SNCP Forced Switch to Protect condition is raised when a forced

switch to the protect path is initiated. The condition is cleared when a higher


Step Action
alarm, and note the module that displays the Signaled SNCP forced switch
to protect warning.
3 From the list under the Go > Protection > Path Level > SNCP > Groups tab,
select the protection unit identified in Step 2.
OKAY.
signaled SNCP protection group.


9 Click Accept.
—end—

Procedure 2-141
Signaled SNCP forced switch to working
Probable Cause: SSNCP Force Switch to Work
NM Probable Cause: SSNCP Force Switch to Work
The S-SNCP Forced Switch to working condition is raised when a forced

switch to the working path is initiated. The condition is cleared when a higher


Step Action
alarm, and note the module that displays the Signaled SNCP forced switch
to working warning.
3 Under the Go > Protection > Path Level > SNCP > Protection Units tab,
select the ASNCP protection unit identified in Step 2 from the list in the list
frame.
4 Click the Release button in the Administer/Status field.
6 If there are several protection units switched, under the Go > Protection >
Path Level > SNCP > Group tab, select the ASNCP group identified in Step
2 from the list in the list frame.
8 Click Accept.

—end—

Procedure 2-142
Signaled SNCP lockout of protection
Probable Cause: SSNCP Lockout of Protect
NM Probable Cause: SSNCP Lockout of Protect

Selector: <bay>-<shelf>-<slot>-<port>_<headTs> Current Selector: <bay>-
<shelf>-<slot>-<port>_<headTs>
Condition Description: User invoked lock out of protection detected
This warning occurs when a user invokes a lock out of protection on an

ASNCP protection unit and is cleared when the lockout is released.


Step Action
alarm, and note the module that displays the Signaled SNCP lockout of
protection warning.

—end—

Procedure 2-143
Signaled SNCP manual switch to protect
Probable Cause: SSNCP Manual Switch to Protect
NM Probable Cause: SSNCP Manual Switch to Protect
Condition Description: User invoked manual switch to protection on an S-

SNCP protection unit detected
The S-SNCP Manual Switch to Protect condition is raised when a manual

switch to the protect path is initiated and the S-SNCP protection feature is
provisioned as revertive. The condition is cleared when a higher priority switch
is initiated or when the manual switch is released.


Step Action
alarm, and note the module that displays the Signaled SNCP manual switch
to protect condition.
Go > Protection > Path Level > SNCP > Group tab, select the signaled
SNCP protection group from the list.

—end—

Procedure 2-144
Signaled SNCP manual switch to working
Probable Cause: SSNCP Manual Switch to Work
NM Probable Cause: SSNCP Manual Switch to Work
NM Additional Text:
Condition Description: User invoked Manual Switch to Working detected
This warning is raised when a manual switch to the working path is initiated
and the S-SNCP protection is provisioned as revertive. The condition is
cleared when a higher priority switch is initiated or when the manual switch is
released.


Step Action
alarm, and note the module that displays the Signaled SNCP manual switch
to working warning.
4 Verify the state of the protect path in the Administer/Status field; it should be
OKAY.

9 Click Accept.
—end—

Procedure 2-145
SNC home path not defined
Object Class: MoOrigSpvcEpt
NM Probable Cause: SNC Home Path Not Defined
NM Additional Text: SNC Home Path Not Defined
TL1 String:
The SNC Home Path not Defined condition is raised if a SNC with Reserved
Home Path enabled does not have a Home Path. This can occur if the SNC
Home Path is released without successfully setting up a new Home Path.


Step Action
condition, and note the port that displays the SNC home path not defined
alarm.
3 Click Go > Provisioning > SNC and select the SNC in alarm.
4 Ensure that if this is a DTL SNC or if constraints are provided, there is valid
path for that particular SNC.
5 Ensure that the SNC is able to setup.
6 Click Accept.
—end—

Procedure 2-146
SNC manual regroom status
Category: Reporting event
Object Class: MoSncOrigEpt
NM Probable Cause: SNC Manual Regroom Status
NM Additional Text:
Condition Description: Report SNC Manual Regroom Status
Default Severity: not applicable
TL1 String: not applicable


—end—

Procedure 2-147
SNC restored using preemption
Object Class: SNC
NM Probable Cause: SncRestoredUsingPreemption
NM Additional Text: WorkingDtl CN5430-30 435 CN5430-45 0
Condition Description: SNC preempted RHP Bandwidth during restoration

as there was no BW availability for this connection
TL1 String: SncRestoredUsingPreemption


Step Action
1 The snc preempts a home path as a last resort. To clear the alarm an
alternate route has to be made available and the snc switched to this
alternate route. This alternate route switch can happen due to Mesh, MSP,
Auto Reversion or Manual Reversion using MSP.
—end—

Procedure 2-148
Superuser logged in
Category: Usage report
Object Class: MoAccount
Probable Cause: Superuser login
NM Probable Cause: Superuser login
NM Additional Text:
Condition Description: Super User Logged In
TL1 String:


Step Action
1 Logout from Super User account.

—end—

Procedure 2-149
TAP connection active
Object Class: TTP, PTP
Probable Cause: Tap connection Active
NM Probable Cause: Tap connection Active
NM Additional Text: Source CTP: <CTP>, XCON under test: <XCON>,

Supporting SNC: <SNC>, TAL Name: <TAL>, Qualifier: <Qualifier>, Mode:
<Mode>
Condition Description: TAP Connection created
TL1 String: MISC
A TAP Connection Active condition is raised when a TAP connection is created

and cleared when it is deleted.


Step Action
condition, and note the port that displays the TAP connection active
warning.
— If power conditions alarms are present, discontinue this procedure
and perform the TCP for the appropriate alarm.
3 Expand the equipment tree until the alarmed port is displayed and note the
shelf and slot designation.
4 Click Go > Diagnostics > TAP Connection, select the TAP connection and
press Delete.
5 Click Accept.


— If the alarm did not clear, repeat the above procedure.
—end—

Procedure 2-150
TCM AIS
Object Class: TTP, CTP (TCM)
Probable Cause: TCM AIS
NM Probable Cause: TCM AIS

unprotected status
TL1 String: TCM-AIS
An ODU TCM AIS indicates that upstream equipment has experienced a

TCM AIS alarm in the reporting node.
When a 5400 Switch detects ODU fault on an incoming signal or a trace

mismatch alarm exist, it generates an AIS on the outgoing CTPs. When TCM
AIS is detected on a TTP, a BDI signal is sent back toward the peer to indicate
that the 5400 Switch has detected an TCM AIS or lower layer defect on the
signal that the peer originated.
A Tandem Connection Monitor AIS (TCM-AIS) alarm is raised when an TCM

dAIS defect persists for 2.5 (±0.5) seconds.


Step Action
condition, and note the port that displays the TCM AIS alarm.

3 Expand the 5400 Switch equipment tree until the alarmed port is displayed
and verify that no equipment alarms exist.
CAUTION
The following steps are performed at the Switch.
set.
— If test set reports incoming TCM AIS or any other line signal defect,
ATTENTION
5 Reconnect fiber, reinstall OM, SFP or XFP, and recheck alarm status.
6 Replace the OM, SFP or XFP
—end—

Procedure 2-151
TCM BDI
Object Class: TTP, CTP
Probable Cause: TCM BDI
NM Probable Cause: TCM BDI

unprotected status
TL1 String: TCM-BDI
A TCM BDI is a maintenance signal used to alert upstream equipment that a

defect (for example, LOS or LOF) has been detected. This signal informs an
node originated. Resolving the fault in the adjoining node clears the TCM BDI
alarm in the reporting node.An TCM-BDI alarm is raised when a TCM far end
defect persists for 2.5 (±0.5) seconds.


Step Action
TCM BDI alarm, and note any additional port alarm information.
(SNC) alarms.
Unavailable (SNC) alarm TCP.


—end—

Procedure 2-152
TCM DEG
Probable Cause: TCM DEG
NM Probable Cause: TCM DEG
NM Additional Text: Degrade, Exceeded <Percent of Errored Blocks>%

errored blocks in <DEGM = 2-10> seconds

TL1 String: TCM-DEG
The TCM-DEG alarm is raised when an TCM DEG defect persists for 2.5
(±0.5) seconds.


Step Action
alarm, and note the port that displays the TCM DEG alarm.


or equivalent.)
go to Step 24.
CAUTION
CAUTION
ESD procedures.

ATTENTION
12.
receive 5400 Switch node. Isolate and clean/repair the fiber or connector
to Step 22.
go to Step 24.


port in alarm.
18 View the Service Type box and ensure that the correct optical rate is
selected.
19 Reconnect the receive fiber and if applicable, reinstall the SFP in accordance
— If the alarm cleared, end this procedure. If the alarm did not clear, go
to Step 21.
23 Reconnect the receive fiber and, if applicable, reinstall the SFP in accordance
—end—

Procedure 2-153
TCM delay measurement failure
Object Class: TTP, CTP
Probable Cause: TCM DMF
NM Probable Cause: TCM DMF
NM Additional Text: Delay Measure Failure
Condition Description: TCM layer delay measurement failure
TL1 String: DMFAIL
The Delay Measurement Failure alarm is raised when the system cannot
successfully complete a requested delay measurement on a ODUk or ODUkT
with Delay Measurement enabled.


Step Action
alarm, and note the NE that displays the TCM delay measurement failure
alarm.
3 In the upstream node, select the transmitter port and verify the following:
– Ensure that no equipment alarms exist. If an equipment alarm
exists, discontinue this procedure and perform the trouble clearing
procedure for the alarmed equipment.
– Ensure that ODUk(T) is free of LOF or LTC alarms. If alarm exists,
follow the trouble clearing procedure for LOF or LTC accordingly.
– Ensure that parent layer OTUk is free of LOS, LOF or LOL alarms.
If any alarms are reported, perform the trouble clearing procedure
in accordance with internal guidelines.


—end—

Procedure 2-154
TCM LCK
Probable Cause: TCM LCK
NM Probable Cause: TCM LCK
NM Additional Text: Lock

TL1 String: TCM-LCK
A TCM-LCK alarm is raised when an TCM dLCK defect persists for 2.5 (±0.5)
seconds.


Step Action
alarm, and note the port that displays the TCM LCK alarm.
CAUTION
4 Check the upstream configuration:

— If it is in maintenance mode, remove from maintenance mode by

administratively locking the module and proceed to Step 9
— If not in maintenance mode then proceed to next step.
5 Remove fiber from module and attach to test set.
6 Monitor the corresponding TCM layer to verify if TCM-LCK alarm is reported.
7 Check signal integrity.
8 If higher level alarms exists, clear these alarms using recommended
procedure.
—end—

Procedure 2-155
TCM LOF
Probable Cause: TCM LOF
NM Probable Cause: TCM LOF
NM Additional Text: Loss of Frame, LOFLOM

unprotected status
TL1 String: LOF
The TCM Loss of Frame alarm is raised when an ODUk dLOFLOM defect
persists for 2.5 (±0.5) seconds.


Step Action
alarm, and note the port that displays the TCM LOF alarm.


action: replace SFP/XFP/CFP, LM, or equivalent.)
a transmit 5400 Switch/CoreDirector Switch port, select the port,
expand the Node Manager configuration tree, click Go >
Configuring and select the Physical TP tab, then ensure that the
port.)
LBO if not a 5400 Switch/CoreDirector Switch technology.)
Step 21.
go to Step 5.
CAUTION
CAUTION
ESD procedures.

ATTENTION
5 Remove the receive fiber in accordance with Removing and Installing an

SFP/XFP/CFP in the 5400 Switch Service Manual. Insert the receive fiber
into a test set capable of reading bit errors, as well as light level.
alarm).
12.
to Step 21.
go to Step 23.

17 Click Go > Configuring and select the Physical TP tab, then ensure that the
provisioned optical rate is correct by viewing the Configured Rate box to
ensure that the correct optical rate is selected.
Manual.
Step 22.
Manual.
—end—

Procedure 2-156
TCM LTC
Probable Cause: TCM LTC
NM Probable Cause: TCM LTC
NM Additional Text: Loss of Tandem Connection
TL1 String: TLM-LTC
A TCM Loss of Tandem Connection (LTC) alarm is raised when an TCM dLTC


Step Action
alarm, and note the port that displays the TCM LTC alarm.
4 Check the upstream configuration:
– If the requisite TCM layer is not generated or monitored at any of
the upstream peer nodes, setup TCM monitoring as per
recommended procedure.
– If the requisite TCM layer is generated or monitored at any of the
peer nodes, proceed to the next step.
5 Remove fiber from module and attach to the test set.
6 Monitor the corresponding TCM layer to verify if TCM LTC alarm is reported.

7 Check signal integrity.

8 If higher level alarms exists, clear these alarms using recommended
procedures.
—end—

Procedure 2-157
TCM OCI
Probable Cause: TCM OCI
NM Probable Cause: TCM OCI
NM Additional Text: Open Connection Indication

TL1 String: TCM-OCI
A TCM Open Connection Indication (OCI) alarm is raised when a TCM dOCI


Step Action
1 Perform the Alarm clearing procedure for the TCM LTC alarm.
—end—

Procedure 2-158
TCM TIM
Probable Cause: TCM TIM
NM Probable Cause: TCM TIM

TL1 String: TCM-TIM
A TCM TIM is a connectivity defect caused by provisioning problems within

the network. The 64-byte SM TTI string which includes the Source Access
Point Identifier (SAPI) field and Destination Access Point Identifier (DAPI) field
as specified in ITU-Y G.709, is compared to an expected identifier, and
persistent mismatches are reported.
A TCM-TIM alarm is raised when a TCM layer dTIM Mismatch defect persists
for 2.5 (±0.5) seconds.


Step Action
alarm, and note the port that displays the TCM TIM alarm.

CAUTION
3 Check if the third party upstream node is configured to transmit any TCM
trace value:
— If TCM is transmitted then disable it, by using recommended
procedure.
— If TCM is not transmitted proceed to next step.
4 Disconnect the fiber and connect to a test set.
5 Monitor the trace (SAPI, DAPI) for the configured TCM level.
— If trace is not null, then check the integrity of the signal.
— If signal reports other alarms, then clear these alarms using the
recommended procedure.
6 Disconnect fiber from test set and reconnect to module.
—end—

Procedure 2-159
Test session active
Object Class: TTP, PTP
Probable Cause: testSessionActive
NM Probable Cause: testSessionActive
NM Additional Text: Reserved for Test
Condition Description: PTP or TTP is under test
TL1 String: N/A
A Test Session Active condition is raised when a PTP or TTP is under test and
cleared when the PTP or TTP is removed from test.


Step Action
2 Click Go > Monitoring > Alarms & Events, select the Alarms tab, and note
the PPT or TTP associated with the Test session active condition.
— If power conditions are present, discontinue this procedure and
perform the TCP for the appropriate alarm.
3 Select Go > Configuring > Ptp.
4 In the List frame, select the port.
5 In the Details frame, select the Basic tab.
6 In the Status group box, select Locked from the Admin State drop-down
menu.
7 Click Accept.
8 Set the Control Status to Not Relevant and click Accept.
9 Set the Admin State to Unlocked and click Accept.


—end—

Procedure 2-160
TIM-P
Object Class: CTP
Probable Cause: Path Trace Mismatch (SONET)/Trace Mismatch (SDH)
NM Probable Cause: Path Trace Mismatch (SONET)/Trace Mismatch (SDH)
NM Additional Text: Received trace: Expected trace:
Condition Description: Path Trace Mismatch (TIM-P) detected
TL1 String:
• TIM-P (SONET)
• TIM (SDH)
A Path Trace Mismatch (TIM-P) is a connectivity defect caused by provisioning
problems (for example, incorrect cross connections) within the network. The
received Path Trace String (the J1 byte) is compared to an expected path trace
string, and persistent mismatches are reported.
The STS Path Terminating Equipment (PTE) detects a TIM-P defect within 30
seconds when none of the sampled 64 or 16 byte STS path trace strings
match the provisioned expected value. A node declares a TIM-P failure if a
TIM-P defect persists for 2.5 seconds. The TIM-P defect clears when the CTP
is administratively locked, when the path is deleted, when path trace is
administratively disabled, or if the mismatch is absent for 10 seconds.


Step Action
1 At the Node Manager workstation, launch the Node Manager (NM)

application and log on to the node.

alarm, and note the port that displays the TIM-P alarm.
CAUTION
ESD procedures.
3 Verify that the node is not provisioned with an incorrect network cross
connect.
4 Verify that the node is provisioned using the appropriate near and far end
CTPs.
5 Verify that the received STS path trace string value matches the expected
value in the CTP path trace screen.
6 Correcting the condition described in Step 3 through Step 5 should clear the
alarm. If this condition did not exist, the TIM-P alarm should clear within 30
seconds.
—end—

Procedure 2-161
Timing backup not available
Object Class: Sync PG (Node Clock only)
Probable Cause: Timing Backup Not Available
NM Probable Cause: Timing Backup Not Available
NM Additional Text: Backup timing is unavailable on <A|C>-CTM.
Condition Description: The backup timing source is failed or initializing and

is unable to provide timing for the node.
Default Severity: Major, Service affecting
TL1 String: TMGBACKUPNA
This condition is raised when the standby CTM is unable to provide timing for
the node. This condition is not raised when the standby CTM is in faststart
mode or holdover mode because these states can provide timing for the node
and are covered under the Clock mode not normal TCP.
A Timing Backup Not Available condition is raised when a source of redundant

timing information is not available for the node. This can occur because the
redundant module source of timing is not present, a redundant timing
subsystem has failed, or is in the process of initialization and is not yet
providing system timing to the backplane.
Timing Backup Not Available condition clears when a source of redundant

timing information is available for the node. Timing is considered available
while in faststart, holdover, or free-run so long as clock is provided to the
backplane for use.


Step Action

Timing backup not available alarm, and note any additional alarm
information and note any additional reported alarms In the following order:
— If any Replaceable unit missing, Replaceable unit problem, or
Replaceable unit mismatch alarms are raised against either of the
Control and Timing Modules, discontinue this procedure and perform
the associated TCP.
— If the secondary CTM is booting, wait 15 minutes, then go to Step 3.
—end—

Procedure 2-162
Timing force - lockout
Probable Cause: Timing Force - Lockout
NM Probable Cause: Timing Force - Lockout
NM Additional Text: A manual force or lockout command is active against

one or more PUs on <Sync PG Name> on <A|C>-CTM
Condition Description: The Timing Force - Lockout condition is raised due

to the activation of a manual command to force a reference switch, lockout a
reference, force holdover, or force free-run.
TL1 String: TMGFORCE
Timing Force - Lockout condition is raised due to a forced synchronization

reference selection state, a selected reference is locked out by means of
setting its priority to disabled, a forced holdover, or forced free-run.
Timing Force - Lockout condition clears when no forced reference switch,

reference lockout, forced holdover, or forced freerun is active.
The node also reports (as a default) a minor alarm when the first of one or
more concurrent or consecutive Forced Reference Switch or Lockout a
Reference commands is completed. The condition clears when all Forced
Reference Switch and/or Lockout a Reference commands have been cleared.


Step Action

alarm, and note the Timing force - lockout alarm.
3 Select Go > Administration > Timing References > Sync PG/PU.
4 In the List frame, select the PG to remove the forced or manual condition.
5 In the Details frame, select the Protection Group tab.
6 In the Operating Mode group box, select Auto from the Prefer Sync Mode
drop-down menu. (Auto mode releases a forced timing reference switch.)
7 Click Accept.
—end—

Procedure 2-163
Revertive switch (timing reference switch)
Probable Cause: Timing Reference Switch
NM Probable Cause: Timing Reference Switch
NM Additional Text: Revertive timing reference switch to <Sync Pu Name>

on <A|C>-CTM.
Condition Description: A Sync PG performs an autonomous switch to an

alternate reference with reversion enabled. This occurs on switches to any
reference with a lower priority.
TL1 String: REFSW
This condition is raised when any switch to a timing reference with a lower
priority than the currently selected reference occurs. This condition is cleared
when reversion to the highest priority level reference has completed or when
the Sych PG enters a holdover or free-run state.
In the case where the Sync PG enters a holdover or free-run state, the Timing
Reference Switch Condition clears and a Clock Mode Not Normal Condition
is raised. If the Sync PG then recovers to a lower priority PU from Holdover or
Free-run; the Timing Reference Switch condition is again raised.
Existing Timing Reference Switch Condition are cleared and a new Timing
Reference Switch Condition is raised when a switch to a timing reference with
a lower priority than the currently selected reference occurs.
The following causes the 5400 Switch to generate (as a default) an

autonomous, non-alarmed report indicating that a standing condition is active:
A switch to a secondary reference by an node that is provisioned to use
revertive reference switching.

Procedure 2-164
Non-revertive switch (timing reference switch)
Timing reference switch reporting event:
Category: Reporting event
Probable Cause: Timing Reference Switch
NM Probable Cause: Timing Reference Switch
NM Additional Text: Non-Revertive timing reference switch to <Sync Pu

Name>
Condition Description: A Sync PG performs an autonomous switch to an

alternate reference where reversion is disabled. This occurs on switches to
any reference with the same priority.
Default Severity: N/A
Type: Reporting event
TL1 String: REFSW
The System reports a Timing Reference Switch for any switch to a timing
reference with the same priority as the currently selected reference.


—end—

Procedure 2-165
Trace mismatch
Probable Cause: Section Trace (SONET)/Trace Mismatch (SDH)
NM Probable Cause: Trace Mismatch
NM Additional Text: Received trace: <rcvd_trace>. Expected: <expt_trace>
Default Severity: Dynamic (see below), Non service affecting
• Warning, NSA:
– Port has no cross-connection provisioned
– Services with unprotected status and AIS forward disabled
switch selector indicates the port
• Major:
– Services with unprotected status and AIS forward enabled, SA.
switch selector indicates the port, NSA.
TL1 String: TIM
A Trace Mismatch is a connectivity defect caused by provisioning problems

within the network. The received Trace String is compared to an expected
trace string, and persistent mismatches are reported.
The PTE detects a Trace Identifier Mismatch (TIM) defect within 30 seconds
when none of the sampled 64 or 16-byte path trace strings match the
provisioned value. The 5400 Switch declares an Trace Mismatch if a TIM
defect persists for 2.5 seconds. The TIM defect clears if it is absent for 10
seconds.



Step Action

the node.
alarm, and note the module that displays the Trace mismatch alarm.
CAUTION
3 Verify that the LTE or MSTE received trace string value matches the expected
value in the PTP section trace screen.
4 Correction of the condition from Step 3 should clear the alarm. If no condition
existed, the alarm should clear after no more than 30 seconds.
—end—

Procedure 2-166
Transmitter tuning in progress
Object Class: PTP (Tunable DWDM Only)
Probable Cause: Tuning in Progress
NM Probable Cause:
NM Additional Text: Transmitter Tuning in Progress
TL1 String: TUNING
The warning is raised when a Tunable Optical Interface is in the process of

tuning the transmitter to the provisioned wavelength.
The warning is cleared when the tuning process is competed on the Tunable
Optical Interface and the PTP is placed in Administrative Lock or ARC Lock.


No action is required. The alarm will clear upon tuning completion.
—end—

Procedure 2-167
Unavailable (SNC)
Object Class: SncOrigEpt
Probable Cause: Unavailable
NM Probable Cause: Unavailable
NM Additional Text:
• SNC cannot be re-routed

• Alarm is generated whenever there is a node or link failure while P-SNC is
working.
TL1 String: PRCDRERR
This alarm occurs when the SNC is in the creating or starting state. It is
typically caused by destination unreachable due to insufficient bandwidth, no
matching service classes, or no physical facility to the destination port.
This alarm clears when any of the following occur:
• The path defect on the CTP involved in the onset of this instance of the
condition is absent for 10 seconds. (In the composite case, this applies to
all CTPs in the GTP.)
• The SNC is deleted or locked
• The SNC or the Node Integrity Check Administrative State is set to Locked

Step Action

alarm, and note the port that displays the Unavailable (SNC) alarm and note
any additional information.
ATTENTION
If the additional information is “SNC lost during re-boot. Please delete and
re-create.”, then the problem happened due to drop side CTP being lost
during a CTM reboot. When SNC creation is done, drop side CTP can be
created by providing the port and timeslots while creating the SNC. Another
way to create the SNC is to specify the CTP or GTP name, in such a case,
the CTP or GTP has to be created before, so that SNC when created does
not give an exception.
3 If the additional information is SNC lost during re-boot. Please delete and
re-create., delete and recreate the SNC and go to Step 13; otherwise, go to
Step 4.
5 Click Provisioning and select the SNC tab. View the Provisioning SNC
screen and check the route to see whether a current route is available.
— If a current route is not available, go to Step 9.
— If a current route is available, go to Step 6.
6 View the provisioning SNC screen and note the nodes and the ports of the
home route.
application and log on to all of the 5400 Switch or CoreDirector Switch nodes
that are indicated in the home route.
8 Expand each equipment tree until the alarmed port is displayed and verify
9 Click Provisioning and select the SNC tab. At the Local End Point field click
(...) SNC State to view the Connection Status of the SNC.
10 If the status column indicates “Failed to get working route from OSRP due to
Max Admin Weight,” contact the network administrator.
11 Click Accept.
ATTENTION
Increasing the Max Admin Weight at the Connection Parameters field will
enable the SNC to take an alternate route.

12 Click Provisioning and select the SNC tab for each node. View the
Provisioning SNC screen and check to ensure that there is a valid route
(sufficient bandwidth and match the service class constraint) going to the
destination node.
— If there is a route available, go to Step 13.
— If a route is unavailable, a route must be established.
—end—

Procedure 2-168
UNEQ/UNEQ-P
Object Class: CTP (SONET and SDH)
Probable Cause: Path Unequipped (SONET)/UNEQ (SDH)
NM Probable Cause: Path Unequipped (SONET)/UNEQ (SDH)
NM Additional Text: Unequipped path
Condition Description: Unequipped path detected
TL1 String: UNEQ-P (SONET) UNEQ (SDH)
The node reports Path Unequipped failures against provisioned paths that can
transport VC-4 circuits. The node can monitor paths non-intrusively; however,
it does not normally function as path-terminating equipment. The node can
terminate a VC-4 and access the overhead, but the VC4 managed object is
not exposed to the management interface.
The UNEQ-P reported to the management interface can be for a VC-3 path
that originates from the terminated VC-4 if that port is enabled for termination
or for an unterminated VC-4 path. For the VC-3 path that originates from the
terminated VC-4, the port will be a drop side port. For the unterminated VC-4
path, the port could be any port in the 5400 network that detects the UNEQ-P.
The UNEQ-P condition clears when the UNEQ-P defect clears or the CTP is
administratively locked (if CTP administrative control is supported).


Step Action

alarm, and note the port that displays the UNEQ/UNEQ-P warning.
side equipment at the egress end of the circuit path.
—end—

Procedure 2-169
UPSR automatic switch
Object Class: MoPathSwitchingPuProxy
Probable Cause: UPSR Automatic Switch
NM Probable Cause: UPSR Automatic Switch
Condition Description: Automatic switch due to defects
Additional Text: Automatic Switch to Protect
TL1 String: WKSWPR
The system clears the Automatic Switch to Protect condition when:
• a revertive UPSR Protection Group automatically switches to protect.

• if a protection group is provisioned from non-revertive to revertive, and if it
is not on the working line at the time of the provisioning change.
• if a protection group is provisioned from revertive to non-revertive
• the target object is no longer automatically protected.

Step Action
the alarm and note the port that displays the automatic switchover condition.
– If an equipment alarm exists, discontinue this procedure and
perform the TCP for the alarmed equipment.
– If an equipment alarm does not exist, go to Step 4.

be correct. (Corrective action: replace port SFP/XFP/CFP or
equivalent with correct rate, wavelength, and reach. To check/
correct provisioned rate of a transmit 5400 Switch port, expand the
Node Manager configuration tree, select the Physical TP and
Basic tabs, and ensure that the provisioned optical rate is correct.
completed.)
or equivalent.)
– The output level of the laser (Node Manager PRTP Physical tab)
technology.)
go to Step 25.
CAUTION

CAUTION
ESD procedures.
ATTENTION
or MSTE in alarm).
14.
Step 12.
12, go to Step 14.

tabs.
selected.

—end—

Procedure 2-170
UPSR fail to switch
Probable Cause: UPSR Fail to Switch
NM Probable Cause: UPSR Fail to Switch
Condition Description: UPSR Fail to Switch
Additional Text: UPSR PU Protection Switch Selector is on : xxxxxx
The system raises a Fail to Switch condition when a UPSR protection feature
is unable to perform an automatic protection switch.
The system clears the Failure to Switch condition if the switch succeeds or if
the protection switch is no longer required because the underlying failure
cleared.


Step Action
3 Note and clear any UPSR faults: UPSR Automatic Switch To Protect, UPSR
default K byte defect, UPSR node Id mismatch or UPSR Protection Group
misconfiguration.
—end—

Procedure 2-171
UPSR manual switch to protect
Probable Cause: UPSR Manual Switch to Protect
NM Probable Cause: UPSR Manual Switch to Protect
Condition Description: UPSR Manual Switch to Protect
Additional Text: UPSR PU Protection Switch.Previous Selector : xxxxxx Current

Selector : xxxxxx
The system raises a Manual Switch to Protect condition against a UPSR

protection group when a manual switch to the protect path is initiated and the
UPSR protection feature is provisioned as revertive.
switching command.


Step Action
alarm, and note the NE that displays the UPSR manual switch to protect
warning.
3 Click Go > Protection > Line level > UPSR > Protection Unit tab and select
the protection unit identified in Step 2.

5 If there are several switched protection units in the UPSR group, under the
Go > Protection > Line Level > UPSR > Group tab, select the UPSR group
from the list.
—end—

Procedure 2-172
UPSR manual switch to working
Probable Cause: UPSR Manual Switch to Work
NM Probable Cause: UPSR Manual Switch to Work
Condition Description: UPSR Manual Switch to Work

Selector : xxxxxx
The system raises a Manual Switch to Protect condition against a UPSR

protection group when a manual switch to the working path is initiated and the
UPSR protection feature is provisioned as revertive.
switching command or when the manual switch is released.


Step Action
alarm, and note the NE that displays the UPSR manual switch to working
warning.
3 Click Go > Protection > Path level > UPSR > Protection Unit tab and select
the protection unit identified in Step 2.

6 If there are several switched protection units in the UPSR group, under the
Go > Protection > Path Level > UPSR > Group tab, select the UPSR group
from the list.
8 Click Accept.
—end—

Procedure 2-173
UPSR force switch to protect
Probable Cause: UPSR Force Switch to Protect
NM Probable Cause: UPSR Force Switch to Protect
Condition Description: UPSR Force Switch to Protect
Additional Text: UPSR PU Protection Switch.Previous Selector : xxxxxx

Current Selector : xxxxxx
The system raises a Force Switch to Protect condition against a UPSR

protection group when a force switch to the protect path is initiated.
The system clears the Force Switch to Protect condition when the manual
switching command.


Step Action
alarm and note the NE that displays the UPSR force switch to protect
alarm.
3 From the list under the Go > Protection > Path Level > UPSR > Groups tab,
select the protection unit identified inStep 2.
OKAY.

7 If there are several locked protection units in the UPSR group, from the list
under the Go > Protection > Path Level > UPSR > Group tab, select the
UPSR group.
9 Click Accept.
—end—

Procedure 2-174
UPSR force switch to work
Probable Cause: UPSR Force Switch to Work
NM Probable Cause: UPSR Force Switch to Work
Condition Description: UPSR Force Switch to Work
Additional Text: UPSR PU Protection Switch.Previous Selector : xxxxxx

Current Selector : xxxxxx
The system raises a Force Switch to Work condition against a UPSR

protection group when a force switch to the Working path is initiated.
The system clears the Force Switch to Work condition when the manual state
is cleared by management command or by a higher-priority automatic
switching command or when the force switch is released.


Step Action
alarm and note the NE that displays the UPSR force switch to work alarm.
3 From the list under the Go > Protection > Path Level > UPSR > protection
Units tab, select the UPSR protection unit identified in Step 2.
6 If there are several locked protection units in the UPSR group, from the list
under the Go > Protection > Path Level > UPSR > Group tab, select the
UPSR group.


8 Click Accept.
—end—

Procedure 2-175
UPSR lockout of protect
Probable Cause: UPSR Lockout of Protect
NM Probable Cause: UPSR Lockout of Protect
Condition Description: UPSR Lockout of Protect
NM Probable Cause: UPSR Lockout of Protect

Selector : xxxxxx
The system raises a Lockout of Protect condition against a UPSR protection

The system clears the Lockout of Protect condition when the manual state is


Step Action
alarm, and note the NE that displays the UPSR lockout of protect. alarm.
3 From the list under the Go > Protection > Path Level > UPSR > Protection Unit
tab, select the protection unit identified in Step 2.
—end—

3-1
Standards and compliance 3-
This chapter contains the following information:

• “Health and safety” on page 3-2
• “Compliance information” on page 3-2
• “Part 15 of the Federal Communications Commission (FCC): interference”
on page 3-2
• “Industry Canada notice” on page 3-3
• “C-Tick” on page 3-3
• “VCCI” on page 3-3
• “EN55022 Class A notice” on page 3-3
• “Food and Drug Administration (FDA) laser safety warning” on page 3-4
• “Class 1 laser product notice” on page 3-4
• “Environmental impact statement” on page 3-4
• “Restricted access location” on page 3-4
• “Bonding, grounding, and connections” on page 3-4
• “Toxic emissions” on page 3-5
• “Telcordia document standards” on page 3-5
• “Safety information and instructions” on page 3-5
• “Voltage precaution” on page 3-7
• “Dual connection energy level hazard” on page 3-7
• “Lift precautions” on page 3-8
• “General static electricity precautions” on page 3-9
• “Optical fiber handling precautions” on page 3-10
• “Fiber break and damaged fiber precautions” on page 3-10
• “Precautions for handling and storing modules” on page 3-10

3-2 Standards and compliance
Health and safety

The health, safety and welfare of engineers and support staff is of paramount
importance to Ciena. Implementing a safe system of work with safe people is
an integral component of our procedures and an absolute requirement under
the provisions of the Health & Safety at Work Act 1974.
Ciena recognizes the importance of all matters of Health & Safety. By suitably
addressing Health & Safety issues from the outset, engineers and operatives
are able to implement installation contract safely, smoothly and efficiently.
A comprehensive set of procedures exist to control our activities and define

our Health and Safety requirements. These are rigorously adhered to by all
Ciena employees.
Reference statements re H&SWA 1974 and Management of H&SWA

Regulations 1998. Prior to commencement of installation Supplier
representatives need to be aware of any site specific risk assessments /
processes / evacuation procedures etc.
Refer to “Safety information and instructions” on page 3-5 for additional

information.
Compliance information
• FCC Part 15 Class A US
• ICES-003 Class A Canada
• C-Tick Australia/New Zealand AN/NZS-4251
• VCCI Class A Japan
• Telcordia GR-1089-CORE NEBS Emissions and Immunity
• EN 300 386 - CE Mark (Includes 61000-4-2 ESD, 4-3 Radiated Immunity,
4-4 EFT, 4-5 Surge, 4-6 Conducted Immunity) and EN 55022 Conducted
and Radiated Emissions for all EU
• Anatel Brazil EMC approved
Part 15 of the Federal Communications Commission (FCC):

interference
This equipment has been tested and found to comply with the limits for a Class
A digital device, pursuant to part 15 of the of the FCC Rules. These limits are
designed to provide reasonable protection against harmful interference when
the equipment is operated in a commercial environment. This equipment
generates, uses and can radiate unintentional radio frequency (RF) energy
and, if not installed and used in accordance with the instruction manual, may
cause harmful interference to radio communications. Operation of this

equipment in a residential area is likely to cause harmful interference in which

case the user will be required to correct the interference at his or her own
expense.
CAUTION
Do not change or modify the device without permission from
Ciena.
If the device is changed or modified without permission from

Ciena, the user may void his or her authority to operate the
equipment.
ATTENTION
This device complies with Part 15 of the FCC Rules. Operation is subject to
the following two conditions: (1) this device may not cause harmful
interference, and (2) this device must accept any interference received,
including interference that may cause undesired operation.
Industry Canada notice

This class A digital apparatus complies with Canadian ICES-003.
Cet appareil numérique de la classe A est conforme à la norme NMB-003 du
Canada.
C-Tick
This product complies with Australian ACMA applicable standards for

EMC and Product Safety for electronic devices. All necessary compliance
documentation is held at Ciena Australia Pty, Ltd, 1 Innovation Road,
N26618 Macquarie Uni, Macquarie Park NSW 2109
VCCI
EN55022 Class A notice

This is a Class A product. In a domestic environment, this product may cause
radio interference in which case the user may be required to take adequate
measures.

Food and Drug Administration (FDA) laser safety warning

This product contains a laser diode. Ciena Corporation strongly recommends
that users and maintenance and service personnel comply with the following
standards and regulations (see Table 3-1) in the design, modification,
operation, maintenance, and service of lasers and fiber-optic devices.
Table 3-1
Standards and Regulations
Jurisdiction Type Title
Federal, US Regulation FDA 21 CFR 1040.10/.11
Federal, US Guidelines OSHA
United States Standard ANSI Z136 series
International Standard IEC 60825-1 series
European Standard EN 60825-1 series
It is further recommended that the owner of this equipment determine and

ensure conformance with any specific and applicable local regulations.
Class 1 laser product notice

The Ciena® 5400 Reconfigurable Switching System is a Class 1 Laser
Product as specified by FDA 21 CFR 1040.10, 21 CFR 1040.11, FDA Laser
Notice 50 and FDA Laser Notice 42 and EN/IEC 60825-1 Safety of Laser
Products - Equipment Classification, Requirements and User's Guide. All
laser devices incorporated in this product are FDA approved Class 1 Laser
Devices (non-modified SFPs, XFPs, CFPs and MSA commercial available,
certified, Class 1 Laser Products).
Environmental impact statement

Ciena equipment contains no hazardous materials as defined by the United
States Environmental Protection Agency (USEPA). Ciena recommends that
all failed products be returned to Ciena for failure analysis and proper
disposal.
Restricted access location

This equipment is intended for installation in a Restricted Access Location.
Bonding, grounding, and connections

WARNING: The intra-building ports of this equipment or subassembly is
suitable for connection to intra-building or unexposed cabling or wiring only.
The intra-building ports of the equipment or subassembly MUST NOT be
metallically connected to interfaces that connect to the OSP or its wiring.

These interfaces are designed for use as intra-building interfaces only (Type 2
or Type 4 ports as described in GR-1089-CORE) and require isolation from
the exposed OSP cabling. The addition of Primary Protectors is not sufficient
protection in order to connect these interfaces metallically to OSP wiring.
This product is intended for isolated dc return (DC-I) installations. The DC

return terminal is not and shall not be connected to the equipment frame or
the grounding means of the equipment.
This equipment is suitable for installation as part of the Common Bonding

Network (CBN).
This equipment is suitable for installation in Network Telecommunications

Facilities.
Toxic emissions
Ciena equipment releases no toxic emissions.
Telcordia document standards

The format and structure of this document is derived from the Telcordia
Generic Requirements for Supplier-Provided Documentation, GR-454-CORE.
Safety information and instructions

Procedures require the user to understand and follow the safety practices at
your site as well as those identified in Ciena documentation. Before applying
power and turning up any hardware, check the installation location for
adequate temperature, humidity and electrical requirements. This section
describes the electrical, physical and environmental specifications for the
5400 Switch.
• The exclamation point within an equilateral triangle is intended to alert the
user to the presence of important operating and maintenance (servicing)
instructions in the literature accompanying the product. When installing,
operating, or maintaining this equipment, basic safety precautions should
always be followed to reduce the risk of fire, electrical shock and injury to
persons.
• Use of controls or adjustments or performance of procedures other than
those specified herein may result in hazardous laser radiation exposure.
• Read and understand all instructions before executing any activity.
• Follow all warnings and instructions marked on this product.
• For information on proper mounting instructions, read the appropriate
section of this manual.

• The metallic telecommunications interface should not leave the building

premises unless connected to telecommunication devices providing
primary and secondary protection as applicable.
• This product should only be operated from the type of power source
indicated on the marking label.
• The -48VDC input terminals are only provided for installations in
Restricted Access Areas locations.
• Do not use this product near water, for example in a wet basement.
• Do not install telecommunications wiring during a lightning storm.
• Do not touch un-insulated wiring or terminals carrying direct current or
leave this wiring exposed. Protect and tape wiring and terminals to avoid
risk of fire, electric shock, and injury to service personnel.
• Do not touch uninsulated wires or terminals unless the line has been
disconnected at the network interface.
ATTENTION
Removing or opening the module covers or opening the cassette covers on
the modules voids the customer warranty.
• To reduce the risk of electrical shock, do not disassemble this product.

Trained personnel should only perform service. Opening or removing
covers and/or circuit boards may expose you to hazardous energy or other
risks. Incorrect re-assembly can cause electric shock or fire when the unit
is subsequently used.
• Ensure that there is no exposed wire when the input power cables are
connected to the unit.
• Installation must include an independent frame ground drop to building
ground.
• This equipment is to be installed only in Restricted Access Areas on
business and customer premises in accordance with Articles 110-16, 110-
18 of the National Electrical Code, ANSI/NFPA No. 70. Other installations
exempt from the enforcement of the National Electrical Code may be
engineered according to the accepted practices of the local
telecommunications utility.
• When connecting to the DC supply, a readily accessible disconnect device
shall be incorporated in the building installation wiring.

Voltage precaution
DANGER
Risk of personal injury
Negative 48 volts DC and 120 volts AC (if optional AC outlet is
installed in bottom of rack) is present in this equipment, and AC
voltages may be present in some test equipment used with this
system. Contact with these voltages can cause personal injury.
Take appropriate safety precautions.
A voltage of -48 volts DC is present in the 5400 Switch as a power source for
normal equipment operation. Depending on the facility, AC voltages are likely
present for test equipment, tools, lighting, etc. Personnel should exercise
safety precautions when connecting, measuring, and disconnecting all
voltage supply lines.
Observe the following precautions to avoid voltage shock:

• Never use both hands when working on or near a voltage source.
• Use the buddy system when working around voltage sources.
• Ensure that rescue and first aid equipment is available and accessible.
• Remove watches, rings, necklaces, and other conductive devices that
might come in contact with live voltages.
• Before activating circuits, ensure that other personnel are not in contact
with voltage sources.
• Deactivate power whenever possible before performing maintenance on
system components.
Dual connection energy level hazard

DANGER
Dual connection energy level hazard
This unit has dual power connections which supply hazardous
energy levels. Remove power from all A and B side power
feeds to de-energize this equipment.
The 5400 Switch uses a dual -48 VDC power source (typically referred to as
A-side and B-side). Each source is protected by separate circuit breakers or
fuses in the Power Distribution Unit and by separate facility Battery
Distribution Fuse Bay (BDFB) circuit breakers. Because the 5400 Switch uses
this redundant -48 VDC dual connection power configuration and is designed
to operate fully from only one -48 VDC power source, removing power from
one source (either A-side or B-side circuit breakers or fuses) does not remove
power from the other source.

When removing power from the 5400 Switch, the user must ensure that power
is removed completely from both -48 VDC sources by turning off all circuit
breakers/fuses.
Lift precautions
DANGER
Lift warning
The 5400 Switch is heavy. A 5410 Switch rack can weigh 390
lbs (177 Kg) when fully populated and 141 lbs (64 Kg) when
empty. A 5430 Switch rack can weigh 1348 lbs (613 Kg) when
fully populated and 780 pounds (354 Kg) when empty. Three
people are required to unpack and maneuver the rack.
Be very careful when moving the 5410 Switch rack around the
installation area. Until the 5410 Switch rack is installed and
secured in place, the rack is very unstable.
When lifting or handling materials manually, use only methods that ensure
personal safety and protection of the material. Never attempt to lift objects that
are too bulky or heavy to handle safely. Whenever possible, push loads
instead of pulling them. Pushing uses the strong leg muscles, whereas pulling
uses the back muscles, which can be easily strained.
Observe the following precautions when lifting an object:

• Before lifting the load, inspect the route over which the load will be carried
for obstructions or spills that could cause slipping or tripping.
• Inspect the load for sharp edges before lifting.
• Identify good hand holds on the load. These hand holds must be able to
support the full weight of the object.
• Avoid twisting or bending when lifting, and carry the load close to the body.
• When team-lifting, ensure that the load is raised at the same rate and that
it rides level to ensure that each person carries equal weight.

General static electricity precautions

CAUTION
Risk of equipment damage
Heel grounders or similar worn footwear attachments work
when the floor is designed to dissipate static electricity. If the
properties of the floor are unknown or in doubt, use a wrist-
strap and make sure it is connected to a piece of electrostatic
discharge (ESD) grounding equipment before proceeding with
any maintenance or installation activity.
A damaging static electrical charge can be generated by the rubbing and

sliding of materials against each other. Different materials have different
potentials of generating and holding a static electric charge. Plastic materials
similar to nylon and polyester are capable of generating and holding a
potentially large damaging static electricity charge. Materials similar to cotton
do not typically have the potential to generate and hold a charge. The buildup
of static electricity can be of a sufficient potential to damage electronic
circuitry. When working on Ciena equipment or any interconnecting electrical/
optical cabling, always wear an approved personnel ground device.
Industry experience has shown that all devices containing integrated circuits
can be damaged by static electricity that builds up on work surfaces and
personnel. The effect of ESD damage may be immediate failure or it may
manifest itself as a latent failure affecting the reliability of the equipment.
The static charges and discharges are produced by various charging effects
of movement and contact with other objects. Dry air allows greater static
charges to accumulate on a body.
Observe the following precautions to avoid static charges and discharges:

• Assume that all modules contain solid state electronic components that
can be damaged by ESD.
• Handle all modules by the faceplate or latch and by the top and bottom
outermost edges. Never touch the components, conductors, or connector
pins.
• When handling modules (that is, storing, installing, removing, and so forth)
or when working on the backplane, always wear a grounded wrist strap or
wear a heel strap and stand on a grounded, static-dissipating floor mat.
• Observe all warning labels on bags and cartons.
• If possible, do not remove modules from antistatic packaging until they are
ready for use.

• If possible, open all module packaging at a static-safe work station using

properly grounded wrist straps and static-dissipating table mats.
• Always store and transport modules in static-safe packaging.
• Keep all static-generating material, such as food wrappers, plastics, and
styrofoam containers, away from all modules.
• When removing modules from an enclosure, immediately place them in
static-safe packages.
• Whenever possible, maintain relative humidity above 20 percent.
Optical fiber handling precautions

When handling or connecting optical fibers, observe the following precautions:
• Always wear safety glasses when handling fibers.
• Avoid indirect eye or direct skin exposure to the ends of optical connectors
and fibers, because laser energy may be present.
• Install protective covers or caps on all fiber optical connectors when they
are not in use.
Fiber break and damaged fiber precautions

If a fiber break occurs or a damaged fiber is seen, observe the following
precautions:
• Power off all laser sources to the fiber or disconnect the fiber end from the
laser source.
• Notify the facility manager or supervisor about the damaged or broken
fiber.
• Identify where the fiber is damaged or broken.
• Be careful when handling damaged or broken optical fibers to avoid eye
injuries caused by invisible fiber fragments.
Precautions for handling and storing modules

CAUTION
Risk of damage to circuit packs and backplanes
Incorrect circuit pack installation may cause damage to the
backplane and circuit pack. Use proper installation practices.
When handling, installing, or removing modules, observe the following

precautions:
• Wear wrist straps or other suitable ESD-grounding devices before
touching and/or removing a module from the equipment shelf or ESD-
protective packaging.

• Handle modules by the faceplate only and do not touch the components,
printed circuit board, or connector contacts.
• Ensure the protective covers or caps are installed on all optical connectors
when the connectors are not in use.
• Ensure the backplane protective covers or caps are removed from the
modules before installing them in equipment shelves.
• Store all modules in suitable ESD-protective packaging when they are not
installed in an equipment shelf.
• Do not stack modules directly on or against each other.
• Store all modules in the original protective packaging container. Do not
stack modules without the use of the original protective packaging
containers.
Modules must be maintained at all times within the environmental parameters

provided in the Telcordia Generic Requirements document references listed
in Table 3-2.
Table 3-2
Environmental parameters for modules
Temperature, humidity, and Storage temperature Shock and vibration

altitude criteria
Refer to Telcordia Generic Refer to Telcordia Generic Refer to Telcordia Generic

Requirements GR-63-CORE, Requirements GR-63-CORE, Requirements GR-63-CORE,
Section 4.1 or ETSI 300019-1-3: Section 4.1.1 or ETSI 300019-1- Section 4.3 and 4.4 or ETSI
Specification T3.2 Partly 1: Specification T1.2 Weather 300019-1-2: Specification T2.3
Temperature Controlled Locations Protected, Not Temperature Public Transportation
Controlled Storage Locations

4-1
Service-affecting/nonservice-affecting
alarms 4-
5400 Switch software facility alarm reporting provides more accurate

information concerning alarm severity and the service affectability of line
alarms; Loss of Signal (LOS), Loss of Frame (LOF), Alarm Indication Signal-
Line (AIS-L), Signal Failure-Bit Error Rate (SF-BER), Signal Degradation-Bit
Error Rate (SD-BER).
Table 4-1 summarizes the software alarm behavior given factors such as the
port type, the existing traffic type, the alarm type, and whether the interface is
protected.
The first column of the table indicates the port type. The port type is either a
drop-side port or a line-side port (trunk). A Subnetwork Connection (SNC)
contains two drop-side interface ports; all of the intermediate ports of an SNC
are line-side ports. Cross connects only span two ports and, therefore, do not
contain line-side ports, only drop-side ports.
The second column of the table indicates the traffic type configured on the
interface. The traffic type can be a XCON, Permanent Subnetwork Connection
(P-SNC), SNC (or some combination), or no traffic. If multiple traffic types
exist on the interface port, the alarm SA/NSA status and severity reflects the
worst case status. For example, from the table a failed, unprotected line-side
port containing an SNC should be indicating a facility alarm as minor and non-
service-affecting. If that same port contained a P-SNC, it would indicate a
facility alarm as critical and service-affecting. If that port contained both a P-
SNC and SNC, it would indicate the facility failure as critical and service-
affecting. (In the worst case, the P-SNC could not reroute around the facility
failure.)
The column labeled Protected indicates whether another 5400 interface is

currently protecting the port. If the entry indicates yes, the interface port is
currently protected by an APS SNCP protection port. If the entry indicates no,
either the port is not configured for a protection port or the protection port is
unavailable.

4-2 Service-affecting/nonservice-affecting alarms
The event column either indicates Failed or Degraded. The term Failed means
an LOS, LOF, AIS-L, or a BER-SF has been detected. The term Degraded
means that a BER-SD (Signal Degrade) has been detected.
The last two columns indicate the resulting SA/NSA status and severity of the
alarm based upon the previously discussed parameters. This alarm indication
behavior affects only line facility alarms (LOS, LOF, AIS-L, BER-SF, and BER-
SD). It does not include any change of behavior for path alarms, cross connect
alarms, or SNC alarms.
Table 4-1
SA/NSA alarm behavior
Port type Traffic type Protected Event SA/NSA Severity
Drop No Traffic No Failed NSA Minor
Degraded NSA Minor
Yes Failed NSA Minor
Degraded NSA Minor
XCON/PSNC No Failed SA Critical
Degraded SA Major
Yes Failed NSA Major
Degraded NSA Major
SNC No Failed SA Critical
Degraded SA Major
Degraded NSA Major

Service-affecting/nonservice-affecting alarms 4-3
Table 4-1
SA/NSA alarm behavior
Port type Traffic type Protected Event SA/NSA Severity
Line No Traffic No Failed NSA Minor
Degraded NSA Minor
Yes Failed NSA Minor
Degraded NSA Minor
PSNC No Failed SA Critical
Degraded SA Major
Degraded NSA Major
SNC No Failed NSA Minor
Degraded SA Major
Degraded NSA Major
From Table 4-1, there are four input parameters that determine the SA/NSA
status and alarm severity. Because the parameters can change after the
alarm posts, 5400 Switch Baseline Software updates alarm status and
severity to reflect the change of any of the input parameters. For example, if a
cross connect is on a port that is Failed but is being protected by another port,
the facility alarm is marked as NSA and major. If after the alarm posts, the port
can no longer be protected, the facility alarm is updated to indicate SA and
critical. If at that point, the alarm condition changes from Failed to Degraded,
the facility alarm status updates to indicate SA and major. If the port can be
protected again before the alarm condition clears, the alarm status should
return to NSA and major.

4-4 Service-affecting/nonservice-affecting alarms

1
5400 Switch
alarm categories 1-2
A bay low ambient temperature 2-42

Bonding, Grounding, and Connections 3-4
AIS, See alarm indication signal (AIS)
alarm indication signal (AIS) 2-34, 2-37
AIS-P 2-27, 2-34 C
connection termination point (CTP) 2-27, 2-34 circuit pack over temperature 2-67
line 2-24, 2-182 Class 1M Laser Product Notice 3-4
multiplex section 2-24 clock mode not normal 2-70
path 2-27 communication, remote node unreachable 2-231
trail termination point (TTP) 2-24, 2-182 Compliance Information 3-2
all reference fail 2-30 Bonding, Grounding, and Connections 3-4
APS Class 1M Laser Product Notice 3-4
LAPS automatic switch to protect 2-129 C-Tick 3-3
LAPS channel mismatch 2-134 EN55022 Class A Notice 3-3
LAPS fail to switch 2-136 Environmental Impact Statement 3-4
LAPS far end protection line failure 2-137 Food and Drug Administration (FDA) Laser
LAPS forced switch to protect 2-138 Safety Warning 3-4
LAPS forced switch to work 2-140 Industry Canada Notice 3-3
LAPS invalid mode 2-142 Part 15 of the Federal Communications
LAPS lockout of protection 2-144 Commission (FCC)
LAPS lockout of working 2-145, 2-155, 2-157 Interference 3-2
LAPS manual switch to protect 2-147 Restricted Access Location 3-4
LAPS mode mismatch 2-151 Telcordia Document Standards 3-5
LAPS protection switch byte failure 2-153 Toxic Emissions 3-5
A-SNCP VCCI 3-3
automatic switch to protect 2-8 config changes inhibited 2-179
failure to switch 2-13, 2-82, 2-83 configuration mismatch 2-75
forced switch to protect 2-14 CTP
forced switch to working 2-16 alarm indication signal 2-27
lockout of protection 2-18
manual switch to protect 2-20
manual switch to working 2-22
E
EFFI 2-84
automatic switch to protect
EN55022 Class A Notice 3-3
A-SNCP 2-8
Environmental Impact Statement 3-4
LAPS 2-129
B F
failure to switch 2-109, 2-298
bay high ambient temperature 2-38, 2-40
2
A-SNCP 2-13, 2-82, 2-83 loss of signal 2-167

fan
fcc
overdriven 2-96, 2-98
M
managed element network config changes
automatic switchover 2-100
inhibited 2-179
degraded 2-104
manual switch to protect
disabled 2-106
A-SNCP 2-20
FCC forced switch to protect 2-110
FCC 2-115
FCC forced switch to working 2-112
manual switch to working
FCC manual switch to protect 2-115
A-SNCP 2-22
FCC manual switch to working 2-116
FCC 2-116
Food and Drug Administration (FDA) Laser Safety
mismatch
Warning 3-4
path trace 2-337
forced switch to protect
section trace 2-292
A-SNCP 2-14
trace 2-345
FCC 2-110
forced switch to working
A-SNCP 2-16 N
FCC 2-112 network config changes inhibited 2-179
no communication with remote node 2-231
H
health 3-1 O
one reference failed 2-268
I OSRP
CTP misconfigured admin state 2-75, 2-129, 2-
in loopback mode
134, 2-137, 2-142, 2-151, 2-153
loopback mode 2-124, 2-175
CTP misconfigured CID 2-223
Industry Canada Notice 3-3
CTP no communication with remote node 2-
input power fuse 2-126
231
OSRP remote unreachable 2-231
L
LAPS automatic switch to protect 2-129
LAPS channel mismatch 2-134
P
Part 15 of the Federal Communications
LAPS fail to switch 2-136
Commission (FCC)
LAPS far end protection line failure 2-137
Interference 3-2
LAPS forced switch to protect 2-138
path trace mismatch 2-337
LAPS forced switch to work 2-140
path unequipped 2-122, 2-260, 2-261, 2-351
LAPS invalid mode 2-142
payload defect 2-260, 2-261
LAPS lockout of protection 2-144
payload label mismatch 2-261
LAPS lockout of working 2-145, 2-155, 2-157
power
LAPS manual switch to protect 2-147
input power fuse 2-126
LAPS mode mismatch 2-151
Preface
LAPS protection switch byte failure 2-153
Compliance Information 3-2
lockout of protection
Safety Information and Instructions 3-5
A-SNCP 2-18
Trademark Acknowledgements 3-5
LOP 2-163
prerequisites 1-1
LOS 2-90, 2-167
loss of frame 2-159, 2-165
loss of pointer 2-163
3
R
RDI 2-264
rectifier failure 2-273, 2-312, 2-335
reference failed 2-268
remote node, no communication 2-231
replaceable unit missing 2-273, 2-312, 2-335
replaceable unit problem 2-276
replaceable unit type mismatch 2-271
Restricted Access Location 3-4
S
safety 3-1
Safety Information and Instructions 3-5
section trace mismatch 2-292, 2-345
T
Telcordia Document Standards 3-5
timing
all redundant sync units failed 2-30
all reference fail 2-32
clock mode not normal 2-70
force lockout 2-341
one reference failed 2-268
timing backup not available 2-339
Toxic Emissions 3-5
Trademark Acknowledgements 3-5
U
unequipped 2-122, 2-351
W
weight, 5410 Switch 3-7
weight, 5430 Switch 3-7
4
5400 Reconfigurable Switching System
Alarm And Trouble Clearing Manual
Copyright© 2010-2013 Ciena® Corporation. All rights reserved.
Publication: 009-3235-003
Revision B
Document release date: August 2013
CONTACT CIENA
For additional information, office locations, and phone numbers, please visit the Ciena
web site at www.ciena.com

009-3235-003 - (5400R2.1.2) - Alarm and Trouble Clearing - RevB PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

009-3235-003 - (5400R2.1.2) - Alarm and Trouble Clearing - RevB PDF

Uploaded by

Copyright:

Available Formats

5400 Reconfigurable Switching System

Alarm and Trouble Clearing Procedures

Corporate Headquarters 410-694-5700 or 800-921-1144 www.ciena.com

This revision supports software release 2.1.2.

5400 Reconfigurable Switching System Alarm And Trouble Clearing Manual

5400 Reconfigurable Switching System Alarm And Trouble Clearing Manual

About this document xiii

Alarm monitoring 1-1

5400 Switch alarm and trouble clearing procedures 2-1

5400 Reconfigurable Switching System Alarm And Trouble Clearing Manual

2-37 Degraded switch fabric 2-83

5400 Reconfigurable Switching System Alarm And Trouble Clearing Manual

2-87 ODU BDI 2-184

5400 Reconfigurable Switching System Alarm And Trouble Clearing Manual

2-137 Section trace mismatch 2-292

Standards and compliance 3-1

5400 Reconfigurable Switching System Alarm And Trouble Clearing Manual

Food and Drug Administration (FDA) laser safety warning 3-4

Service-affecting/nonservice-affecting alarms 4-1

5400 Reconfigurable Switching System Alarm And Trouble Clearing Manual

5400 Reconfigurable Switching System Alarm And Trouble Clearing Manual

About this document 0

This document provides a description of the Ciena® 5430 Reconfigurable

The procedures contained in this manual are intended to be performed on a

Due to the tenuous nature of performing alarm and trouble clearing

5400 Reconfigurable Switching System Alarm And Trouble Clearing Manual

• Windows® XP, Windows® NT, and Windows® 7 are registered

5400 Reconfigurable Switching System Alarm And Trouble Clearing Manual

• 5400 Reconfigurable Switching System TL1 Manual (009-3235-016)

5400 Reconfigurable Switching System Alarm And Trouble Clearing Manual

5400 Reconfigurable Switching System Alarm And Trouble Clearing Manual

About this manual

The CoreDirector Family of Multiservice Switches are hereinafter referred to

5400 Reconfigurable Switching System Alarm And Trouble Clearing Manual

– Digital optical test set usage

Environmental alarm An alarm caused by a condition relating to an enclosure in which the

Equipment alarm An alarm caused by an equipment fault.

5400 Reconfigurable Switching System Alarm And Trouble Clearing Manual

Table 1-1 (continued)

Processing error alarm An alarm caused by a software and/or processing failure.

Threshold crossing A transient alarm generated when the performance monitoring

General trouble clearing approach

In some instances, external conditions (for example, a severed fiber) cause an

If a LED is illuminated, further isolation can be accomplished opening the

5400 Reconfigurable Switching System Alarm And Trouble Clearing Manual

5400 Reconfigurable Switching System Alarm And Trouble Clearing Manual

5400 Switch alarm and trouble clearing

A-SNCP automatic switch Page 8

A-SNCP fail to switch Page 13

A-SNCP forced switch to protect Page 14

A-SNCP forced switch to working Page 16

A-SNCP lockout of protect Page 18

A-SNCP manual switch to protect Page 20

A-SNCP manual switch to working Page 22

AIS-L/MS-AIS (TTP) Page 24

AIS-P/RDI-P (CTP) Page 27

All redundant sync units failed Page 30

All references failed Page 32

Autonegotiation fail Page 37

Bay air filter(s) problem Page 38

Bay high ambient temperature Page 40

Bay low ambient temperature Page 42

BLSR automatic switch to protect Page 44