009-3288-543 - (5400 - R4.4 - FaultMgmt-Alarm) RevA

5400 Packet-Optical Platform
Fault Management - Alarm Clearing

Release 4.4
What’s inside...
New in this release and documentation roadmap
Alarm monitoring
5400 Switch alarm and trouble clearing procedures
Service-affecting/non service-affecting alarms
009-3288-543 - Standard Revision A

April 2018
Copyright© 1999-2018 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. For the most up-to-date technical publications, visit www.ciena.com.
Copyright© 1999-2018 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-CIENA-24 (243-6224)
410-865-4961
In Europe, Middle East, 800-CIENA-24-7 (800-2436-2247)
and Africa +44-207-012-5508
00 0800 77 454 (Slovenia)
In Asia-Pacific 800-CIENA-24-7 (800-2436-2247)
+81-3-6367-3989
+91-124-4340-600
120 11104 (Vietnam)
000 8004401369 (India)
In Caribbean and Latin 800-CIENA-24-7 (800-2436-2247)
America 1230-020-0845 (Chile)
009 800-2436-2247 (Colombia)
0800-77-454 (Mexico and Peru)
00 008000442510 (Panama)
Sales and General Information North America: 1-800-207-3714 E-mail: sales@ciena.com
International: +44 20 7012 5555
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-22-42419600 E-mail: sales@ciena.com
In Latin America 011-5255-1719-0220 (Mexico City) E-mail: sales@ciena.com
Training E-mail: learning@ciena.com
For additional office locations and phone numbers, please visit the Ciena web site at www.ciena.com.
5400 Packet-Optical Platform Fault Management - Alarm Clearing

Release 4.4 009-3288-543 Standard Revision A
Copyright© 1999-2018 Ciena® Corporation April 2018
READ THIS LICENSE AGREEMENT (“LICENSE”) CAREFULLY BEFORE INSTALLING OR USING CIENA
SOFTWARE OR DOCUMENTATION. THIS LICENSE IS AN AGREEMENT BETWEEN YOU AND CIENA
COMMUNICATIONS, INC. (OR, AS APPLICABLE, SUCH OTHER CIENA CORPORATION AFFILIATE
LICENSOR) (“CIENA”) GOVERNING YOUR RIGHTS TO USE THE SOFTWARE. BY INSTALLING OR USING
THE SOFTWARE, YOU ACKNOWLEDGE THAT YOU HAVE READ THIS LICENSE AND AGREE TO BE BOUND
BY IT.
1. License Grant. Ciena may provide “Software” to you either (1) embedded within or running on a hardware
product or (2) as a standalone application, and Software includes upgrades acquired by you from Ciena or a Ciena
authorized reseller. Subject to these terms, and payment of all applicable License fees including any usage-based
fees, Ciena grants you, as end user, a non-exclusive, non-transferable, personal License to use the Software only in
object code form and only for its intended use as evidenced by the applicable product documentation. Unless the
context does not permit, Software also includes associated documentation.
2. Open Source and Third Party Licenses. Software excludes any open source or third-party programs supplied
by Ciena under a separate license, and you agree to be bound by the terms of any such license. If a separate
license is not provided, any open source and third party programs are considered “Software” and their use
governed by the terms of this License.
3. Title. You are granted no title or ownership rights in or to the Software. Unless specifically authorized by Ciena in
writing, you are not authorized to create any derivative works based upon the Software. Title to the Software,
including any copies or derivative works based thereon, and to all copyrights, patents, trade secrets and other
intellectual property rights in or to the Software, are and shall remain the property of Ciena and/or its licensors.
Ciena's licensors are third party beneficiaries of this License. Ciena reserves to itself and its licensors all rights in
the Software not expressly granted to you.
4. Confidentiality. The Software contains trade secrets of Ciena. Such trade secrets include, without limitation, the
design, structure and logic of individual Software programs, their interactions with other portions of the Software,
internal and external interfaces, and the programming techniques employed. The Software and related technical
and commercial information, and other information received in connection with the purchase and use of the
Software that a reasonable person would recognize as being confidential, are all confidential information of Ciena
(“Confidential Information”).
5. Obligations. You shall:
i) Hold the Software and Confidential Information in strict confidence for the benefit of Ciena using your best efforts
to protect the Software and Confidential Information from unauthorized disclosure or use, and treat the Software
and Confidential Information with the same degree of care as you do your own similar information, but no less than
reasonable care;
ii) Keep a current record of the location of each copy of the Software you make;
iii) Use the Software only in accordance with the authorized usage level;
iv) Preserve intact any copyright, trademark, logo, legend or other notice of ownership on any original or copies of
the Software, and affix to each copy of the Software you make, in the same form and location, a reproduction of the
copyright notices, trademarks, and all other proprietary legends and/or logos appearing on the original copy of the
Software delivered to you; and
v) Issue instructions to your authorized personnel to whom Software is disclosed, advising them of the confidential
nature of the Software and provide them with a summary of the requirements of this License.
6. Restrictions. You shall not:
i) Use the Software or Confidential Information a) for any purpose other than your own internal business purposes;
and b) other than as expressly permitted by this License;
ii) Allow anyone other than your authorized personnel who need to use the Software in connection with your rights
or obligations under this License to have access to the Software;
iii) Make any copies of the Software except such limited number of copies, in machine readable form only, as may
be reasonably necessary for execution in accordance with the authorized usage level or for archival purposes only;
iv) Make any modifications, enhancements, adaptations, derivative works, or translations to or of the Software;
v) Reverse engineer, disassemble, reverse translate, decompile, or in any other manner decode the Software;
vi) Make full or partial copies of the associated documentation or other printed or machine-readable matter provided
with the Software unless it was supplied by Ciena in a form intended for reproduction;
vii) Export or re-export the Software from the country in which it was received from Ciena or its authorized reseller
unless authorized by Ciena in writing; or

viii) Publish the results of any benchmark tests run on the Software.
7. Audit: Upon Ciena's reasonable request you shall permit Ciena to audit the use of the Software to ensure
compliance with this License.
8. 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 Software and any accompanying technical
data (collectively “Materials”) are commercial within the meaning of applicable Federal acquisition regulations. The
Materials were developed fully at private expense. U.S. Government use of the Materials is restricted by this
License, and all other U.S. Government use is prohibited. In accordance with FAR 12.212 and DFAR Supplement
227.7202, the Software is commercial computer software and the use of the Software is further restricted by this
License.
9. Term of License. This License is effective until the applicable subscription period expires or the License is
terminated. You may terminate this License by giving written notice to Ciena. This License will terminate
immediately if (i) you breach any term or condition of this License or (ii) you become insolvent, cease to carry on
business in the ordinary course, have a receiver appointed, enter into liquidation or bankruptcy, or any analogous
process in your home country. Termination shall be without prejudice to any other rights or remedies Ciena may
have. Upon any termination of this License you shall destroy and erase all copies of the Software in your
possession or control, and forward written certification to Ciena that all such copies of Software have been
destroyed or erased. Your obligations to hold the Confidential Information in confidence, as provided in this License,
shall survive the termination of this License.
10. Compliance with laws. You agree to comply with all laws related to your installation and use of the Software.
Software is subject to U.S. export control laws, and may be subject to export or import regulations in other
countries. If Ciena authorizes you to import or export the Software in writing, you shall obtain all necessary licenses
or permits and comply with all applicable laws.
11. Limitation of Liability. ANY LIABILITY OF CIENA SHALL BE LIMITED IN THE AGGREGATE TO THE
AMOUNTS PAID BY YOU TO CIENA OR ITS AUTHORIZED RESELLER 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 LICENSOR OF
CIENA. NEITHER CIENA NOR ANY OF ITS LICENSORS 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.
12. General. Ciena may assign this License to an affiliate or to a purchaser of the intellectual property rights in the
Software. You shall not assign or transfer this License or any rights hereunder, and any attempt to do so will be void.
This License shall be governed by the laws of the State of New York without regard to conflict of laws provisions.
The U.N. Convention on Contracts for the International Sale of Goods shall not apply hereto. This License
constitutes the complete and exclusive 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.

i
Publication history 0
April 2018
Standard Revision A.
This is the first standard release of this document for software release 4.4.

ii Publication history

iii
Contents 0
Publication history i
About this document ix
New in this release and documentation roadmap xi
Alarm monitoring 1-1

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

Ciena return material authorization (RMA) procedure 2-10
Using the ACO switch to turn off an alarm 2-12
Clearing TCM CTP PM Invalid Flag 2-13
CTM Control Plane Restart 2-15
LM Control Plane Restart 2-19
A-SNCP automatic switch 2-21
A-SNCP fail to revert 2-26
A-SNCP fail to switch 2-27
A-SNCP forced switch to protect 2-28
A-SNCP forced switch to working 2-30
A-SNCP lockout of protect 2-32
A-SNCP manual switch to protect 2-33
A-SNCP manual switch to working 2-35
Adjacency discovery unreliable 2-37
AIS-L/MS-AIS (TTP) 2-39
AIS-P/RDI-P (CTP) 2-42
All provisioned external authentication servers unavailable 2-45
All redundant sync units failed 2-47
All references failed 2-49
AU-AIS 2-51
Auto-revert window active 2-54
Autonegotiation fail 2-55
Bay air filter(s) problem 2-56
Bay high ambient temperature 2-58
Bay low ambient temperature 2-60

iv Contents
BLSR automatic switch to protect 2-62

BLSR default k-bytes defect 2-67
BLSR force switch to protect 2-69
BLSR improper APS codes 2-70
BLSR inconsistent APS codes 2-73
BLSR lockout of protect 2-75
BLSR lockout of work 2-76
BLSR manual switch to protect 2-77
BLSR node id mismatch 2-78
BLSR protection degrade condition 2-81
BLSR protection group misconfiguration 2-82
Channel contention 2-84
Chassis IDP Failed 2-86
Circuit pack over temperature 2-87
Clock mode not normal 2-91
Communications subsystem conflict 2-94
Configuration mismatch 2-96
Co-routed SNC is degraded 2-98
Co-routed SNC is unavailable 2-99
DC power failed 2-100
DCN interface link failure 2-103
Degraded switch fabric 2-104
DPanel mismatch 2-105
Duplicate adjacency discovered 2-107
ESLM audit mismatch 2-108
ESLM card in Hold 2-109
Ethernet failure indication condition (Ethernet LFI) 2-110
Ethernet forward fault indication 2-111
Ethernet-LOF 2-113
Ethernet-LOS 2-118
Ethernet-RFI 2-123
External authentication server unavailable 2-125
Expansion switch link down 2-127
Fabric Upgrade In-Progress 2-129
Fan overdriven 2-130
Fan speed mismatch 2-132
FCC automatic switch 2-134
FCC fail to revert 2-139
FCC fail to switch 2-140
FCC forced switch to protect 2-141
FCC forced switch to working 2-143
FCC lockout of protect 2-145
FCC manual switch to protect 2-146
FCC manual switch to working 2-147
FEC type mismatch 2-149
Firmware mismatch 2-150
FPGA SEU event 2-152
Generic AIS 2-153
GFP Loss of frame delineation 2-154
GFP UPI mismatch 2-156

Contents v
HIBER 2-158
High temperature 2-159
In loopback condition 2-163
In loopback mode 2-164
Input power fuse 2-165
Intrusion detection 2-167
Last authentication key expired 2-168
LAPS automatic switch to protect 2-170
LAPS channel mismatch 2-175
LAPS far end protection line failure 2-177
LAPS forced switch to protect 2-178
LAPS forced switch to working 2-180
LAPS invalid APS mode 2-182
LAPS lockout of protection 2-184
LAPS lockout of working 2-185
LAPS manual switch to protect 2-186
LAPS manual switch to working 2-188
LAPS mode mismatch 2-190
LAPS protection switch byte failure 2-192
Laser frequency out of range 2-194
LCH 2-195
Line Flapping 2-197
LOC 2-199
LOF 2-201
LOP 2-206
Loss of multi-frame indication 2-208
Loss of lane alignment 2-209
Loss of PCS 2-210
LOS 2-212
LSC 2-217
Maximum discovered route limit reached 2-222
NDP configuration mismatch condition 2-223
NDP adjacency down 2-224
NDP duplicate subtended neighbor condition 2-226
Network configuration changes inhibited 2-227
Nodes per area exceeded 2-228
NTP server connection failed 2-230
ODU AIS 2-235
ODU BDI 2-237
ODU DEG 2-239
ODU LCK 2-244
ODU LOF 2-245
ODU OCI 2-250
ODU PLM 2-252
ODU TIM 2-254
Operation out of spec 2-256
OPR channel out of range 2-258
OPR channel power high 2-260
OPR out-of-range 2-261
OPR power high 2-262

vi Contents
Optical trace mismatch (TR control) 2-263

OPU CSF 2-264
OPU MSI mismatch 2-266
OSI communications failure 2-267
OSPF adjacency down 2-269
OSPF backplane IP address conflict condition 2-270
OSRP advertised bandwidth mismatch condition 2-271
OSRP concatenation mismatch condition 2-273
OSRP CTP bandwidth locked 2-275
OSRP CTP misconfigured bandwidth lockout 2-276
OSRP CTP misconfigured OVPN ID 2-277
OSRP link ID mismatch condition 2-278
OSRP LTP misconfigured BW thresholds 2-279
OSRP LTP oversubscribed 2-280
OSRP misconfigured admin state condition 2-282
OSRP misconfigured CID condition 2-283
OSRP misconfigured condition 2-285
OSRP misconfigured node name condition 2-287
OSRP OVPN ID mismatch conditions 2-289
OSRP port capability mismatch 2-290
OSRP remote unreachable condition 2-291
OTU AIS 2-293
OTU BDI 2-295
OTU DEG 2-297
OTU LOF 2-302
OTU LOL 2-307
OTU PFSD 2-312
OTU PFSF 2-317
OTU TIM 2-322
Out-of-range 2-324
PDI-P 2-325
PDU mismatch 2-326
PLM-P 2-328
Power in reduction state 2-329
PPPCommunicationConflict 2-330
PPPCommunicationFailure 2-333
Provisioning mismatch 2-336
Provisioning required 2-338
RDI/MS-RDI 2-340
Remote nodes per system exceeded 2-342
Reference failed 2-344
Replaceable unit type mismatch 2-348
Replaceable unit missing 2-351
Replaceable unit problem 2-354
SDCC/LDCC 2-367
SD/SF 2-368
SD-P/SF-P 2-373
Secondary CTM initializing 2-374
Section trace mismatch 2-375
Signaled SNCP automatic switch 2-377

Contents vii
Signaled SNCP fail to switch 2-382

Signaled SNCP fail to revert 2-383
Signaled SNCP forced switch to protect 2-384
Signaled SNCP forced switch to working 2-386
Signaled SNCP lockout of protection 2-387
Signaled SNCP manual switch to protect 2-388
Signaled SNCP manual switch to working 2-389
SNC fail to revert 2-391
SNC home path not defined 2-392
SNC manual regroom status 2-394
SNC resize status 2-395
SNC restored using preemption 2-396
SNC reverse path setup failure 2-397
SPLI loopback test active 2-398
Superuser logged in 2-399
TAP connection active 2-400
TC-AIS 2-401
TC-LTC 2-402
TC-RDI 2-403
TCM AIS 2-404
TCM BDI 2-406
TCM DEG 2-409
TCM delay measurement failure 2-414
TCM LCK 2-415
TCM LOF 2-417
TCM LTC 2-422
TCM OCI 2-424
TCM TIM 2-425
Test session active 2-427
TIM-P 2-428
Timing backup not available 2-430
Timing force - lockout 2-432
TODR-DOW reversion inhibited 2-434
TTI Mismatch Condition 2-436
Revertive switch (timing reference switch) 2-438
Non-revertive switch (timing reference switch) 2-439
Trace mismatch 2-440
Transmit mismatch 2-442
Transmitter tuning in progress 2-443
Unavailable (SNC) 2-444
UNEQ/UNEQ-P 2-447
UPSR automatic switch 2-449
UPSR fail to switch 2-454
UPSR manual switch to protect 2-455
UPSR manual switch to working 2-457
UPSR force switch to protect 2-459
UPSR force switch to work 2-461
UPSR lockout of protect 2-463
VLSR default k-bytes defect 2-464

viii Contents
Service-affecting/non service-affecting alarms 3-1

ix
About this document 0
This document provides 5400 Packet-Optical Platform R4.3 Fault

Management Alarm Clearing procedures.
Trademark Acknowledgments
• Ciena® is a registered trademark of Ciena Corporation.
• Cisco® is a registered trademark of Cisco.
• Juniper Networks, the Juniper Networks logo, JUNOS, Steel-Belted
Radius, NetScreen, and ScreenOS are registered trademarks of Juniper
Networks, Inc. in the United States and other countries. JUNOSe is a
trademark of Juniper Networks, Inc.
• UNIX® is a registered trademark licensed exclusively through X/Open
Company, Ltd.
Intended Audience
This document is intended for certified system installation technicians, test
engineers, network operations center, and technical support personnel
responsible for configuration. All personnel are required to read, understand,
and observe the safety precautions described in the appropriate product
manuals.
Release Notes and Document Updates

This document is revised at major releases and, therefore, may not always
contain the latest product information. As needed, customer Release Notes
(RNs) are provided for all releases to describe any new information or
document changes.
The latest online version of this document and all release notes can be
accessed on the Ciena web site at http://www.ciena.com.
Related Documentation
Additional supporting documentation is available through the Ciena web site
at http://www.ciena.com.

x About this document
The following list contains the names of the related documents in the suite:
• System Description (009-3288-100)
• 5430 Hardware Installation (009-3288-201.1)
• 5410 Hardware Installation (009-3288-201.2)
• 5430 15Tb Upgrade (009-3288-201.3)
• 5430 PDU Upgrade (009-3288-201.4)
• 5410 5Tb Upgrade (009-3288-201.5)
• Commissioning and Testing (009-3288-221)
• TL-1 Description (009-3288-190)
• Node Manager Fundamentals (009-3288-195)
• Administration and Security (009-3288-301)
• Configuration - Provisioning and Operating (009-3288-310)
• Configuration - Bandwidth and Data Services (009-3288-320)
• Configuration - Control Plane (009-3288-330)
• Fault Management - Performance Monitoring (009-3288-520)
• Fault Management - Alarm Clearing (009-3288-543)
• Fault Management - Module Replacement (009-3288-545)
• SAOS Command Reference (009-3288-610)
• SAOS Configuration (009-3288-630)
• SAOS Event Reference (009-3288-650)
• SAOS MPLS Configuration (009-3288-670)
• SAOS MIB Reference (009-3288-690)
Document Ordering Information

To order additional documentation, the user can contact the local sales
representative or Ciena through the contact numbers and/or e-mail addresses
listed after the front cover.
Document Comments
Ciena appreciates all comments that help us to improve our documentation
quality. The user can submit comments through the Ciena web site at http://
www.ciena.com.
Additional Product Information

Additional product information can be obtained by contacting the local sales
representative or Ciena through the contact numbers and/or e-mail addresses
listed after the front cover.

xi
New in this release and documentation

roadmap 0
This Technical Publication supports 5400 Packet-Optical Platform (5400)

Release 4.4 software.
R4.4 Draft Issue 2

The following alarms and procedures are added in this release:
• Clearing TCM CTP PM Invalid Flag
• Channel contention
• ESLM audit mismatch
• ESLM card in Hold
• High temperature
• Power in reduction state
Documentation Roadmap
The following roadmap illustrates the structure of the 5400 technical
publications library.

xii New in this release and documentation roadmap

1-1
Alarm monitoring 1-
About this manual

This manual is organized in chapters that 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® XP, Windows® NT, and Windows® 7, or UNIX
operating systems)

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 5400 Packet-Optical Platform Fault-
Management - Module Replacement.
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
(OneControl Unified Management System and 5400 Node Manager). This
chapter describes basic alarm monitoring using:
• 5400 Node Manager- refer to 5400 Packet-Optical Platform Node

Manager Fundamentals as required
• 5400 Switch controls and indicators- refer to 5400 Packet-Optical Platform
System Description as required

Alarm monitoring 1-3
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.
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 OneControl Unified
Management System 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.

1-4 Alarm monitoring
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).
After diagnosing the problem, the craft technician refers to the appropriate
maintenance procedure.
ATTENTION
Clear alarms in order of severity. Clear all Critical alarms first, then clear all
Major alarms, and then clear all minor alarms.
ATTENTION
“Service-affecting/non service-affecting alarms” on page 3-1, provides
additional information.

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.
Related alarm clearing procedures:

• Ciena return material authorization (RMA) procedure
• Using the ACO switch to turn off an alarm
• Clearing TCM CTP PM Invalid Flag
Table 2-1
5400 Switch Alarms
Alarm
A-SNCP automatic switch
A-SNCP fail to revert
A-SNCP fail to switch
A-SNCP forced switch to protect
A-SNCP forced switch to working
A-SNCP lockout of protect
A-SNCP manual switch to protect
A-SNCP manual switch to working
Adjacency discovery unreliable
AIS-L/MS-AIS (TTP)
AIS-P/RDI-P (CTP)
All provisioned external authentication servers unavailable
All redundant sync units failed

2-2 5400 Switch alarm and trouble clearing procedures
Table 2-1
5400 Switch Alarms (continued)
Alarm
All references failed
AU-AIS
Auto-revert window active
Autonegotiation fail
Bay air filter(s) problem
Bay high ambient temperature
Bay low ambient temperature
BLSR automatic switch to protect
BLSR default k-bytes defect
BLSR force switch to protect
BLSR improper APS codes
BLSR inconsistent APS codes
BLSR lockout of protect
BLSR lockout of work
BLSR manual switch to protect
BLSR node id mismatch
BLSR protection degrade condition
BLSR protection group misconfiguration
Channel contention
Chassis IDP Failed
Circuit pack over temperature
Clock mode not normal
Communications subsystem conflict
Configuration mismatch
Co-routed SNC is degraded
Co-routed SNC is unavailable
DC power failed

Table 2-1
Alarm
DCN interface link failure
Degraded switch fabric
DPanel mismatch
Duplicate adjacency discovered
ESLM audit mismatch
ESLM card in Hold
Ethernet failure indication condition (Ethernet LFI)
Ethernet forward fault indication
Ethernet-LOF
Ethernet-LOS
Ethernet-RFI
External authentication server unavailable
Expansion switch link down
Fabric Upgrade In-Progress
Fan overdriven
Fan speed mismatch
FCC automatic switch
FCC fail to revert
FCC fail to switch
FCC forced switch to protect
FCC forced switch to working
FCC lockout of protect
FCC manual switch to protect
FCC manual switch to working
FEC type mismatch
Firmware mismatch
FPGA SEU event

Table 2-1
Alarm
Generic AIS
GFP Loss of frame delineation
GFP UPI mismatch
HIBER
High temperature
In loopback condition
In loopback mode
Input power fuse
Intrusion detection
Last authentication key expired
LAPS automatic switch to protect
LAPS channel mismatch
LAPS far end protection line failure
LAPS forced switch to protect
LAPS forced switch to working
LAPS invalid APS mode
LAPS lockout of protection
LAPS lockout of working
LAPS manual switch to protect
LAPS manual switch to working
LAPS mode mismatch
LAPS protection switch byte failure
Laser frequency out of range
LCH
Line Flapping
LOC
LOF

Table 2-1
Alarm
LOP
Loss of multi-frame indication
Loss of lane alignment
Loss of PCS
LOS
LSC
Maximum discovered route limit reached
NDP configuration mismatch condition
NDP adjacency down
NDP duplicate subtended neighbor condition
Network configuration changes inhibited
Nodes per area exceeded
NTP server connection failed
ODU AIS
ODU BDI
ODU DEG
ODU LCK
ODU LOF
ODU OCI
ODU PLM
ODU TIM
Operation out of spec
OPR channel out of range
OPR channel power high
OPR out-of-range
OPR power high
Optical trace mismatch (TR control)

Table 2-1
Alarm
OPU CSF
OPU MSI mismatch
OSI communications failure
OSPF adjacency down
OSPF backplane IP address conflict condition
OSRP advertised bandwidth mismatch condition
OSRP concatenation mismatch condition
OSRP CTP bandwidth locked
OSRP CTP misconfigured bandwidth lockout
OSRP CTP misconfigured OVPN ID
OSRP link ID mismatch condition
OSRP LTP misconfigured BW thresholds
OSRP LTP oversubscribed
OSRP misconfigured admin state condition
OSRP misconfigured CID condition
OSRP misconfigured condition
OSRP misconfigured node name condition
OSRP OVPN ID mismatch conditions
OSRP port capability mismatch
OSRP remote unreachable condition
OTU AIS
OTU BDI
OTU DEG
OTU LOF
OTU LOL
OTU PFSD
OTU PFSF

Table 2-1
Alarm
OTU TIM
Out-of-range
PDI-P
PDU mismatch
PLM-P
Power in reduction state
PPPCommunicationConflict
PPPCommunicationFailure
Provisioning mismatch
Provisioning required
RDI/MS-RDI
Remote nodes per system exceeded
Reference failed
Replaceable unit type mismatch
Replaceable unit missing
Replaceable unit problem
SDCC/LDCC
SD/SF
SD-P/SF-P
Secondary CTM initializing
Section trace mismatch
Signaled SNCP automatic switch
Signaled SNCP fail to switch
Signaled SNCP fail to revert
Signaled SNCP forced switch to protect
Signaled SNCP forced switch to working
Signaled SNCP lockout of protection

Table 2-1
Alarm
Signaled SNCP manual switch to protect
Signaled SNCP manual switch to working
SNC fail to revert
SNC home path not defined
SNC manual regroom status
SNC resize status
SNC restored using preemption
SNC reverse path setup failure
SPLI loopback test active
Superuser logged in
TAP connection active
TC-AIS
TC-LTC
TC-RDI
TCM AIS
TCM BDI
TCM DEG
TCM delay measurement failure
TCM LCK
TCM LOF
TCM LTC
TCM OCI
TCM TIM
Test session active
TIM-P
Timing backup not available
Timing force - lockout

Table 2-1
Alarm
TODR-DOW reversion inhibited
TTI Mismatch Condition
Revertive switch (timing reference switch)
Non-revertive switch (timing reference switch)
Trace mismatch
Transmit mismatch
Transmitter tuning in progress
Unavailable (SNC)
UNEQ/UNEQ-P
UPSR automatic switch
UPSR fail to switch
UNEQ/UNEQ-PA-SNCP forced switch to protect
UPSR manual switch to working
UPSR force switch to protect
UPSR force switch to work
UPSR lockout of protect
VLSR default k-bytes defect
ATTENTION
Maintenance procedures are located in 5400 Packet-Optical Platform Fault

Procedure 2-1
Ciena return material authorization (RMA) procedure
Overview
This procedure describes how to obtain a Ciena Return Material Authorization
(RMA) number and how to return a defective item to Ciena.
Required tools
• ESD-guard wrist strap
• ESD-guard heel grounders
• Common hand tools
• Anti-static bag or anti-static box
Prerequisites
• Collect hardware related alarm additional text information.
• The user must use proper module handling procedures. When handling,
installing, or removing modules, the following precautions must be
observed.
— Ensure modules are stored in ESD-protective packaging when not
installed in an equipment shelf.
— Do not stack modules on or against each other.
— Pick up modules by the front handle, and do not touch components on
the circuit board.
• An anti-static bag or box must be available for the removed module.
Referenced documents
• None

Procedure
CAUTION
Risk of damage to circuit packs/modules
This equipment contains Electrostatic Discharge (ESD)
sensitive devices. Wear grounding straps when handling
equipment and follow ESD procedures.
ATTENTION
All returned equipment must have a Ciena RMA number. Ciena is not
responsible for any item returned without this identifier.
Step Action
1 Go to the Ciena Support website http://www.ciena.com/support/ and have the

following information available:
a. Serial Number
b. Site ID (If applicable)
c. PO Number (If applicable)
d. Customer Contact
e. Contact Phone Number
f. Problem Description
— What was the nature of the failure?
— How was the failure detected/verified?
— Approximately how long was the module running prior to failure?
ATTENTION
Ciena assigns an RMA number, which is used to track the defective item. The
replacement item will be shipped to the customer, based upon the terms of
the Customer Contract for Warranty (repair or replace).
2 After the replacement item has been unpacked and installed, reuse the
shipping container,packing materials, and optical dust caps to return the
defective item to Ciena.
3 Affix the preprinted air bill to the shipping container.
4 Arrange for the shipper to collect the shipping container.
—end—

Procedure 2-2
Using the ACO switch to turn off an alarm
Overview
This procedure describes how to turn off an audible alarm using the Alarm
Cut-Off (ACO) switch on the 5430 Switch display module or 5410 CTM. The
ACO switch enables a craftsperson to silence an audible alarm at the node.
The ACO switch does not inhibit any other visible indication of the alarm.
Furthermore, all subsequent alarms (including audible alarms) continue to be
monitored and processed.
Required tools
Prerequisites
• The facility containing the 5400 Switch must be equipped with an audible
alarm that is connected to the 5400 Switch.
• None
Procedure
CAUTION
Step Action
1 At the 5430 Switch display module or 5410 Switch CTM, press and
momentarily hold ACO (alarm cut off) to trigger LED test. All led will transition
between their colors for about a minute. No report is generated. No alarms
are raised. LED inspection is visual only.
2 Press the ACO/LED button and the blue light indicates to immediately silence
audible alarms. When all minor, major and critical alarms are cleared then the
blue light will clear.
—end—

Procedure 2-3
Clearing TCM CTP PM Invalid Flag
Overview
The Node Manager TCM CTP Real Time Stats screen has an Invalid Data
flag. The Invalid Data flag turns red indicating the value of the counter is not
valid for the entire interval.
• During mesh restorations, the terminating node SNC and TCM CTP are
deleted. On the originating node, the TCM CTP does not get deleted and
TCM CTP stays valid. The originating node TCM CTP's far end and
terminating Node's Near/Far end are marked as invalid due to deletion/
creation of TCM object on the Terminating node.
• When collected PM data counters are reset to initial value of zero for a
current accumulation period the data for that period is declared invalid and
the invalid data flag is red.
• When the data collection begins after the start of a collection period, the
data for that collection period is declared invalid and the invalid data flag
is red.
Category: Standing condition
Object Class: TCMCTP
Default severity: There is no alarm indication however, the Invalid Data flag
turns from grey to red when data is invalid.
Procedure
Step Action
1 If the Invalid Data flag is set at the near end, check for and clear the following:
• TCM is in SSF
• TCM is in Dependency
• TIM is present with action enabled
Note: During mesh restorations, the Invalid Data flag is set if any of the above
conditions are present.

2 If the Invalid Data flag is set at the far end, check for and clear the following:
• TCM defect present (AIS,LCK,LTC,OCI,TIM with action enabled)
• TCM is in SSF
• TCM is in dependency
• ODUk CTP does not have an associated active cross connect
Note: During mesh restorations, the Invalid Data flag is set due to deletion
and recreation of far end cross connect.
—end—

Procedure 2-4
CTM Control Plane Restart
Overview
This procedure describes how to control plane restart the primary or
secondary CTM. The CTM control plane restart restarts the upper-layer
software only (core_xx, cesd-xxxx, etc.). The timing plane and traffic are
unaffected.
Required tools
The following are required for all installations:
• Personal Computer (PC) or laptop computer running Windows®
• HyperTerminal available on PC
• File Transfer Protocol (FTP) software
• FTP server PC for storing database backup files
The following are required when the procedure is performed at the NE:
• Serial cable for connection to the CTM. The RJ-45 to sub-D 9 pin cable is
configured for Data Terminal Equipment (DTE) or USB to serial adapter.
Prerequisites
• Disable firewalls on the FTP server or the file transfer will not work.
• Craft Interface personnel must be registered system users with valid user
names and passwords to log on to the Command Line Interface (CLI).
• Craft Interface personnel must have knowledge in the use, setup, and
configuration of HyperTerminal software.
configuration of FTP software on the FTP server.
• Setup the FTP server with the default user name and password
(anonymous).
• None.

Procedure
CAUTION
ATTENTION
If the upgrade is performed from the OneControl workstation, refer to the
OneControl software documentation and perform the OneControl Software
Backup on Demand (Manual) procedure.
Step Action
Connect to 5400 Switch

1 Connect to the 5400 Switch in one of the following ways:
a. Connect a cable from the CNSL port on the CTM to the laptop, and start
a HyperTerminal program.
b. From the laptop, launch a Telnet session to the 5400 Switch virtual
Internet Protocol (IP) address from the Windows Start menu, as follows:
— Select Run.
— Type telnet <5430 IP address>.
— Press Enter.
The CLI Login prompt is displayed.
2 Log on to the 5430 CLI at an administrator level. The default user name is
superuser and the default password superuser1!
3 If required, select the option to return to the CLI Menu.
The Maintenance menu is displayed.
—continued—

Procedure 2-4 (continued)

Step Action
Figure 2-1
Maintenance menu
---------------------------------------------------------
---- CIENA 5400 ----
---- MAINTENANCE MENU ----
---------------------------------------------------------
---- 1 Display system configuration
---- 2 Display module status
---- 3 Upgrade or revert software release
---- 4 Backup database
---- 5 Restore database
---- 6 Perform system operations
---- 7 Modify system configuration
---- 10 Log off
---------------------------------------------------------
1-A-CTM:P> (rel_cn5430_3.0.1.0_cl634166, 5430-SVT-a64)
Enter Choice (? for help): ?
4 At the Maintenance menu type the option number to Perform system

operations and press Enter.
The Operations menu (Figure 2-2) is displayed.
—continued—


Step Action
Figure 2-2
Operations menu
-------------------------------------------------------------
---- CIENA 5400 ----
---- OPERATIONS MENU ----
-------------------------------------------------------------
---- 1 List Module status
---- - - - - - - - - - - - - - - - - - - - - - - - - - -
---- 2 Control Plane Restart a CTM
---- 3 Control Plane Restart an LM
---- - - - - - - - - - - - - - - - - - - - - - - - - - -
---- 4 Control Plane Reset the Primary CTM
---- 5 Control Plane Reset the Secondary CTM
---- 6 Control Plane Reset an LM
---- - - - - - - - - - - - - - - - - - - - - - - - - - -
---- 8 Full Reset the Primary CTM
---- 9 Full Reset the Secondary CTM
---- 10 Full Reset an LM
---- 11 Full Reset a SM
---- 12 Full Reset a CFU
---- - - - - - - - - - - - - - - - - - - - - - - - - - -
---- 14 Interrupt Backup or Restore Operations
---- 15 Service and Port Lock Config Menu
---- - - - - - - - - - - - - - - - - - - - - - - - - - -
---- 16 Telnet TLS Server Certificate Menu
---- 17 HTTPS Client Certificate Menu
---- 18 Security Log TLS Server Certificate Menu
---- 19 Security Log TLS Server Key Menu
---- 20 LDAP Client Certificate Menu
---- 21 LDAP CA Certificate Menu
---- 22 LDAP Client Key Menu
---- - - - - - - - - - - - - - - - - - - - - - - - - - -
---- 23 Support Menu
---- 24 Return to CTM CLI Menu
------------------------------------------------------------
1-A-CTM:P> (rel_cn5430_3.0.1.0_cl634166, 5430-SVT-a64)
Enter Choice (? for help): ?
5 At the Operations menu type the option number to Control Plane Restart a
CTM and press Enter.
Enter CTM to control plane restart: is displayed.
6 Type 1-A-CTM or 1-C-CTM (5430 Switch) or 1-A-CTM1or 1-A-CTM2 (5410
Switch).
—end—

Procedure 2-5
LM Control Plane Restart
Overview
This procedure describes how to control plane restart the a LM. The LM
control plane restart restarts the upper-layer software only (core_xx, cesd-
xxxx, etc.). The data plane and traffic are unaffected.
Required tools
The following are required for all installations:
• Personal Computer (PC) or laptop computer running Windows®
• HyperTerminal available on PC
• File Transfer Protocol (FTP) software
• FTP server PC for storing database backup files
The following are required when the procedure is performed at the NE:
• Serial cable for connection to the CTM. The RJ-45 to sub-D 9 pin cable is
configured for Data Terminal Equipment (DTE) or USB to serial adapter.
Prerequisites
• Disable firewalls on the FTP server or the file transfer will not work.
• Craft Interface personnel must be registered system users with valid user
names and passwords to log on to the Command Line Interface (CLI).
configuration of HyperTerminal software.
configuration of FTP software on the FTP server.
• Setup the FTP server with the default user name and password
(anonymous).
• None.

Procedure
CAUTION
ATTENTION
If the upgrade is performed from the OneControl workstation, refer to the
OneControl software documentation and perform the OneControl Software
Backup on Demand (Manual) procedure.
Step Action
Connect to 5400 Switch

1 Connect to the 5400 Switch in one of the following ways:
a. Connect a cable from the CNSL port on the CTM to the laptop, and start
a HyperTerminal program.
b. From the laptop, launch a Telnet session to the 5400 Switch virtual
Internet Protocol (IP) address from the Windows Start menu, as follows:
— Select Run.
— Type telnet <5430 IP address>.
— Press Enter.
The CLI Login prompt is displayed.
2 Log on to the 5430 CLI at an administrator level. The default user name is
superuser and the default password superuser1!
3 If required, select the option to return to the CLI Menu.
The Maintenance menu is displayed.
4 At the Maintenance menu type the option number to Perform system
operations and press Enter.
The Operations menu is displayed.
5 At the Operations menu type the option number to Control Plane Restart an
LM and press Enter.
Enter LM to control plane restart: is displayed.
6 Type 1-A-1 to 1-C-15 (5430 Switch) or 1-A-1 to 1-A-10 (5410 Switch).
The following is displayed:
Control Plane Restart an LM: Control Plane Restart of 1-
x-n initiated.
—end—

Procedure 2-6
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.
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.
—continued—


Step Action
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 5400 Packet-
Optical Platform System Description. (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.
—continued—


Step Action
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 5400 Packet-
Optical Platform Commissioning and Testing. 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 5400 Packet-Optical Platform System Description. 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.
—continued—


Step Action
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.
—continued—


Step Action
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 procedure
titled “Removing, deleting or installing an SFP/XFP/CFP” in 5400 Packet-
Optical Platform Fault Management - Module Replacement.
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 procedure titled
“Removing, deleting or installing an SFP/XFP/CFP” in 5400 Packet-Optical
Platform Fault Management - Module Replacement. 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 5400 Packet-Optical
Platform System Description.
• 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
specification, go to step 27.
27 Reconnect the receive fiber, then reinstall the port. If required, refer to the
procedure titled “Removing, deleting or installing an SFP/XFP/CFP” in 5400
Packet-Optical Platform Fault Management - Module Replacement.
• If the alarm cleared, end this procedure.
• If the alarm did not clear, contact the next level of support.
—end—

Procedure 2-7
A-SNCP fail to revert
Category: Reporting event
Probable Cause: ASNCP Failure to Switch
NM Probable Cause: ASNCP failure to revert
NM Additional Text: <Holdback "clean" time in HH:MM format>
Condition Description: The ASNCP failed to revert within the TODR window.
TL1 String: FAILTORVRT
The System shall raise the A-SNCP Fail To Revert event when an A-SNCP
fails to revert within the TODR window.

Step Action
2 Click Go > Monitoring > Alarms & Events and select the Alarms tab. Note
the module that displays the A-SNCP fail to revert alarm.
3 Verify no automatic switches are active.
• If automatic switches are active or the original alarm has not cleared, then
go to step 4
• If alarm has cleared, then go to step 6
4 Determine if a user switch (manual, forced or lockout) is active. release the
switch.
• If no switches are active or the alarm has cleared, then go to step 5
5 If the alarm remains active, ensure that no other alarm is active
6 Verify that the warning cleared.
—end—

Procedure 2-8
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-9
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
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.
—continued—


Step Action
8 Click the Release button in Administer All PUs field.

9 Click Accept.
—end—

Procedure 2-10
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.
—continued—


Step Action

8 Click Accept.
—end—

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

Previous 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-12
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.
—continued—


Step Action

—end—

Procedure 2-13
Probable Cause: ASNCP Manual Switch to Work
NM Probable Cause: ASNCP Manual Switch to Work

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.
—continued—


Step Action
9 Click Accept.
—end—

Procedure 2-14
Object Class: Equipment
Probable Cause: Adjacency discovery unreliable
NM Probable Cause: Adjacency discovery unreliable
NM Additional Text:
Condition Description: The SPLI shelf database contains stale entries.
Default Severity: Minor, Non service affecting
TL1 String: ADJUNR
This alarm is raised when a remote shelf that the SPLI feature is tracking has
not communicated (UDP) with the SPLI application for more than 10 minutes.
This could happen:

• if the remote shelf SiteID or TID has been changed
• if the remote shelf is isolated from the network
• if the remote shelf is constantly restarting.

Step Action
the module that displays the Adjacency discovery unreliable alarm.
3 From the NM SPLI tab, determine if any shelves are unreliable.
4 Verify whether the TID or siteID has changed on those nodes. If changes
have been made, change the TID or siteID of those nodes back to the original
ones if necessary.
5 If changes have not been made, verify that communications are working
correctly by logging into the node.
—continued—


Step Action
6 Click the Refresh button in the SPLI tab of the node Information window to
retrieve the latest status.
7 If SPLI is not matching all the TID-shelves that are listed as unreliable, click
the Delete button. This will remove all the unreliable entries from the table.
—end—

Procedure 2-15
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/Non service affecting for ports with no

cross-connection provisioned, Minor/Non service affecting for ports with
protected status, or Major/Service affecting for ports with unprotected status
TL1 String: AIS (SONET/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.
—continued—


AIS-L/MS-AIS (TTP)
Step Action
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.
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.
—continued—


AIS-L/MS-AIS (TTP)
Step Action
CAUTION
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 5400 Packet-Optical Platform
Fault Management - Module Replacement.
—end—

Procedure 2-16
AIS-P/RDI-P (CTP)
Object Class: CTP (SONET and SDH)
Probable Cause: AIS-P (SONET/SDH)
NM Probable Cause: AIS-P (SONET/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/Non service affecting for ports with protected status, or
Major/service affecting for ports with unprotected status
TL1 String:
• AIS (SONET/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
—continued—


AIS-P/RDI-P (CTP)
Step Action
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-17
All provisioned external authentication servers
unavailable
Category: Usage report
Object Class:
Probable Cause: All Provisioned External LDAP Servers Unavailable
NM Probable Cause:
NM Additional Text:
Condition Description: All provisioned external LDAP servers cannot be

reached based on the timeout parameters
TL1 String: EXTLDAPSERVUNAV
The All External LDAP Servers Unavailable condition is reported when all
provisioned external LDAP servers cannot be reached based on the timeout
parameters.
The All External LDAP Servers Unavailable condition clears when External
LDAP is disabled or when any provisioned external authentication server can
be reached.

Step Action
the All provisioned external authentication servers unavailable alarm.
3 Disable the server from the 5400 switch.
4 Re-enable the server and log in or log out of the server.
5 If the alarm is raised again, disable the server and log in or log out of the
server.
—continued—


All provisioned external authentication servers unavailable
Step Action
6 If the alarm is raised, ensure the following server provisioning values on the
network element are correct:
• server IP address
• server port
7 Check the status of the server. Ensure the status is ON.
8 Log in or log out of the network element.
—end—

Procedure 2-18
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.
—continued—


Step Action
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.
• If Reference failed alarm is present, go to Reference failed.
—end—

Procedure 2-19
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.
—continued—


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

Procedure 2-20
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/Non service affecting for ports with protected status, or
Major/service affecting for ports with unprotected status
TL1 String:
• 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.
—continued—


AU-AIS
Step Action
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.
—continued—


AU-AIS
Step Action
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-21
Auto-revert window active
Category: Service Report
Object Class: Object
Probable Cause: Auto-Revert Window Active
NM Probable Cause:
NM Additional Text: Software Upgrade Auto-Revert Window Active
Condition Description: Period of time after a software upgrade for the 5400
Switch to stabilize. CTM, LM, SM reboots or HIR during this period causes the
5400 Switch to revert to the previous release.
TL1 String: AUTOREVERTWINDOW
The Auto-Revert Window Active condition is raised after a software upgrade.
The Auto-Revert Window Active condition clears when the 5400 Switch exits
the Auto-Revert Period after a software upgrade.

Step Action
1 Wait approximately 30 minutes for the auto-revert window to expire before

changing the system configuration, upgrading spare CTMs, or performing
firmware upgrades.
—end—

Procedure 2-22
Autonegotiation fail
Object Class: ETTP
Probable Cause:
NM Probable Cause: Autonegotiation Fail
NM Additional Text: Autonegotiation Fail
Condition Description:
TL1 String: AUTONEGFAILED
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-23
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
—continued—


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 5400 Packet-Optical Platform Administration and
Security.
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-24
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
—continued—


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 5400 Packet-Optical Platform Fault
Management - Module Replacement 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-25
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.
—continued—


Step Action
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-26
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.
—continued—


Step Action
when completed.)
equivalent.)
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.
—continued—


Step Action
If the far end upstream LTE or MSTE laser and optical multiplexer tests good,
go to step 5.
CAUTION
CAUTION
ESD procedures.
ATTENTION
—continued—


Step Action

MSTE in alarm).
step 12.
go to step 14.
12, go to step 27.
—continued—


Step Action
20 Under the Go > Configuration menu, select the Physical TP and Basic
tabs.
selected.
go to step 27.
—end—

Procedure 2-27
Object Class: MoVlsrPU
Probable Cause: BLSR Default K-Bytes
NM Probable Cause: BLSR Default K-Bytes
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.
TCP for the alarmed equipment.
—continued—


Step Action
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-28
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-29
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:
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 the
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).
—continued—


Step Action
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-30
Probable Cause: BLSR Inconsistent APS Codes
NM Probable Cause: BLSR Inconsistent 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.
—continued—


Step Action
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-31
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-32
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-33
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-34
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.
—continued—


Step Action
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 substep 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.
—continued—


Step Action
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-35
BLSR protection degrade condition
Object Class: BLSR
Probable Cause: BLSR Protection Degrade Detected
Condition Description: BLSR Protection Degrade condition when the

Enhanced Protection Byte Exerciser 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-36
BLSR protection group misconfiguration
Object Class: MoVlsrPg
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 NEs 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 NEs 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
unprovisioned.


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-37
Channel contention
Object Class: PTP
Probable Cause: Channel contention
NM Probable Cause: Channel contention
NM Additional Text:
Condition Description: SPLI has detected a channel contention
TL1 String: CHAN_CONTEN
This alarm is raised against the line facility of all WL3-based platforms
(TSLM1D-WL3, OSLM2-WL3 and OSLM5-WL3n circuit packs) when the
provisioned wavelength/ frequency is already in use and is detected by the
circuit pack.

Step Action
alarm, and note the facility that displays the Channel Contention alarm.
3 Check and ensure the following provisioning information is correct on the
card:
• ENM is matching the other end of the link.
• Differential coding matches the other end of the link.
If all the provisioning information above is correct and the alarm is still active,
then disable Channel Contention Detection.
4 If the original alarm is cleared, the procedure is complete. If the alarm is not
cleared, continue with the next step.
—continued—

Step Action
5 If the alarm is not cleared and the facility wavelength is not already in use on
the network, disable Channel Contention Detection and Avoidance on the
PTP screen Coherent tab.
6 If the alarm does not clear, contact your next level of support or your Ciena
support group.
—end—

Procedure 2-38
Chassis IDP Failed
Category: Equipment
Object Class: MoBay
Probable Cause: Chassis IDP Failed
NM Probable Cause: Chassis IDP Failed
NM Additional Text: CPHF, I92
Condition Description: The Chassis IDP failed alarm is reported as a

Replaceable Unit Problem (RUP) Control Plane Health Failure I92 when the
backplane ID ROM fails.
The 5400 Switch ID stored on the backplane EEPROM is used to brand CTMs
when they are installed in the 5400 Switch. CTM branding assigns a unique
ID to a node chassis and stores that ID in the persistent storage of the CTM.
This allows the CTM to identify circumstances where they are placed in a
foreign node chassis. In such instances, the CTM can force the user to accept
the existing provisioning or reconfigure the alien CTM prior to running the
system software.
Replacing the backplane ID ROM requires accessing the 5400 Switch

backplane. Contact Ciena Technical Support.
TL1 String: EQPT

Step Action
1 Contact Ciena Technical Support.

—end—

Procedure 2-39
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: INT
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
—continued—


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:
ATTENTION
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
—continued—


Step Action
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.
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.
—continued—


Step Action
9 At the node, replace circuit pack in accordance with the appropriate

procedure from 5400 Packet-Optical Platform Fault Management - Module
Replacement:
• Removing and installing a 5400 Switch fan assembly
• Remove and install 5430 Switch CTM
• Removing and installing a 5400 Switch module
• Removing, deleting or installing an SFP/XFP/CFP
• Removing and installing a 5400 Switch line module
• Removing and installing a 5430 Switch display module
• Removing and installing a 5430 Switch I/O module
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-40
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: SWTOINT
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 type 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.
—continued—


Step Action
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-41
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.
TL1 String: PPPFAIL
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 unprovisioned.
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.
—continued—


Step Action

—end—

Procedure 2-42
Object Class: PTP
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.
TL1 String: PRCDRERR
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 preprovisioning,
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
—continued—


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-43
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-44
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
Default Severity: Critical, service affecting
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-45
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
—continued—


DC power failed
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 5400 Packet-Optical Platform Commissioning and Testing.
• 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 5400 Packet-Optical Platform Fault Management -
Module Replacement and replace any burnt or discolored modules in
accordance with the appropriate procedure as listed below, then go to step
12.
• Removing and installing a 5400 Switch fan assembly
• Removing and installing a 5400 Switch module
• Removing, deleting or installing an SFP/XFP/CFP
• Removing and installing a 5400 Switch line module
• Removing and installing a 5430 Switch display module
—continued—


DC power failed
Step Action
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-46
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-47
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
ATTENTION
The Degraded switch fabric alarm can be raised during commissioning,
during the time when the first line module has not yet been installed. The
alarm clears when the first line module is installed.
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 5400
Packet-Optical Platform System Description.
5 Insert SMs as required.
—end—

Procedure 2-48
DPanel mismatch
Category: Equipment
Object Class: Bay
Probable Cause: DPANEL Mismatch
NM Probable Cause: DPANEL Mismatch
NM Additional Text: NA
Condition Description: The provisioned DPANEL and PDU's are not the
same generation.
TL1 String: DPANELMISMATCH
The DPANEL Mismatch alarm is raised when the installed DPANEL and PDUs
are not of the same generation.
This alarm occurs on a 5430 under the following scenarios:

• when a Gen 2 PDU coexists with a legacy display panel
• when a legacy PDU coexists with a Gen 2 display panel
To clear the alarm, the user must install equipment so that the display panel
and the PDUs are of the same generation: either all Gen 2 units, or all legacy
units. DPANEL Mismatch is cleared when the 5430 Switch detects that the
display panel and the PDUs are all of the same generation.

Step Action
—continued—


DPanel mismatch
Step Action
2 Click Go > Inventory, which causes the Basic inventory tab to be displayed.
Expand the equipment tree until the following units are displayed: PDU-A,
PDU-B, and PDU-DPANEL. For each unit, proceed as follows. Select the unit
in the equipment tree, and make note of whether the unit is a Gen 2 unit, as
indicated by the value of the Installed Card Type field on the Basic inventory
tab.
3 At the node, replace units so that all are legacy units or so that all are Gen 2
units.
• For instructions for installing legacy units, see 5400 Packet-Optical
Platform Fault Management - Module Replacement.
• For instructions for installing Gen 2 units, see 5400 Packet-Optical
Platform 5430 15Tb Upgrade and 5400 Packet-Optical Platform 5430
PDU Upgrade.
—end—

Procedure 2-49
Duplicate adjacency discovered
Object Class: PTP
Probable Cause: Duplicate adjacency discovered
NM Probable Cause: Duplicate adjacency discovered.
NM Additional Text:
Condition Description: More than one adjacency match exists for the PTP.
TL1 String: DUPADJ
The Duplicate adjacency discovered alarm is raised against the PTP when
more than a single match exists for the PTP (more than one SPLI Match
associated with the MoPtp object exists).
The Duplicate adjacency discovered alarm is cleared against the PTP when
less than two matches exists for the PTP (less than two SPLI Match objects
associated the MoPtp object exist).

Step Action
NE that displays the Duplicate adjacency discovered alarm.
3 Verify that less than two matches exists for the PTP in alarm.
—end—

Procedure 2-50
ESLM audit mismatch
Category: Equipment
Object Class: MoBay
NM Probable Cause: ESLM audit mismatch
NM Additional Text:
Default Severity: Major, Service affecting
TL1 String: AUDITMM
An ESLM audit mismatch is reported when the ESLM configuration data

stored in the CTM is inconsistent with configuration data in the ESLM. Note
that audit mismatches are detected only when a CTM switchover occurs.
A mismatch in configuration data may or may not affect traffic. Whether a

mismatch affects traffic is dependent on the specific data that is mismatched.

Step Action
2 Click Go > Monitoring > Alarms & Events, select the Alarms tab, then
select the ESLM Audit Mismatch alarm.
3 Refer to the Additional Text to determine the cause of the alarm and/or
recommended action to correct the mismatch.
• If the source of the mismatch is identified, check the ESLM configuration
data and reprovision incorrect parameters as necessary.
—end—

Procedure 2-51
ESLM card in Hold
Category: Equipment
Object Class: MoBay
NM Probable Cause: ESLM card in Hold
NM Additional Text:
TL1 String: LMHOLD

Step Action
2 Click Go > Monitoring > Alarms & Events, select the Alarms tab, then
select the ESLM card in Hold alarm. Note that the Alarms table identifies
which ESLM is the source of the alarm.
3 Refer to the Additional Text to determine the cause of the alarm and/or
recommended action to clear the Hold state.
• If indicated, perform the recommended action.
—end—

Procedure 2-52
Ethernet failure indication condition (Ethernet LFI)
Object Class: ETTP
NM Probable Cause: Ethernet-LFI
NM Additional Text: Local fault
TL1 String: LFI

Step Action
3 Select the port that displays the Ethernet failure indication condition (Ethernet
LFI) alarm.
4 Inspect far end client equipment configuration and operational state and
perform any required configuration changes or repairs.
—end—

Procedure 2-53
Object Class: ETTP
NM Probable Cause: Ethernet Forward Fault Indication
NM Additional Text: Ethernet Forward Fault
TL1 String: 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.
—continued—


Step Action
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-54
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: 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.)
—continued—


Ethernet-LOF
Step Action
(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 5400 Packet-Optical Platform System Description.
(Corrective action: clean the transmit port fiber connector, replace the
SFP/XFP/CFP, and/or correct improper Line Build Out if not a 5400
Switch technology.)
• If the test result for the far end upstream LTE or MSTE laser or optical
multiplexer is bad, repair in accordance with upstream technology
guidelines, then go to step 22.
• If the test result for the far end upstream laser transmitter is good, go to
step 5.
CAUTION
CAUTION
ESD procedures.
—continued—


Ethernet-LOF
Step Action
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 procedures listed in 5400 Packet-Optical
Platform Configuration - Provisioning and Operating, and then go to step
23.
6 Remove the receive fiber in accordance with Removing, deleting or installing
an SFP/XFP/CFP in 5400 Packet-Optical Platform Fault Management -
Module Replacement, 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.
—continued—


Ethernet-LOF
Step Action
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.
—continued—


Ethernet-LOF
Step Action
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 Removing, deleting or installing an SFP/XFP/CFP in 5400
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.
23 Reconnect the receive fiber and if applicable, reinstall the SFP/XFP.CFP in
—end—

Procedure 2-55
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.

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.

Step Action
alarm, and note the port that displays the Ethernet-LOS alarm.
—continued—


Ethernet-LOS
Step Action
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:
(Corrective action: re-place/provision SFP/XFP/CFP with correct rate,
before correcting and unlock when completed).
• The laser should not be locked. (Corrective action: unlock the port.)
(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
—continued—


Ethernet-LOS
Step Action
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.
—continued—


Ethernet-LOS
Step Action
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
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.
—continued—


Ethernet-LOS
Step Action

19 Verify that the alarm cleared at the Node Manager workstation.
20 Replace the module then go to step 23.
go to step 23.
step 22.
—end—

Procedure 2-56
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: 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.
—continued—


Ethernet-RFI
Step Action
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
6 Recheck the Ethernet Remote Fault Indication alarm status.
—end—

Procedure 2-57
Category: Reporting Event
Object Class:
Probable Cause: External LDAP Server Unavailable
NM Probable Cause: External LDAP Server Unavailable
NM Additional Text:
Condition Description: An external LDAP server cannot be reached based

on the timeout parameters.
TL1 String: EXTLDAPSERVUNAV

Step Action
2 Click Go > Administration > Security > LDAP Key Mgmt and note
reachability Status on all provisioned LDAP servers.
3 If reachability Status is Unavailable on only one server, troubleshoot.
4 Set LDAP Key Mgmt Mode to Disabled and click Apply.
5 Set LDAP Key Mgmt Mode to Enabled and click Apply.
6 If the alarm is raised again, disable the server and log in or log out of the
server.
7 If the alarm is raised, ensure the following server provisioning values on the
network element are correct:
• server IP address
• server port
8 Check the status of the server. Ensure the status is ON.
9 Log in or log out of the network element.
—continued—


Step Action

—end—

Procedure 2-58
Object Class: MoCircuitPackCM
Probable Cause: Expansion Switch Link Down
NM Probable Cause: Expansion Switch Link Down
NM Additional Text: [ES1, ES2, ES3, ES4] port
Condition Description: An Expansion Switch link is down on one or more of

the four ES ports (ES1, ES2, ES3, ES4)
ATTENTION
Only ES1 can be enabled in this release.
TL1 String: ESPORTDOWN

Step Action
Expansion switch link down alarm, and note the Probable Cause and
Additional Information.
3 Check Ethernet link to local router. If alarm clears, end this procedure.
4 Verify remote 6500 link and ES/ILAN port configuration. If alarm clears, end
this procedure.
5 From the Node Manager workstation, click Go > Inventory, expand the
equipment tree and select the secondary CTM.
6 Ensure Operational State is Enabled and Procedural Status is
Synchronized.
7 Select the CTM reporting the alarm and click Soft Reset and then click
Accept when prompted.
—continued—


Step Action
8 Refer to the 5400 Switch Service manual and remove and replace the CTM
reporting the alarm.
—end—

Procedure 2-59
Fabric Upgrade In-Progress
Object Class: Bay
Probable Cause: Fabric Upgrade In-Progress
NM Probable Cause: Fabric Upgrade In-Progress
Default Severity: Minor, Non service affective
TL1 String:
The Fabric Upgrade In-Progress standing condition is raised when a

combination of SMs and HDSMs are present in the chassis. This standing
condition is cleared when only one type of SM is present in the chassis.

Step Action
1 Refer to 5400 Packet-Optical Platform 5410 5Tb Upgrade or 5400 Packet-

Optical Platform 543015Tb Upgrade and complete the SM upgrade.
—end—

Procedure 2-60
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 set point 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 set point temperatures of all devices in
the system.
TL1 String: FANOVRSPD
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
set point temperatures of all devices in the system.
A Fan Overdriven alarm indicates that a device on a circuit pack is above its
set point temperature, but not necessarily above its max operating threshold.
Fan Overdriven is cleared when the commanded fan speed falls below 7500
RPM.
When the alarm is raised, the network operations center (NOC) should check
for any stimulus that would cause the system temperature to rise and fans to
be over driven. Stimuli may include: a clogged air filter, a stuck exhaust louver,
or a disruption in facility cooling. If the stimuli are addressed or do not exist,
one should expect the alarm to clear within two hours.


Step Action
Fan overdriven alarm, and note any additional equipment alarm information
related to the node.
• If there are no related equipment or high temperature alarms, go to step
3.
CAUTION
ESD procedures.
ATTENTION
5 Wait two hours, and then verify that the alarm cleared at the Node Manager
workstation.
—end—

Procedure 2-61
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
—continued—


Fan speed mismatch
Step Action
Fan speed mismatch alarm, and note any additional equipment alarm
information related to the node.
• 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-62
Probable Cause: FCC Automatic Switch
NM Probable Cause: FCC Automatic Switch
NM Additional Text:
TL1 String: WKSWPR
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.
—continued—


Step Action
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,
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.
—continued—


Step Action
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.
—continued—


Step Action
MSTE in alarm).
step 12.
• If a defective or dirty fiber or connector was cleaned or repaired in step
12, go to step 14.
• If no defective or dirty fibers or connectors were cleaned or repaired in
step 12, go to step 26.
—continued—


Step Action
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.
go to step 26.
—end—

Procedure 2-63
FCC fail to revert
Probable Cause: FCC failure to revert
NM Probable Cause: FCC failure to revert
The FCC fail to revert event is raised when an FCC fails to revert within the
TODR window.

Step Action
the module that displays the FCC fail to revert alarm.
go to step 4
switch.
—end—

Procedure 2-64
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-65
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.
—continued—


Step Action

—end—

Procedure 2-66
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.
—continued—


Step Action

—end—

Procedure 2-67
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-68
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-69
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.
—continued—


Step Action

9 Click Accept.
—end—

Procedure 2-70
FEC type mismatch
Object Class: TTP
Probable Cause:
NM Probable Cause: FEC Type Mismatch
NM Additional Text:
Condition Description: FEC Type provisioning Mismatch
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-71
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 Firmware mismatch alarm.
—continued—


Firmware mismatch
Step Action
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-72
FPGA SEU event
Category: Equipment
Object Class: MoLM
Probable Cause: Single event upset: soft CRC error event of line module
circuit pack.
NM Probable Cause: FPGA SEU event
NM Additional Text:
Condition Description: Reports FPGA Soft CRC Error Event of LM Circuit

Pack.
Default Severity: Reporting event; Non service affecting.
TL1 String:
The alarm is generated when the following single event upset (SEU) is
detected: soft CRC error event on line module circuit pack.
—end—

Procedure 2-73
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-74
Object Class: CG
Probable Cause: GFP loss of frame delineation
NM Probable Cause: GFP loss of frame delineation
NM Additional Text: Loss of GFP Frame
Condition Description: GFP layer cannot detect valid GFP frames.
Default Severity: Major SA
TL1 String: GFP-LFD
GFP loss of frame delineation alarm is raised against the GFP object if an
dLFD defect persists for 2.5 (± 0.5) seconds.
The GFP loss of frame delineation alarm is cleared when the dLFD defect is
absent for 10 (± 0.5) seconds.
This condition occurs when OPUk layer failures cause dLFD.

Step Action
alarm, and note the MoGfpAp object that displays the GFP Loss of frame
delineation alarm.
3 Verify the TransparencyMode on the associated ETTP objects are same on
both ends of the tunnel.
4 Clear any upstream OTN faults (LOS, LOC, LOF, LOM, AIS, LCK, OCI, or
Payload Type Mismatches).
—continued—


Step Action

—end—

Procedure 2-75
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.
—continued—


GFP UPI mismatch
Step Action
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-76
HIBER
Object Class: ETTP (10GbE, 40 GbE, 100 GbE)
Probable Cause: HiBER
NM Additional Text: HiBER detected
Condition Description: HiBER condition detected.
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
cross connection.
TL1 String: HIBER

Step Action
3 Select the alarm, and note the port that displays the "HiBER" alarm.
4 Click Go > Configuring > PTPs, check actual received optical power on
associated PTP and verify that received optical power meets the optical
interface specifications. If received optical power is outside the specified
operating range, trouble shoot / repair the link.
—end—

Procedure 2-77
High temperature
Category: Equipment
Probable Cause: High temperature
NM Probable Cause: High temperature
NM Additional Text: The module is near the maximum temperature range.
Condition Description: Circuit Pack Temperature Warning is generated

when any one of the monitored temperatures on a circuit pack near the
maximum temperature range.
Default Severity: Minor, not service affecting
TL1 String: HITEMP
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 warning temperature threshold.
High Temperature is generated when any one of the monitored temperatures

on a circuit pack cross its warning temperature threshold.
High Temperature is cleared when all monitored temperatures of a circuit pack

are below their warning temperatures.

Step Action
—continued—


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:
— 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
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
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.
—continued—


Step Action
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.
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.
Replacement:
Removing and installing a 5400 Switch fan assembly
Remove and install 5430 Switch CTM
Removing and installing a 5400 Switch module
Removing, deleting or installing an SFP/XFP/CFP
Removing and installing a 5400 Switch line module
Removing and installing a 5430 Switch display module
Removing and installing a 5430 Switch I/O module
—continued—


Step Action
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.
— If the alarm cleared, end this procedure.

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

Procedure 2-78
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: LPBKTERM or LPBKFACILITY
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-79
In loopback mode
Object Class: TTP
Probable Cause: Loopback
NM Probable Cause: Loopback
Condition Description: Loopback is enabled on a a TTP.
TL1 String: Not applicable
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-80
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: FA
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.
—continued—


Input power fuse
Step Action

procedures listed in 5400 Packet-Optical Platform Fault Management -
Module Replacement.
—end—

Procedure 2-81
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-82
Object Class: MoSubtendedNeighbor
Probable Cause: Last authentication key expired
NM Probable Cause:
NM Additional Text: Expired accept key still used as no other key active for
generate.
TL1 String: LASTMD5KEYTO
The system generates the condition for last key timed out when the accept
stop time or generate stop time expire for the last available key for the
interface.
This condition is cleared, when the “accept stop time” and “generate stop
time” both have configured values greater than the current time, the
associated key is deleted, or a new key is configured and enabled for current
use.

Step Action
Last authentication key expired alarm.
3 Click Go > provisioning > OSPF and select the Subtended neighbor tab.
4 Click the MD5Key Data Tab and the Add/Remove MD5 Keys dialog box is
displayed.
5 Verify that the “accept stop time” and “generate stop time” both have
configured values greater than the current time.
6 Click Close.
—continued—


Step Action

—end—

Procedure 2-83
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
—continued—


Step Action
LAPS automatic switch to protect alarm, and note the port that displays the
automatic switchover condition.
when completed.)
equivalent.)
—continued—


Step Action
go to step 5.
CAUTION
CAUTION
ESD procedures.
ATTENTION
—continued—


Step Action
MSTE in alarm).
step 14.
12, go to step 14.
—continued—


Step Action
tabs.
selected.
22 Reconnect the receive fiber, then reinstall the port in accordance with the
go to step 27.
—end—

Procedure 2-84
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,
—continued—


Step Action
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-85
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-86
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.
—continued—


Step Action
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-87
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.
—continued—


Step Action

Request.
—end—

Procedure 2-88
Probable Cause: Invalid APS Mode Failure
NM Probable Cause: Invalid APS Mode Failure
NM Additional Text:
Condition Description: Invalid APS Mode
TL1 String: APSIM
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,
—continued—


Step Action
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-89
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-90
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-91
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.
—continued—


Step Action

Request.
—end—

Procedure 2-92
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.
—continued—


Step Action

Request.
—end—

Procedure 2-93
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, the
source name, and additional information.
—continued—


LAPS mode mismatch
Step Action
4 Change the configuration parameters to match the local or far end as required
then click Accept.
—end—

Procedure 2-94
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.
—continued—


Step Action
defect alarms.
• If no Receiver equipment failure alarms, Near End APS alarms, or
go to the next step.
—end—

Procedure 2-95
Laser frequency out of range
Object Class: PTP
Probable Cause: Laser frequency out of range.
NM Probable Cause: Laser frequency out of range.
NM Additional Text: Laser frequency out of range.
TL1 String: OLFOOR

Step Action
1 If possible, clear all other alarms from the network.

2 If the alarm is not clear, verify the subtending equipment to ensure that it
meets the frequency specification. If the equipment does not meet the
specification, change the client signal to use subtending equipment that is
within specifications.
support group.
—end—

Procedure 2-96
LCH
Object Class: TTP
Probable Cause: LCH
NM Probable Cause: LCH
NM Additional Text: Provisioned Channel Power Low

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.
—continued—


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

Procedure 2-97
Line Flapping
Object Class: TTP
Probable Cause: Line Flapping
NM Probable Cause: Line Flapping
NM Additional Text: (None)
Condition Description: Line going in and out of failure
TL1 String: LFA
The line flapping alarm is used to identify when a line goes in and out of failure
multiple times within a specified time. This feature counts multiple line failure
occurrences within a user defined window and reports it as an alarm after a
certain defined threshold is reached. For example: three line failures [any
combination of LOS/LOF/AIS-L] detected within 300 seconds triggers a Line
Flapping Alarm. The alarm automatically clears when the line is error free for
a user defined period of seconds.
Any combination of the following defect(s) occurring on a SONET/SDH line

cause a 'line down' and are used to count line failure(s):
• LOS
• LOF
• AIS-L
• SF-BER
• Mesh on Signal Degrade

The following ODUkT TCMi layer defects shall declare a 'line down' and be
used to count line failure(s):
• SSF
— dLOS
— dLOF
— dLOM
— dLOL
— OTUk dAIS
• TCM dAIS
• TCM dLOF
• TCM dOCI
• TCM dLCK
• TCM dLTC (with consequent actions enabled)
• TCM dTIM (with consequent actions enabled)
• Mesh on Sustained DEG

Step Action
2 Check the facility for problems which cause intermittent failures.
—end—

Procedure 2-98
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.
—continued—


LOC
Step Action
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-99
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.
—continued—


LOF
Step Action
SFP/XFP/CFP, and/or correct improper Line Build Out (LBO) if not a 5400
Switch technology.)
step 21.
• If the far end upstream LTE or MSTE laser and optical multiplexer test
good, go to step 5.
—continued—


LOF
Step Action
CAUTION
CAUTION
ESD procedures.
ATTENTION

—continued—


LOF
Step Action
(between the transmit LTE or MSTE checked in step 4 and the Receive LTE
or MSTE in alarm).
step 21.
to step 23.
—continued—


LOF
Step Action
port in alarm.
rate is selected.
step 22.
—end—

Procedure 2-100
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 - MN/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 non
service affecting.

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


LOP
Step Action
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-101
Loss of multi-frame indication
Object Class: TTP (ODU4)
Probable Cause: ODU LOOMFI
Condition Description: Loss of OPU4 Multiframe
NM Additional Text: Loss of OPU4 Multiframe Indicator

unprotected status.
TL1 String: LOOMFI
This alarm applies only to ODU4, specifically the OPU4 multi frame alignment
process. LOOMFI alarm is raised as a result of an incorrectly mapped OPU
payload, where the payload is multiplexed ODUjs.

Step Action
3 Select the alarm, and note the port that displays the "loss of multiframe
indication" alarm.
4 Inspect the upstream equipment performing the ODUk/ODUj mapping, and
re-configure, replace, or repair the equipment in such a way that it complies
with the ITU-T G.798 ODUkP/ODUj-21 standard mapping process.
—end—

Procedure 2-102
Loss of lane alignment
Object Class: ETTP
Probable Cause: Ethernet-LOL
NM Probable Cause: Ethernet-LOL
NM Additional Text: Loss of lane on parallel interface

unprotected status.
TL1 String: LOL

Step Action
3 Select the alarm, and note the port that displays the "Loss of lane alignment"
alarm.
4 Inspect far end client equipment configuration and operational state and
perform any required configuration changes or repairs.
—end—

Procedure 2-103
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: LOPCS
A 10Gbe or 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.
—continued—


Loss of PCS
Step Action

—end—

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

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.
—continued—


LOS
Step Action
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.)
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.
—continued—


LOS
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.
—continued—


LOS
Step Action
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.
11, go to step 26.
• If no defective or dirty fibers or connectors was cleaned or repaired in
—continued—


LOS
Step Action
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 5400 Packet-Optical Platform System
Description.
go to step 28.
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-105
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.
—continued—


LSC
Step Action
SFP/XFP/CFP, and/or correct improper Line Build Out (LBO) if not a 5400
Switch technology.)
step 21.
• If the far end upstream LTE or MSTE laser and optical multiplexer test
good, go to step 5.
CAUTION
—continued—


LSC
Step Action
CAUTION
ESD procedures.
ATTENTION

or MSTE in alarm).
—continued—


LSC
Step Action
step 21.
to step 23.
port in alarm.
—continued—


LSC
Step Action
rate is selected.
specification defined in SFP/XFP/CFP Specifications listed in 5400 Packet-
Optical Platform System Description.
step 22.
—end—

Procedure 2-106
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 Check box.
—end—

Procedure 2-107
NDP configuration mismatch condition
NM Probable Cause: NDP Neighbor Configuration Mismatch
NM Additional Text: Same Subtended Neighbor configured on multiple NDP

links with different discovered destinations.
TL1 String: NBRCONFIGMISMTCH
This condition for Configuration Mismatch is raised when multiple NDP links
to the same subtended neighbor have different discovered destinations.

Step Action
1 Verify that multiple NDP links to the same subtended neighbor have the
same discovered destinations.
—end—

Procedure 2-108
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
—continued—


NDP adjacency down
Step Action
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-109
NDP duplicate subtended neighbor condition
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-110
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-111
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 three areas, 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 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-112
Object Class: MoBay
Probable Cause: NTP server connection failed
NM Probable Cause:
NM Additional Text: The connection to the provisioned NTP Server(s) failed
TL1 String: NTPFAIL
The alarm is raised if/when the Node is unable to communicate with any of the
provisioned NTP servers.

Step Action
3 Select the alarm that displays the NTP server connection failed alarm.
4 Log in to the Maintenance CLI by connecting a Telnet session to the Node's
DCN IP Address.
—continued—


Step Action
5 At the “Enter Choice” prompt at the bottom of the Maintenance Menu, type
the number to select the Modify system configuration option, and then
press Enter to select the Node Settings menu.
6 At the “Enter Choice” prompt at the bottom of the Node Settings menu, type
the number to select the NTP Settings Menu option, and then press Enter
to select the NTP Settings menu.
7 At the “Enter Choice” prompt at the bottom of the NTP Settings menu, type
the number to select the NTP Server Settings Menu option, and then press
Enter to select the NTP Server menu.
8 At the “Enter Choice” prompt at the bottom of the NTP Server menu, type the
number to select the Get server status option, and then press Enter to get
the latest connection status.
9 If all servers show “Init” in the NTP status column, wait approximately one
minute. Then, at the “Enter Choice” prompt at the bottom of the NTP Server
menu, type the number to select the Get server status option, and then
press Enter to get the latest connection status once again. If all servers do
not show “Init” in the NTP status column, proceed to step 21.
10 If all servers persist in the “Init” state, it is possible that the underlying NTP
client did not start correctly. To restart the client, follow this procedure:
number to select the Return to previous menu option, and then press Enter
to select the NTP Settings menu.
the number to select the Enable/Disable External NTP Support option, and
then press Enter.
13 Enter "disable".
the number to select the Commit pending NTP configuration option, and
then press Enter. This will temporarily clear the alarm.
the number to select the Enable/Disable External NTP Support option, and
then press Enter.
16 Enter "enable".
the number to select the Commit pending NTP configuration option, and
then press Enter.
18 Wait approximately two minutes. Then, at the “Enter Choice” prompt at the
bottom of the NTP Settings menu, type the number to select the NTP Server
Settings Menu option, and then press Enter to select the NTP Server menu.
—continued—


Step Action
number to select the Get server status option, and then press Enter to force
the status information to refresh.
20 If the NTP Status column shows “Connected” or “Synced” for any server, the
alarm will remain cleared in Node Manager. If the alarm returns in Node
Manager during this step, proceed to the next step.
21 If any of the servers display “Failed” in the Auth Status column, then attempt
to fix the connection and clear the alarm using the following steps. If not,
proceed to step 33.
number to select the Show settings for an individual server option, and
then press Enter. Then enter the IP Address of the server.
23 Verify that the “Key ID” in use matches the same “Key ID” used by that server.
If that information is not available, verify it against the available configuration
information.
24 If NTP Authentication is not intended to be enabled for this server, the “Key
ID” must be “0”.
to return to the NTP Settings menu.
the number to select the NTP Authentication Settings Menu option, and
then press Enter to display the NTP Authentication menu.
27 At the “Enter Choice” prompt at the bottom of the NTP Authentication menu,
type the number to select the Show a single KeyID option, and then press
Enter. Then enter the relevant “Key ID”. Verify that the authentication type
matches what is in use on the server.
28 For security reasons, the authentication key is not displayed in the MCLI. If at
this point no error is apparent, delete the key and then re-enter the key to
ensure it is correct. To delete and then re-enter the key, use the following NTP
Authentication menu options in the sequence shown:
• Delete an NTP Authentication Key
• Add a new KeyID
• Set Authentication Type
• Enter Authentication Key
29 If any configuration changes have been made, wait approximately one
minute. Then, at the “Enter Choice” prompt at the bottom of the NTP
Authentication menu, type the number to select the Return to previous
menu option, and then press Enter to return to the NTP Settings menu.
—continued—


Step Action
the number to select the NTP Server Settings Menu option, and then press
Enter to select the NTP Server menu.
number to select the Get server status option, and then press Enter to force
the status alarms to refresh and see if the changes corrected the problem.
32 If the alarm persists, continue to the next step. If the alarm has cleared, make
sure to repeat these instructions for any other NTP servers with an Auth
Status of “Failed” to ensure optimal NTP operation.
to return to the NTP Settings menu. From here there are three different paths
to clear the alarm.
• Option 1. Disable the NTP Client feature, and apply the change. To
disable the NTP Client feature, proceed as follows. At the “Enter Choice”
prompt at the bottom of the NTP Settings menu, type the number to select
the Enable/Disable External NTP Support option, and then press
Enter. Then enter “disable”. To apply the change, proceed as follows.
At the “Enter Choice” prompt at the bottom of the NTP Settings menu,
type the number to select the Commit pending NTP configuration
option, and then press Enter.
• Option 2. Go to the NTP Server menu and use the options on that menu
to add a valid NTP server. To go to the NTP Server menu, proceed as
follows. At the “Enter Choice” prompt at the bottom of the NTP Settings
menu, type the number to select the NTP Server Settings Menu option,
and then press Enter. When you are on the NTP Server menu, you can
use the menu options to add a valid NTP server. The options for this can
vary based on the configuration of the server being added: please refer
to 5400 Packet-Optical Platform Administration and Security for
information on adding a NTP server.
• Option 3. Go to the NTP Server menu, and list all NTP servers. To go to
the NTP Server menu, proceed as follows. At the “Enter Choice” prompt
at the bottom of the NTP Settings menu, type the number to select the
NTP Server Settings Menu option, and then press Enter. To list all NTP
servers, proceed as follows. At the “Enter Choice” prompt at the bottom
of the NTP Server menu, type the number to select the List all NTP
servers option, and then press Enter.
—continued—


Step Action
34 Verify that all servers have been correctly configured. If it is determined that
all servers have been correctly configured but the alarm persists, the alarm
can be cleared by removing all configured NTP servers. To delete a
configured NTP server, use the Delete an NTP Server option on the NTP
Server menu.
35 If the alarm cleared, end this procedure.
36 If the alarm did not clear, verify that the desired NTP servers are operational
and then contact the next level of support.
—end—

Procedure 2-113
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: 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.
—continued—


ODU AIS
Step Action
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 defect,
go to step 5.
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-114
ODU BDI
Probable Cause: ODU BDI
NM Probable Cause: ODU BDI
NM Additional Text: Backward Defect Indication

unprotected status
TL1 String: 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.
—continued—


ODU BDI
Step Action
3 View the Current Alarms details screen and note any related Unavailable
(SNC) alarms.
• If an alarm exists, discontinue this procedure and perform the
Unavailable (SNC) alarm TCP.
• If an equipment alarm does not exist, isolate the problem to the 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.
• If no upstream alarm can be identified, go to step 5.
—end—

Procedure 2-115
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: 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.
—continued—


ODU DEG
Step Action
— Port and LM (or equivalent if other technology) equipment failures or
— The laser should be of the correct type (rate, wavelength, and reach),
and the provisioned optical rate (if applicable) should also be correct.
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 should be in accordance with SFP/XFP/
CFP Specifications in 5400 Packet-Optical Platform System
Description. (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.)
step 24.
good, go to step 5.
—continued—


ODU DEG
Step Action
CAUTION
CAUTION
ESD procedures.
ATTENTION
—continued—


ODU DEG
Step Action
(between the transmit node checked in step 4 and the receive node in alarm).
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
step 22.
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.
—continued—


ODU DEG
Step Action
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 Removing, deleting or installing an SFP/XFP/CFP in 5400 Packet-
• 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.
go to step 24.
—end—

Procedure 2-116
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: 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-117
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.
—continued—


ODU LOF
Step Action
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 or
replace SFP/XFP/CFP, LM, or equivalent.)
(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 provisioned optical rate is correct. Always lock
the port before correcting and unlock when completed.)
replace the SFP/XFP/CFP, and/or correct improper 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.
—continued—


ODU LOF
Step Action
CAUTION
CAUTION
ESD procedures.
ATTENTION

Module Replacement. Insert the receive fiber into a test set capable of
—continued—


ODU LOF
Step Action
(between the transmit node checked in step 4 and the Receive node in
alarm).
receive 5400 Switch/CoreDirector Switch. Isolate and clean/repair the fiber or
connector trouble in accordance with internal guidelines.
step 21.
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.
—continued—


ODU LOF
Step Action
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
step 22.
—end—

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

TL1 String: 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.
—continued—


ODU OCI
Step Action

—end—

Procedure 2-119
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: 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 5400 Packet-Optical Platform Fault
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.
—continued—


ODU PLM
Step Action
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-120
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>
Default Severity:
• Warning, Non service affecting if Consequent Actions are Disabled.
• Minor, Non service affecting for ports with no cross-connection
provisioned, MN/NSA for ports with protected status, or CR/SA for ports
with unprotected status.
TL1 String: 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.
—continued—


ODU TIM
Step Action
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-121
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 that at least
one of the measurements, reach or PMD (Polarization Mode Dispersion) DGD
(differential group delay), exceeded the specifications of the circuit pack. Line
signal conditioning will be applied if the condition which caused this alarm to
be raised was present during optical signal acquisition (for example, after
connecting fiber, or after card insertion or cold restart operation). It is possible
for this alarm to be raised without impacting traffic, if traffic was already
running prior to the condition being detected. Actions must be taken to clear
this alarm as soon as possible.
The alarm is latched even if all measurements, reach or PMD DGD, do not
exceed the specifications of the circuit pack and does not get re-evaluated
until either a cold restart of the circuit pack or a line fault condition toggles (for
example: fiber pull and reinsertion).

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.
—continued—


Step Action

• If the alarm did not clear, goto step 5
5 Replace the coherent optical interface circuit pack with another that does
support the reach or PMD. Refer to 5400 Packet-Optical Platform Fault
Management - Module Replacement for procedure on how to replace a circuit
pack.
• If the alarm did not clear, contact the next level of support
—end—

Procedure 2-122
OPR channel out of range
Object Class: PTP
Probable Cause: OPR Channel Out of Range
NM Probable Cause: OPR out of range
NM Additional Text: OPR channel out of range <High or Low>
TL1 String: OPRCHOOR
This warning is associated with the operation of the interface on a colorless

DWDM line system where the add/drop interface of the line system can drop
a band of wavelengths to the receiver and allow the coherent receiver to filter
the wavelength of interest. This is a measure of the received channel of
interest.
The warning is cleared when:

• Rx power is within the minimum and maximum receive optical power
range.
• LOS condition is raised on the PTP
• PTP is placed in ARC Lock
• optical module is removed from the LM

Step Action
alarm, and note the port that displays the OPR channel out of range alarm.
3 Locate the receive port that is in alarm and use an attenuator to raise or lower
the power as needed.


• If the alarm did not clear, replace the optic.
—end—

Procedure 2-123
OPR channel power high
Object Class: PTP
Probable Cause: OPR channel power high
NM Probable Cause: OPR channel power high
NM Additional Text: Optical channel power outside limit
Condition Description: The OPR channel power high refers to a specific

channel on a WL3 or higher modem port with high coherent receiver filtered
channel power. The alarm is raised when the Rx power is above the maximum
receive optical power range defined for the interface.
TL1 String: OPROL

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

Procedure 2-124
OPR out-of-range
Object Class: PTP
Probable Cause: OPR out of range
NM Probable Cause: OOR
NM Additional Text: OPR out of range <High or Low>
TL1 String: OPROOR
The warning is raised when the total optical power seen at the receiver 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
1 At the Node Manager workstation, launch the NM application and log on to

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 Removing, deleting
or installing an SFP/XFP/CFP in 5400 Packet-Optical Platform Fault
• If the alarm cleared, end this procedure
—end—

Procedure 2-125
OPR power high
Object Class: PTP
Probable Cause: OPR power high
NM Probable Cause: OPR power high
NM Additional Text: Optical power outside limit.
Condition Description: The OPR power high refers to a grey optics or a WL2
modem port. The alarm is raised when the Rx power is above the maximum
receive optical power range defined for the interface.
TL1 String: OPROL

Step Action
alarm, and note the port that displays the OPR power high alarm.
3 Locate the receive port that is in alarm and use an attenuator to raise or lower
the power as needed.
• If the alarm did not clear, replace the optic.
—end—

Procedure 2-126
Optical trace mismatch (TR control)
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 (TR control)
alarm.
3 Verify that the transmit and receive fibers are connected to the appropriate
ports.
—end—

Procedure 2-127
OPU CSF
Object Class: ODU CTP
Probable Cause: OPU CSF
NM Probable Cause: OPU CSF
NM Additional Text: Client Signal Fail
TL1 String: 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.
—continued—


OPU CSF
Step Action
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-128
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: 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-129
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: ISISADJACENCY
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.
7 From the Maintenance Menu, disable the OSI and reboot the Primary CTM.

—end—

Procedure 2-130
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-131
OSPF backplane IP address conflict condition
Object Class:
NM Probable Cause: Backplane IP Address Conflict
Condition Description: RNE address detected which conflicts with the

address space assigned to the 5400 backplane IP address space.
Additional Text: < IP address of conflicting RNE>
TL1 String: BPIPCONFLICT
This alarm is raised when a subtending RNE address is detected that conflicts
with the address space assigned to the 5400 backplane IP address space.
The condition is cleared when the node no longer detects an RNE address
that conflicts with the address space assigned to the 5400 backplane IP
address space.

Step Action
alarm, and note the IP address of conflicting RNE.
3 At the conflicting RNE IP, change the IP Address.
—end—

Procedure 2-132
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.
—continued—


Step Action
9 In the list frame, select Local Links and then in the details frame, select
Link.
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-133
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.
—continued—


Step Action
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-134
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
check box is ‘checked’ in the detail field.
4 Click Accept.
—end—

Procedure 2-135
OSRP CTP misconfigured bandwidth lockout
Object Class: OsrpCtp
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.
check boxes in the detail field.
6 Verify that both check boxes are consistent at both nodes.
7 Click Accept.
—end—

Procedure 2-136
OSRP CTP misconfigured OVPN ID
Object Class: CTP
Probable Cause: OSRP CTP Misconfigured OVPN ID
NM Probable Cause:
NM Additional Text: OSRP Line OVPN ID Mismatch
TL1 String: OSRPCTPMISCONFIGURED

Step Action
the port that displays the OSRP CTP misconfigured OVPN ID 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-137
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-138
OSRP LTP misconfigured BW thresholds
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:;
TL1 String: CONFIGMISMATCH
Configuration mismatch due to advertised bandwidth threshold attribute on

adjacent OSRP links.

the port that displays the OSRP LTP misconfigured BW thresholds 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-139
Object Class: MoLtp
NM Probable Cause: OSRP LTP Oversubscribed
NM Additional Text: Bandwidth Oversubscription
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.
—continued—


Step Action
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-140
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-141
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.
—continued—


Step Action
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-142
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 bundled 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.
—continued—


Step Action
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-143
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.
—continued—


Step Action
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-144
OSRP OVPN ID mismatch conditions
Object Class: CTP
Probable Cause: OSRP CTP Misconfigured OVPN ID
NM Probable Cause:
NM Additional Text: OSRP Line OVPN Bandwidth Mismatch
Condition Description: Configuration Mismatch due to OVPN ID Bandwidth
TL1 String: OSRPCTPMISCONFIGURED
An OSRP OVPN ID Mismatch condition is generated on a Link when the two

ends of a Link are configured with different OVPN IDs

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-145
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-146
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
—continued—


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 11.
5 For OTN, select Go > Configuring > Trail TPs > OTN TTPs > OTU TTPs and
select the GCC tab for the desired port.
6 For SONET/SDH, select Go > Configuring > Trail TPs > SONET/SDH TTPs
and select the DCC tab for the desired port.
7 Note OSRP channel setting.
8 Launch node manager on the remote node identified in step 3.
9 Repeat step 5 or step 6 at the remote node.
10 Check OSRP channel setting for the desired port at the remote node.
11 Verify the OSRP channel settings are the same.
12 If the OSRP channel settings are not the same, make the desired changes
and click Accept.
13 Ensure the setting is the same at both ends of the link.
14 Verify that the alarm cleared on both the local and remote nodes.
• If alarm is cleared, end this procedure.
—end—

Procedure 2-147
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: 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.
—continued—


OTU AIS
Step Action
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, the
manually isolated.
ATTENTION
go to step 5.
5 Reconnect fiber, reinstall OM, SFP/XFP/CFP, and recheck alarm status.
6 Replace the OM, SFP/XFP/CFP.
—end—

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

unprotected status
TL1 String: 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.
—continued—


OTU BDI
Step Action
(SNC) alarms.
Unavailable (SNC) alarm trouble clearing procedure.
downstream trouble clearing procedure.
—end—

Procedure 2-149
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: 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
—continued—


OTU DEG
Step Action
replace the OM, LM, or equivalent.)
(Corrective action: replace OM or equivalent with correct rate,
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 ensure that the provisioned optical
completed.)
• The laser should not be locked. (Corrective action: unlock the OM or
port.)
Specifications listed in 5400 Packet-Optical Platform System Description.
(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.).
• If the far end upstream node laser and optical multiplexer tests good, go
to step 5.
—continued—


OTU DEG
Step Action
CAUTION
CAUTION
ESD procedures.
ATTENTION
5 Remove the OM or port receive fiber in accordance with Removing, deleting

Management - Module Replacement. 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/
CFP Specifications in 5400 Packet-Optical Platform System Description.
—continued—


OTU DEG
Step Action
step 22.
to step 24.
17 Click Go > Inventory and select the Physical TP tab.
—continued—


OTU DEG
Step Action
selected.
go to step 24.
23 Reconnect the receive fiber and if applicable, reinstall the OM or SFP in
—end—

Procedure 2-150
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.
—continued—


OTU LOF
Step Action
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.)
Switch technology.)
step 5.
—continued—


OTU LOF
Step Action
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).
service type.
• 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 5400
Packet-Optical Platform Configuration - Provisioning and Operating, and
then go to step 24.
—continued—


OTU LOF
Step Action

alarm).
receive 5400 Switch. Isolate and clean/repair the fiber or connector trouble in
step 22.
to step 24.
—continued—


OTU LOF
Step Action

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-151
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.
—continued—


OTU LOL
Step Action
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
— SFP/XFP/CFP and LM (or equivalent if other technology) equipment
— 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 SFP/XFP/CFP with correct rate,
— 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 5400 Packet-Optical Platform System
Description. (Corrective action: clean the transmit SFP/XFP/CFP fiber
connector, replace the SFP/XFP/CFP, and/or correct improper LBO if
not a 5400 Switch technology.)
step 5.
—continued—


OTU LOL
Step Action
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).
service type.
• 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 5400
Packet-Optical Platform Configuration - Provisioning and Operating, and
then go to step 24.
—continued—


OTU LOL
Step Action

alarm).
receive 5400 Switch. Isolate and clean/repair the fiber or connector trouble in
step 22.
to step 24.
—continued—


OTU LOL
Step Action

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-152
OTU PFSD
Probable Cause: OTU PFSD
NM Probable Cause: OTU PFSD
NM Additional Text: PreFEC 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.
—continued—


OTU PFSD
Step Action
completed.)
port.)
to step 5.
—continued—


OTU PFSD
Step Action
CAUTION
CAUTION
ESD procedures.
ATTENTION

—continued—


OTU PFSD
Step Action
step 22.
to step 24.
—continued—


OTU PFSD
Step Action
selected.
go to step 24.
23 Reconnect the receive fiber and if applicable, reinstall the OM or SFP/XFP/
CFP in accordance with Removing, deleting or installing an SFP/XFP/CFP in
5400 Packet-Optical Platform Fault Management - Module Replacement.
—end—

Procedure 2-153
OTU PFSF
Probable Cause: OTU PFSF
NM Probable Cause: OTU PFSF
NM Additional Text: PreFEC Signal Fail

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.
—continued—


OTU PFSF
Step Action
completed.)
port.)
to step 5.
—continued—


OTU PFSF
Step Action
CAUTION
CAUTION
ESD procedures.
ATTENTION

—continued—


OTU PFSF
Step Action
step 21.
to step 23.
—continued—


OTU PFSF
Step Action
selected.
go to step 23.
22 Reconnect the receive fiber and if applicable, reinstall the OM or SFP/XFP/
CFP in accordance with Removing, deleting or installing an SFP/XFP/CFP in
5400 Packet-Optical Platform Fault Management - Module Replacement.
—end—

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

TL1 String: 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

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-155
Out-of-range
Category: Equipment
Object Class: PTP
Probable Cause: OOR
NM Probable Cause: OOR
NM Additional Text:
TL1 String: OPROOR
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 Removing, deleting
—end—

Procedure 2-156
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
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-157
PDU mismatch
Category: Equipment
Object Class: Bay
Probable Cause: PDU Mismatch
NM Probable Cause: PDU Mismatch
Condition Description: The provisioned PDU's are not the same generation.
TL1 String: PDUMISMATCH
The PDU Mismatch alarm is raised when a replacement PDU is not the same
type as the PDU replaced.
This alarm occurs under the following scenarios:

• 15Tb 5430 Switch Gen2 10-feed PDU is installed in a 3.6Tb 5430 Switch
• 3.6Tb 8-feed PDU is installed in a 15Tb 5430 Switch
• One PDU is a 60 amp PDU one PDU is a 70 amp PDU
The user must install the correct PDU to clear the alarm. PDU Mismatch is
cleared when the 5430 Switch no longer detects two generations of PDU
provisioned in the chassis.

Step Action
alarm, and note the PDU that displays the alarm and note any additional text
information.
—continued—


PDU mismatch
Step Action
3 Replace the PDU with a PDU supported in the release.

• For instructions for installing legacy PDUs, see 5400 Packet-Optical
Platform Fault Management - Module Replacement.
• For instructions for installing Gen 2 PDUs see 5400 Packet-Optical
Platform 5430 15Tb Upgrade and 5400 Packet-Optical Platform 5430
PDU Upgrade.
—end—

Procedure 2-158
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-159
Power in reduction state
Object Class: PTP
Probable Cause: Power in reduction state
NM Probable Cause: Power in reduction state
NM Additional Text: Tx Blanking enabled
TL1 String: TXBLANK
The Power in Reduction State condition is raised when a coherent optical

interface has Tx Blanking enabled.
Upon detecting a Channel Contention on an interface, the system shall enable

Tx Blanking on the interface. WhenTx Blanking is enabled, the transmit laser
sets the transmit power of the laser to the hardware minimum value.
The alarm is cleared by the system when Tx Blanking is disabled.

No action is required.
—end—

Procedure 2-160
Category: Communications subsystem conflict
Object Class: ---
Probable Cause: Configuration Mismatch
Condition Description: PPP Communications System Conflict
TL1 String: ---
The system raises the PPPCommunicationConflict alarm in the following

scenarios:
1 In this scenario, the following conditions must exist. (1) At the local end,
the interface is an unnumbered PPP session, that is, it is an interface that
does not have an IP of its own and uses the Node’s management IP. (2)
At the remote end, the subtended neighbor has a PPP subnet provisioned
instead of an IP address.
If the conditions exist, and if the Remote IP learned from Internet Protocol
Control Protocol (IPCP) negotiation does not match the subnet that the
user specified in the subtended neighbor settings, then the
PPPCommunicationConflict alarm is raised.
Note 1: On the OSPF Subtended Neighbor tab, in the Neighbor
Parameters area, the user can configure either a netmask or a specific IP
address of the PPP interface at the subtended neighbor. If the user specifies
an IP address (rather than a subnet), and if the Remote IP learned from IPCP
negotiation does not match the specified IP address, then the
PPPCommunicationFailure alarm is raised.
Note 2: A PPP session to the subtended NE can be numbered with an
assigned IP Address for each PPP/OSPF Link or unnumbered using 0.0.0.0
(factory default).
2 In this scenario, the PPP session can be either numbered or unnumbered,
that is, the remote end can have a specified IP address or not. If the PPP
daemon is unable to negotiate a remote-end IP address, it auto assigns
an IP address in the 10.64.64.0/24 subnet. The alarm is raised for four
seconds and then is cleared. It is listed in the historical alarms thereafter.
The alarm is an indication to the user that the IP negotiation might not
have succeeded but the PPP link is up.

The PPPCommunicationConflict alarm is cleared as follows:

1 If the alarm was raised in scenario 1, it is cleared when changes are made
that cause the subtended neighbor’s provisioned subnet to include the
management / DCN IP address of the remote node. See Alarm clearing
procedure below.
2 If the alarm was raised in scenario 2, it is cleared automatically after four
seconds.
Note: The alarm indicates that, although the PPP link is up, the IP address
of the remote end of the PPP link was assigned at that node, and was not
negotiated. The user should investigate the configuration of the two ends of
the link and the details of the operation at each end, to determine why
negotiation failed.

Use the following steps to clear the PPPCommunicationConflict alarm if the
alarm was raised in scenario 1 as described above.
Step Action
Find out the IP address of the subtended neighbor

1 Find out the management / DCN IP address of the remote node. Take note of
the address.
Find the list of TTPs associated with the subtended neighbor
2 Login to the local node using Node Manager.
3 Click Go > Provisioning > OSPF.
4 Select the Subtended Neighbor tab.
5 Take note of the names of the inband IP ports that are associated with the
subtended node. The list of inband IP ports (for example, 1-A-12-50) is
displayed in the Details area.
Note: The subtended node must be deleted and re-provisioned. (It is not
possible to update the subtended node.) It is possible to delete the
subtended node only if it has no associated TTPs. The inband IP ports
have TTPs.
Disassociate the TTPs from the subtended neighbor
7 Select the SONET/SDH TTPs tab.
8 On the SONET/SDH TTPs tab, select the DCC subtab.
9 On the DCC subtab, select the Protocols subtab.
—continued—


Step Action
10 For each inband IP port that you took note of in step 5, perform the following
substeps.
a. Select the inband IP port in the list at the top of the screen.
b. In the Details area, in the PPP box, in the Admin State field, use the
selector and select “Locked”.
c. In the Details area, in the PPP box, clear the name of the subtended
neighbor from the Node Name field.
Delete the subtended neighbor
12 Delete the subtended neighbor.
Note: The only way to update the provisioned values for the subtended
neighbor is to delete and re-provision the subtended neighbor.
Re-provision the subtended neighbor using the proper IP address and netmask
13 Re-provision the subtended neighbor, specifying the proper IP address and
netmask, so that the management / DCN IP address that you took note of in
step 1 falls in the subnet.
14 Click Accept to save the Subtended Node profile.
Unlock the PPP admin state of the subtended neighbor
19 In the Details area, in the PPP box, to the right of the Node Name field, there
is a rectangle containing three dots (...). Click on that rectangle.
The Select Neighbor Node dialog box opens.
20 In the Select Neighbor Node dialog box, select the subtended neighbor that
you provisioned in step 13.
21 In the Details area, in the PPP box, in the Admin State field, use the selector
and select “Unlocked”.
The subtended neighbor will be re-associated with the TTPs.
—end—

Procedure 2-161
Category: Communications subsystem conflict
Object Class: ---
Probable Cause: PPP Communications Subsystem Alarm Is Set
NM Probable Cause: PPP Communications Subsystem Alarm Is Set
Condition Description: PPP Communications Subsystem Failure
Type: Alarm Condition
TL1 String: ---
The system raises the PPPCommunicationFailure alarm when the PPP link is
not up for one of the following reasons: (1) because there is a parameter
mismatch in the Link Control Protocol (LCP) parameters or in the Internet
Protocol Control Protocol (IPCP) parameters; (2) because the PPP admin
state at the remote node has been set to Locked. For example, if the
provisioned subtended-neighbor IP address of the unnumbered PPP session
does not match the Remote Side IP address.
Note 1: On the OSPF Subtended Neighbor tab, in the Neighbor

Parameters area, the user can configure either a netmask or a specific IP
address of the PPP interface at the subtended neighbor. If the user
specifies a netmask (rather than an IP address), and if the Remote IP
learned from IPCP negotiation is not in the subnetwork identified by the
specified netmask, then the PPPCommunicationConflict alarm is raised.
Note 2: A PPP session to the subtended NE can be numbered with an
assigned IP Address for each PPP/OSPF Link or unnumbered using
0.0.0.0 (factory default).
The system clears the PPPCommunicationFailure condition when changes
are made that cause the mismatched LCP or IPCP parameters on both ends
to match. For example, in the case of a mismatch in IP addresses on the
unnumbered PPP session, if the subtended neighbor is deleted and re-
provisioned with the correct IP address (the remote node’s management /
DCN IP address), then the alarm will be cleared. See Alarm clearing
procedure below.


Step Action
Find out the IP address of the subtended neighbor

1 Find out the management / DCN IP address of the remote node. Take note of
the address.
Find the list of TTPs associated with the subtended neighbor
2 Login to the local node using Node Manager.
4 Select the Subtended Neighbor tab.
5 Take note of the names of the inband IP ports that are associated with the
subtended node. The list of inband IP ports (for example, 1-A-12-50) is
displayed in the Details area.
Note: The subtended node must be deleted and re-provisioned. (It is not
possible to update the subtended node.) It is possible to delete the
subtended node only if it has no associated TTPs. The inband IP ports
have TTPs.
Disassociate the TTPs from the subtended neighbor
10 For each inband IP port that you took note of in step 5, perform the following
substeps.
a. Select the inband IP port in the list at the top of the screen.
b. In the Details area, in the PPP box, in the Admin State field, use the
selector and select “Locked”.
c. In the Details area, in the PPP box, clear the name of the subtended
neighbor from the Node Name field.
Delete the subtended neighbor
12 Delete the subtended neighbor.
Note: The only way to update the provisioned values for the subtended
neighbor is to delete and re-provision the subtended neighbor.
Re-provision the subtended neighbor using the proper IP address
13 Re-provision the subtended neighbor, specifying the management / DCN IP
address that you took note of in step 1.
—continued—


Step Action
14 Click Accept to save the Subtended Node profile.

Unlock the PPP admin state of the subtended neighbor
19 In the Details area, in the PPP box, to the right of the Node Name field, there
is a rectangle containing three dots (...). Click on that rectangle.
The Select Neighbor Node dialog box opens.
20 In the Select Neighbor Node dialog box, select the subtended neighbor that
you provisioned in step 13.
21 In the Details area, in the PPP box, in the Admin State field, use the selector
and select “Unlocked”.
The subtended neighbor will be re-associated with the TTPs.
—end—

Procedure 2-162
Object Class: MoPTP
Probable Cause: Provisioning mismatch
NM Probable Cause: Provisioning mismatch
NM Additional Text: Provisioned value outside of supported range
TL1 String: ProvMM

Step Action

the desired node.
alarm, and note the module that displays the Provisioning mismatch alarm.
CAUTION
4 In the parameters section, select the desired frequency from the Frequency-
Wavelength drop-down menu.
—continued—


Step Action
5 Click Accept.
—end—

Procedure 2-163
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.
—continued—


Step Action
5 Click Accept.
—end—

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

protected status, or Major/service affecting for ports with unprotected status
TL1 String: RFI
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.
—continued—


RDI/MS-RDI
Step Action
(SNC) alarms.
• If a SNC related alarm exists, discontinue this procedure and perform the
downstream TCP.
for this line to identify the LTE/PTE that may be generating this alarm.
—end—

Procedure 2-165
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 value of remote nodes in the Remote Nodes Per CD field.
5.
—continued—


Step Action
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.
7 From the CLI Maintenance Menu, disable the OSI and reboot the Primary
CTM.
—end—

Procedure 2-166
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: SYNC
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.
—continued—


Reference failed
Step Action
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.
—continued—


Reference failed
Step Action
13 Replace the standby CTM (CTM reset in step 12) in accordance with the
appropriate procedure in 5400 Packet-Optical Platform Fault Management -
Module Replacement:
14 Wait 20 seconds and verify that the alarm cleared at the Node Manager
workstation.
—end—

Procedure 2-167
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.
• <equipment AID>, Unsupported PDU, Please complete the fan upgrade.
• <equipment AID>, Unsupported Switch Module, Please complete the fan
upgrade.
• <equipment AID>, Unsupported Line Module, Please complete the fabric
upgrade.
• <equipment AID>, Unsupported Line Module, Please complete the PDU
upgrade.
Condition Description: The Replaceable Unit Type Mismatch alarm appears

when a replacement module, typically an optical module, 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 TSLM-12 with an OSLM-50-10G). To clear the
alarm, install the correct module or delete the existing module from inventory.
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 the following 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)
• a 10-feed Gen2 PDU is installed into a chassis without a completely
upgrading the fans
• a 5T-SM or 15T-SM is inserted into a chassis without a completely
upgrading the fans
• a >100G LM is inserted into a chassis without a completely upgraded
switch fabric
• a HDLM (OSLM-2-Flex3-WL3e) which requires High Power PDUs is
inserted into a chassis without a completely upgrading the PDUs
• a 10-feed Gen2 PDU is installed into a chassis without upgrading the
display panel
To clear the alarm, the user must install the correct module/ delete the existing
module from inventory or complete the appropriate upgrade.

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.
• If the additional text information is “<equipment AID>, Unsupported PDU,
Please complete the fan upgrade” then complete the fan upgrade and go
to step 7.
• If the additional text information is “<equipment AID>, Unsupported
Switch Module, Please complete the fan upgrade” then complete the fan
upgrade and go to step 7.
• If the additional text information is “<equipment AID>, Unsupported Line
Module, Please complete the fabric upgrade” then complete the SM
—continued—


Step Action
• If the additional text information is “<equipment AID>, Unsupported Line

Module, Please complete the PDU upgrade” then complete the PDU
• If the additional text information is “<equipment AID>, Unsupported PDU,
Please complete the Display Panel upgrade” then complete the display
panel upgrade and go to step 7.
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.
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 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 procedure listed in step 6.
6 At the node, replace the circuit pack in accordance with the appropriate
Replacement:
—end—

Procedure 2-168
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, non 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, non service affecting for a missing CTM.
• Critical, service affecting for a missing SM.
• Minor, non service affecting for a missing PDU.
• Critical, service affecting for a missing fan module.
• Minor, non 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.
—continued—


Step Action
4 At the node, replace the circuit pack in accordance with the appropriate
Replacement:
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-169
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: INT
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 a PDU with an internal fuse failure, perform the PDU remove and
replacement procedure. This event typically occurs during installation
when the power feeds to the PDU are reversed.
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 data sheet.
• Device Max Temperature is cleared when the junction temperature of the
given device on a circuit pack falls below [target set point + 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.

against an optical interface due to an unsupported equipment
configuration, the RUP additional text field is:
CLEI-<xxxxx> not supported with current equipment configuration
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
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
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
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 LM Port Complete BITS Reference PLL 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
Isolation DPFI failure

code
I01 InitFailureDetection
I02 Not Applicable
I03 STSXInternalFailureDetection
I04 STSXInputLinkWarningIsolation
I05 STSXInputLinkFailureIsolation
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
I18 SWSYNC Failure
I19 FPGA CRC Error
I20 Packet Fabric Link Degrade/Failure
I21 FramerFailureDetection
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,I21,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
Isolation CPFI failure

code
I80 Re-booting
I81 Marginal State
I82 Held in Reset
I83 Slot ID/Internal Address Failure

Table 2-4
5400 CPHF isolation mechanism codes (continued)
Isolation CPFI failure

code
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
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
I100 CTM Ethernet Communications Unstable
I101 Persistence Store sync failure
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.
—continued—


Step Action

9 If four sequential LMs are reporting RUP alarms, verify that remaining LMs
are functioning properly.
• Refer to 5400 Packet-Optical Platform Fault Management - Performance
Monitoring and perform the procedure for resetting the primary Control
and Timing Module (CTM Switch).
• If LM RUP alarms clear, replace the secondary CTM in accordance with
the appropriate procedure from 5400 Packet-Optical Platform Fault
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
Replacement:
CAUTION
Performance of this procedure may cause a traffic disruption. If
applicable, move traffic to protect in accordance with local practices,
—continued—


Step Action
11 If the replaceable unit problem circuit pack is the secondary CTM, check the
additional text information for code I101.
If additional text Then
is not I101 proceed to step step 12
is I101 I101 is a persistence store DB sync failure between
the primary and secondary CTMs. The alarm is raised
against the secondary CTM however, both CTMs must
be checked isolate the fault to the correct CTM.
Perform the following:
a. Click Go > Inventory then expand the equipment tree and select the
primary CTM.
b. Verify Operational State is Enabled, Alarm Status is N/A, Alarm
Status is blank, and Procedural Status is Providing Service.
If primary CTM Then
is ok replace secondary CTM and proceed to step 16.
not ok contact the next level of support.
ATTENTION
12 At the node, verify that the replaceable unit problem circuit pack in question
has a red LED illuminated.
13 Replace the circuit pack in accordance with the appropriate procedure as
listed above.
14 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.
—continued—


Step Action
15 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 16.

• If failure, go to step 17.
16 Verify alarm cleared at Node Manager workstation.
• If success, end this procedure.
17 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 18.
• If success, end procedure.
• If the alarm did not clear, repeat the remove and install procedure in
accordance with the applicable procedure in 5400 Packet-Optical
Platform Fault Management - Module Replacement to reseat the circuit
pack.
—end—

Procedure 2-170
SDCC/LDCC
Object Class: MoCCC
Probable Cause: ManualAdminLock
NM Probable Cause: Manual Admin Locked
NM Additional Text:
Condition Description: This alarm is raised when the transparent DCC

cross-connection is placed into a LOCKED AdminState
TL1 String: MANCCC
This alarm is raised when the transparent DCC cross-connection is placed

into a LOCKED Admin state.

Step Action
2 Click Go > Monitoring > CCC and select the channel that displays the
SDCC/LDCC alarm.
3 Verify the admin state is UNLOCKED.
—end—

Procedure 2-171
SD/SF
Category: Quality Of Service
Object Class: TTP SONET/SDH
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: SD/SF
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.
—continued—


SD/SF
Step Action
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:
action: replace the SFP/XFP/CFP, LM, or equivalent.)
(Corrective action: replace SFP/XFP/CFP or equivalent with correct rate,
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.)
SFP/XFP/CFP or equivalent, and/or correct improper LBO if not a 5400
Switch or CoreDirector Switch technology.).
step 22.
good, go to step 5.
—continued—


SD/SF
Step Action
CAUTION
CAUTION
ESD procedures.
ATTENTION
5 Remove the port receive fiber and insert the receive fiber into a test set
—continued—


SD/SF
Step Action
MSTE in alarm).
step 22.
to step 24.
alarmed port. Correct any problems that are found.
port in alarm.
—continued—


SD/SF
Step Action
selected.
go to step 24.
—end—

Procedure 2-172
SD-P/SF-P
Category: Quality Of Service
Object Class: CTP SONET/SDH
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 conditions covered in Procedure 2-171, “SD/SF”, but are applied
to the path layer.

To clear this alarm, perform the procedures described in Procedure 2-171,
“SD/SF” to clear SD-P and SF-P.
Verify that the alarm cleared.

—end—

Procedure 2-173
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: SYSBOOT
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

—end—

Procedure 2-174
Section trace mismatch
Object Class: TTP (SONET/SDH)
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.
selector indicates the port, NSA.
TL1 String: TIM
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-175
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.
—continued—


Step Action
completed.)
equivalent.)
Switch technology.)
step 25.
good, go to step 5.
ATTENTION
—continued—


Step Action

7 Clean the receive fiber in accordance with Ciena Standard Cleaning and
MSTE in alarm).
step 12.
12, go to step 14.
—continued—


Step Action

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.
—continued—


Step Action
go to step 26.
—end—

Procedure 2-176
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-177
Signaled SNCP fail to revert
Probable Cause: SSNCP Failure To Revert
NM Probable Cause:
When the S-SNCP fails to revert within the TODR window, the S-SNCP Fail
To Revert event is raised.

Step Action
the module that displays the Signaled SNCP fail to revert alarm.
go to step 4
switch.
—end—

Procedure 2-178
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,
OKAY.
signaled SNCP protection group.
9 Click Accept.
—continued—


Step Action

—end—

Procedure 2-179
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-180
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-181
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-182
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.
—continued—


Step Action
9 Click Accept.
—end—

Procedure 2-183
SNC fail to revert
NM Probable Cause:
TL1 String: FAILTORVRT.

Step Action
condition, and note the port that displays the SNC fail to revert alarm.
go to step 4
switch.
6 Click Accept.
—end—

Procedure 2-184
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.
ATTENTION
A "Home Path Not Defined" alarm can be raised against a reserved home
path SNC during regroom during BW lockout to current route or regroom
where this link is along the least cost path. Even though the bandwidth on
this link is advertised as zero, the current SNC understands there is room for
itself as it is currently there. The regroom releases the home path
reservation. To clear, issue a regroom when there is sufficient BW not in BW
lockout for the SNC to successfully setup.

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.
—continued—


Step Action
5 Ensure that the SNC is able to setup.

6 In the detail frame, click the Regroom tab and the Snc regroom parameters
dialog box is displayed.
ATTENTION
In the snc regroom parameters dialog box, the user has the option to use
the "Make current Path as Home Path" which has the opportunity to re-
establish the home path without traffic impact.
7 Click Apply.
—end—

Procedure 2-185
SNC manual regroom status
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-186
SNC resize status
Object Class: MoSncOrigEpt
NM Probable Cause: SNC resize status
NM Additional Text: <status of resize operation>
Condition Description: Report SNC resize status
Default Severity: Not applicable
TL1 String: SNCRSZ
SNC resize status reports the status of a ODUFlex SNC resizing operation.

—end—

Procedure 2-187
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-188
SNC reverse path setup failure
Object Class: SNC
NM Probable Cause: SNC Reverse Path Setup Failure
Condition Description: This alarm is raised during Back-to-back SNCP

setup when an alternate route is not available between the originating/
terminating node and the pinch node. This can be caused when one of the
following conditions occurs:
• a member port is out of service (OOS)
• there is a Link Down alarm on a member port
• there is Loss Of Signal (LOS) on a member port
• no bandwidth available
Default Severity: Dynamic:

• Warning, Non service affecting
• Minor, Non service affecting
• Major Service affecting
TL1 String: FAILTOREVSETUP

Step Action
1 To clear the alarm an alternate route has to be made available between the
originating/terminating node and the pinch node. Resolve any port, line,
bandwidth issues between the originating/terminating node and the pinch
node.
—end—

Procedure 2-189
SPLI loopback test active
Object Class: OTU TTP
Probable Cause: SPLI loopback test active
NM Probable Cause: SPLI loopback test active
NM Additional Text: The SPLI loopback test is being executed.
TL1 String: SPLILPBKACT
—end—

Procedure 2-190
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: SECU

Step Action
1 Logout from Super User account.

—end—

Procedure 2-191
TAP connection active
Object Class: TTP, PTP
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: TAP
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-192
TC-AIS
Probable Cause: TC-AIS
NM Additional Text: Tandem Connection Alarm Indication Signal

Condition Description: Tandem Connection alarm indication signal detected
(SONET) or multiplex section alarm indication signal detected (SDH)
Default Severity: Major/Service affecting for ports with unprotected status
TL1 String: AIS
TC-AIS is raised against the OSLM-2-Flex3-WL3e when using the 16QAM

mode and APS 1+1.
Refer to AIS-L/MS-AIS (TTP) on page 2-39.
—end—

Procedure 2-193
TC-LTC
Probable Cause: LTC
NM Additional Text: Loss of Tandem Connection

Default Severity: Minor/Non service affecting for ports with unprotected

status
TL1 String: LTC
TC-LTC is raised against the OSLM-2-Flex3-WL3e when using the 16QAM

mode and APS 1+1.
Refer to TCM LTC on page 2-422.
—end—

Procedure 2-194
TC-RDI
Probable Cause: TC-RDI SONET), TC-RFI (SDH)
NM Additional Text: Tandem Connection Remote Defect Indication

Condition Description: Tandem Connection Line alarm indication signal
detected (SONET) or multiplex section alarm indication signal detected (SDH)
Default Severity: Major/Service affecting for ports with unprotected status
TL1 String: RFI
TC-RDI is raised against the OSLM-2-Flex3-WL3e when using the 16QAM

mode and APS 1+1.
Refer to RDI/MS-RDI on page 2-340.
—end—

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

unprotected status
TL1 String: 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.
—continued—


TCM AIS
Step Action
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, the
manually isolated.
ATTENTION
go to step 5.
5 Reconnect fiber, reinstall OM, SFP or XFP, and recheck alarm status.
6 Replace the OM, SFP or XFP
—end—

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

unprotected status
TL1 String: 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.
downstream TCP.
—continued—


TCM BDI
Step Action
—end—

Procedure 2-197
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: 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.
—continued—


TCM DEG
Step Action
completed.)
equivalent.)
Switch technology.)
step 24.
good, go to step 5.
—continued—


TCM DEG
Step Action
CAUTION
CAUTION
ESD procedures.
ATTENTION
—continued—


TCM DEG
Step Action
receive 5400 Switch node. Isolate and clean/repair the fiber or connector
step 22.
to step 24.
port in alarm.
—continued—


TCM DEG
Step Action
18 View the Service Type box and ensure that the correct optical rate is
selected.
• If the alarm cleared, end this procedure. If the alarm did not clear, go to
step 21.
go to step 24.
—end—

Procedure 2-198
TCM delay measurement failure
Object Class: TTP, CTP
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
—end—

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

TL1 String: 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
—continued—


TCM LCK
Step Action
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-200
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.
—continued—


TCM LOF
Step Action
replace SFP/XFP/CFP, LM, or equivalent.)
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 provisioned optical rate is correct. Always lock
the port before correcting and unlock when completed.)
Switch/CoreDirector Switch technology.)
step 5.
—continued—


TCM LOF
Step Action
CAUTION
CAUTION
ESD procedures.
ATTENTION

—continued—


TCM LOF
Step Action
alarm).
step 21.
to step 23.
—continued—


TCM LOF
Step Action
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.
step 22.
—end—

Procedure 2-201
TCM LTC
Probable Cause: TCM LTC
NM Probable Cause: TCM LTC
NM Additional Text: Loss of Tandem Connection
Default Severity:
• Unprotected CA disabled: Warning
• Protected CA enabled: Minor
• Unprotected CA enabled: Major
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.
—continued—


TCM LTC
Step Action
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-202
TCM OCI
Probable Cause: TCM OCI
NM Probable Cause: TCM OCI
NM Additional Text: Open Connection Indication

TL1 String: 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-203
TCM TIM
Probable Cause: TCM TIM
NM Probable Cause: TCM TIM

Default Severity:
• Warning, Non service affecting when Consequent Actions are disabled
• Minor, Non service affecting when Consequent Actions are enabled
TL1 String: 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
—continued—


TCM TIM
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-204
Test session active
Object Class: TTP, PTP
Probable Cause: testSessionActive
NM Additional Text: Reserved for Test
Condition Description: PTP or TTP is under test
TL1 String: TSA
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-205
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 (SONET/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.
—continued—


TIM-P
Step Action
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-206
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.
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
—continued—


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 type 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-207
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: MAN
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 free-run 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.
—continued—


Step Action
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-208
Probable Cause: TODR-DOW Reversion Inhibited
NM Probable Cause:
NM Additional Text:
Default Severity: Warning, Non service affective
TL1 String: TODRREVINH
The TODR-DOW reversion inhibited standing condition is raised when all

assigned TODR profiles for the object are configured as disabled. This
standing condition is cleared when at least one assigned TODR profiles for the
object is enabled or all assigned profiles are deleted.

Step Action
alarm, and note the TODR-DOW reversion inhibited alarm.
3 Click Go > Provisioning > TODR Profiles.
4 From the list frame, select the TODR profiles for the object configured as
disabled.
5 In the detail frame, check the “Profile Enabled” check box, to enable selected
profile.
6 Click Accept.
• If the alarm did not clear, proceed to the following step.
—continued—


Step Action
8 From the list frame, select the TODR profiles for the object configured as
disabled.
9 Press “Delete” to delete the TODR profile selected in the list frame.
10 Click Accept.
—end—

Procedure 2-209
TTI Mismatch Condition
Object Class: TTP (OTUk), TTP, CTP, PT-CTP (ODUk)
Probable Cause: OTU TIM, ODU TIM
NM Probable Cause: OTU TIM, ODU TIM

Default Severity:
• Warning, Non service affecting when Consequent Actions are disabled
• Minor, Non service affecting when Consequent Actions are enabled
• Critical, Service affecting for unprotected ports
TL1 String: TIM
This alarm is raised when the trail trace identifier (TTI) value received by the
facility differs from the expected provisioned TTI value. This can be caused by
incorrect fibering or incorrect provisioning of the TTI value.
ODU/OTU TTI mismatch detection are independent of each other.

Mismatches of TTI can be declared based on the comparison of the Actual
received TTI and Expected received TTI values of the following components:
• Source Access Point Identifier (SAPI) only
• Destination Access Point Identifier (DAPI) only
• SAPI + DAPI
• Operator specific (default)
The TCM TTI mismatch detection is based on the comparison of the Actual
received TTI and Expected received TTI values of the following components:
• Source Access Point Identifier (SAPI) only (default)
• Destination Access Point Identifier (DAPI) only
• SAPI + DAPI

For CTP/PT-CTP Objects, if no cross-connection is provisioned, then the

alarm is not reported.

Step Action
1 Use the optical fiber connection information to identify the transmit and
receive sites of the alarmed signal.
2 Verify that the optical fiber connections are correct on the circuit pack that is
raising the alarm and on the upstream circuit pack.
3 From the Node Manager Configuring menu, select the appropriate OTN
TTPs, ODU CTPs, or ODU TCM CTPs Trail Trace tab and use the Trace
group box to retrieve the TTI values for the optical facilities at the transmit
network element and at the alarmed receive network element.
4 Select your next step.
If the alarm Then
clears this procedure is complete
does not clear go to step 5
5 Compare the outgoing TTI value of the transmit signal at the transmit network
element with the expected TTI value of the receive signal at the receive
network element.
If the values are different, change the expected TTI value of the receive signal
to match the outgoing TTI value of the transmit signal.
support group.
—end—

Procedure 2-210
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: SWTOSEC
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 Sync 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-211
Non-revertive switch (timing reference switch)
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: PS
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-212
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
selector indicates the port
• Major:
— Services with unprotected status and AIS forward enabled, SA.
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-213
Transmit mismatch
Object Class: MoPTP
Probable Cause: Transmit mismatch
NM Probable Cause: Transmit mismatch
NM Additional Text:
TL1 String: TXMM

Step Action
alarm, and note the module that displays the Transmit mismatch alarm.
3 Check the 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 settings at both ends are similar.
6 Click Accept.
—end—

Procedure 2-214
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-215
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.
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
—continued—


Unavailable (SNC)
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.
—continued—


Unavailable (SNC)
Step Action
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-216
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
protected status, or Critical, service affecting for ports with unprotected status
TL1 String: UNEQ (SONET/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.
—continued—


UNEQ/UNEQ-P
Step Action

side equipment at the egress end of the circuit path.
—end—

Procedure 2-217
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.
—continued—


Step Action
when completed.)
equivalent.)
step 25.
good, go to step 5.
—continued—


Step Action
CAUTION
CAUTION
ESD procedures.
ATTENTION
—continued—


Step Action
MSTE in alarm).
step 12.
go to step 14.
12, go to step 27.
—continued—


Step Action
tabs.
selected.
go to step 27.
—end—

Procedure 2-218
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-219
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.
—continued—


UPSR manual switch to protect
Step Action

—end—

Procedure 2-220
Probable Cause: UPSR Manual Switch to Work
NM Probable Cause: UPSR Manual Switch to Work
Condition Description: UPSR Manual Switch to Work

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.
—continued—


Step Action

8 Click Accept.
—end—

Procedure 2-221
Probable Cause: UPSR Force Switch to Protect
NM Probable Cause: UPSR Force Switch to Protect
Condition Description: UPSR Force Switch to Protect

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,
OKAY.
—continued—


Step Action
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-222
Probable Cause: UPSR Force Switch to Work
NM Probable Cause: UPSR Force Switch to Work
Condition Description: UPSR Force Switch to Work

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.
—continued—


Step Action

8 Click Accept.
—end—

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

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—

Procedure 2-224
Object Class: VLSR Default KBytes
Probable Cause: VLSR Default K-Bytes
NM Probable Cause: VLSR Default K-Bytes
TL1 String: VLSRKB
The system raises the VLSR Default K Byte condition if the NE continues to
detect a default K bytes for 2.5 (±0.5) seconds.

raising a default K bytes condition.
The system clears the VLSR Default K Byte condition when:

defect

Step Action
3 Select the port that displays the VLSR default k-bytes defect warning, the
source name and additional information.
—continued—


Step Action
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.
—end—


3-1
Service-affecting/non service-affecting
alarms 3-
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 3-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.

3-2 Service-affecting/non service-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 3-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/non service-affecting alarms 3-3
Table 3-1
SA/NSA alarm behavior (continued)
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 3-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.

3-4 Service-affecting/non service-affecting alarms

5400 Packet-Optical Platform
Fault Management - Alarm Clearing
Copyright© 1999-2018 Ciena® Corporation. All rights reserved.
Release 4.4
Publication: 009-3288-543
Document status: Standard
Revision A
Document release date: April 2018
CONTACT CIENA
For additional information, office locations, and phone numbers, please visit the Ciena
web site at www.ciena.com

009-3288-543 - (5400 - R4.4 - FaultMgmt-Alarm) RevA

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

009-3288-543 - (5400 - R4.4 - FaultMgmt-Alarm) RevA

Încărcat de

Drepturi de autor:

Formate disponibile

5400 Packet-Optical Platform

Fault Management - Alarm Clearing

009-3288-543 - Standard Revision A

5400 Packet-Optical Platform Fault Management - Alarm Clearing

5400 Packet-Optical Platform Fault Management - Alarm Clearing

5400 Packet-Optical Platform Fault Management - Alarm Clearing

5400 Packet-Optical Platform Fault Management - Alarm Clearing

5400 Packet-Optical Platform Fault Management - Alarm Clearing

Alarm monitoring 1-1

5400 Switch alarm and trouble clearing procedures 2-1

5400 Packet-Optical Platform Fault Management - Alarm Clearing

BLSR automatic switch to protect 2-62

5400 Packet-Optical Platform Fault Management - Alarm Clearing

5400 Packet-Optical Platform Fault Management - Alarm Clearing

Optical trace mismatch (TR control) 2-263

5400 Packet-Optical Platform Fault Management - Alarm Clearing

Signaled SNCP fail to switch 2-382

5400 Packet-Optical Platform Fault Management - Alarm Clearing

Service-affecting/non service-affecting alarms 3-1

5400 Packet-Optical Platform Fault Management - Alarm Clearing

About this document 0

This document provides 5400 Packet-Optical Platform R4.3 Fault

Release Notes and Document Updates

5400 Packet-Optical Platform Fault Management - Alarm Clearing

Document Ordering Information

Additional Product Information

5400 Packet-Optical Platform Fault Management - Alarm Clearing

New in this release and documentation

This Technical Publication supports 5400 Packet-Optical Platform (5400)

R4.4 Draft Issue 2

5400 Packet-Optical Platform Fault Management - Alarm Clearing

5400 Packet-Optical Platform Fault Management - Alarm Clearing

About this manual

The CoreDirector Family of Multiservice Switches are hereinafter referred to

5400 Packet-Optical Platform Fault Management - Alarm Clearing

– Digital optical test set usage

• 5400 Node Manager- refer to 5400 Packet-Optical Platform Node

5400 Packet-Optical Platform Fault Management - Alarm Clearing

5400 Switch alarms

Environmental alarm An alarm caused by a condition relating to an enclosure in which the

Equipment alarm An alarm caused by an equipment fault.

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

5400 Packet-Optical Platform Fault Management - Alarm Clearing

If a LED is illuminated, further isolation can be accomplished opening the

5400 Packet-Optical Platform Fault Management - Alarm Clearing

5400 Switch alarm and trouble clearing

Related alarm clearing procedures:

A-SNCP automatic switch

A-SNCP fail to revert

A-SNCP fail to switch

A-SNCP forced switch to protect

A-SNCP forced switch to working

A-SNCP lockout of protect

A-SNCP manual switch to protect

A-SNCP manual switch to working

Adjacency discovery unreliable

All provisioned external authentication servers unavailable

All redundant sync units failed

5400 Packet-Optical Platform Fault Management - Alarm Clearing

All references failed