Table Of Contents
Release Notes for Cisco ONS 15454 SDH Release 7.2.2
Changes to New Features and Functionality
CSCec42769 Database Corruption with ONS 15454 SDH Release 4.0, 4.0.1, 4.1
Maintenance and Administration
CSCdv10824: Netscape Plugins Directory
Common Control and Cross Connect Cards
Active Cross Connect or TCC2/TCC2P Card Removal
Interoperability with SONET DS3i-N-12
SONET and SDH Card Compatibility
CSCse85355 CSCsd52665 CSCsd56328
Database Restore on an MS-SPRing
Active XCVXL or TCC2/TCC2P Card Removal
Resolved Caveats for Release 7.2.x
Maintenance and Administration
New Features and Functionality
New Software Features and Functionality
IEEE 802.17b Based Resilient Packet Ring (RPR)
Network Circuit Automatic Routing Overridable NE Default
Fibre Channel and FICON Interface Interoperability Enhancements
Cisco Product Security Overview
Reporting Security Problems in Cisco Products
Obtaining Technical Assistance
Cisco Technical Support Website
Definitions of Service Request Severity
Obtaining Additional Publications and Information
Release Notes for Cisco ONS 15454 SDH Release 7.2.2
Note
The terms "Unidirectional Path Switched Ring" and "UPSR" may appear in Cisco literature. These terms do not refer to using Cisco ONS 15xxx products in a unidirectional path switched ring configuration. Rather, these terms, as well as "Path Protected Mesh Network" and "PPMN," refer generally to Cisco's path protection feature, which may be used in any topological network configuration. Cisco does not recommend using its path protection feature in any particular topological network configuration.
August 2007
Release notes address closed (maintenance) issues, caveats, and new features for the Cisco ONS 15454 SDH multiplexer. For detailed information regarding features, capabilities, hardware, and software introduced with this release, refer to the "Release 7.2" version of the Cisco ONS 15454 DWDM Installation and Operations Guide; and the "Release 7.2" version of the Cisco ONS 15454 SDH Procedure Guide; Cisco ONS 15454 SDH Reference Manual; Cisco ONS 15454 SDH Troubleshooting Guide; and Cisco ONS 15454 SDH TL1 Command Guide. For the most current version of the Release Notes for Cisco ONS 15454 Release 7.22, visit the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/ong/15454sdh/sdhrelnt/index.htm
Cisco also provides Bug Toolkit, a web resource for tracking defects. To access Bug Toolkit, visit the following URL:
http://www.cisco.com/cgi-bin/Support/Bugtool/launch_bugtool.pl
Contents
Resolved Caveats for Release 7.2.x
New Features and Functionality
Cisco Product Security Overview
Obtaining Technical Assistance
Obtaining Additional Publications and Information
Changes to the Release Notes
This section documents supplemental changes that have been added to the Release Notes for Cisco ONS 15454 SDH Release 7.2 since the production of the Cisco ONS 15454 SDH System Software CD for Release 7.22.
The following changes have been added release notes 7.22.
Changes to New Features and Functionality
The following caution has been added:
LMP Caution on page 46.
Caveats
Review the notes listed below before deploying the ONS 15454 SDH. Caveats with tracking numbers are known system limitations that are scheduled to be addressed in a subsequent release. Caveats without tracking numbers are provided to point out procedural or situational considerations when deploying the product.
Hardware
CSCsf19530
Fan tray array board exceeds 60dbA acoustic noise limit. No workaround available. This issue will be resolved in a future release.
CSCed18803
Rarely, the non-enhanced Muxponder unit does not pass Jitter Tolerance test from Trunk port to client port as per ITU-T G.825, 2 Mb/s mask, at the 10 Hz specific setpoint. The Muxponder should be configured with G.709 Off, FEC Off and Trunk signal provided by external Jitter test box, and the unit client port output monitored for errors, to see this issue. This issue will not be resolved. Note, however, that in normal network configurations the muxponder is operated with G.709 and FEC turned on, and the jitter tolerance tests pass.
CSCuk48503
Under specific conditions the non-enhanced MXPD does not pass the Telcordia GR-253/G.825 Jitter generation mask test on 10G TX Trunk port. The 2.5 G TX Client jitter generation is always within mask and does not exhibit this issue. This occurs only when, in SONET mode, there is no FEC, no G.709, and client interfaces are looped back, with non-synchronous clocking, and the jitter testbox TX connected to Trunk RX port, while the jitter testbox RX is connected to the Trunk TX port. The jitter testbox TX clock recovers from RX with an additional 5 ppm offset added. This issue will be resolved in a future hardware release.
CSCea78210
The TXP_MR_2.5G and TXPP_MR_2.5G cards do not support TX Optical power performance monitoring on the trunk port. To see this, go to the Optics Performance Monitoring tab of the TXP_MR_2.5G or TXPP_MR_2.5G card, and select the trunk port. TX Optical Pwr is not shown. This is as designed.
CSCdw92634
SDH DS3-I and E3 electrical cards only support a VC4 J1 trace string setting for all VC4s together. You cannot set the J1 byte for individual VC4s. This issue is a limitation of hardware.
Note
VC3 J1 strings can be set individually, but the optical cards cannot monitor the VC3 J1 string.
CSCdw14501
Interconnection Equipment failure alarms may be generated at 55 degrees C, and 72 volts. When the operating environment is at 55 degrees C and 72 volts, interconnection equipment failure alarms for the following cards can occur:
•
STM16SH
•
STM64LH
•
STM16LH
The alarms could potentially occur on any of these boards, as well: OC48AS, GigE, OC192 or OC192LR. This issue will not be resolved.
Upgrades
CSCec42769 Database Corruption with ONS 15454 SDH Release 4.0, 4.0.1, 4.1
CautionBefore you upgrade to Release 7.x from Release 4.0, 4.0.1, or 4.1, you must read this caveat and run the SDH Circuit Repair Utility (VcCheck) provided on the software CD (also available on CCO).
The XCVXL card on the ONS 15454 SDH allows the intermixing of VC12 and VC3 payloads within a single VC4. When a VC4 contains only one VC12 tributary and at least one VC3 tributary and the VC12 is deleted, the database becomes corrupt.
The database load process on the ONS 15454 SDH occurs during a TCC2/TCC2P reboot, TCC2/TCC2P protection switch, software activation, or database restore. When the database is loaded containing this corruption the load process fails, causing the corrupt database to be deleted from the TCC2/TCC2P flash memory. The previous saved database is then loaded instead. When all saved databases on a TCC2/TCC2P contain the corruption, the TCC2/TCC2P will load with the default provisioning, and all existing provisioning will be lost.
If this issue occurs you will see a loss of either some or all provisioning after a TCC2/TCC2P switch or reset.
To ensure that your network is not vulnerable to this issue, you must first determine if the issue already exists within your network, and if so, correct it. You can detect the issue by using the SDH Circuit Repair Utility (VcCheck) provided on the ONS 15454 SDH Release 4.1.3, 4.6.x, 5.x, 6.x, or 7.x software CDs. The VcCheck tool is also available for download from CCO. Once you have alleviated immediate risk from the issue, you must upgrade to Release 7.x, Release 6.x, Release 5.x, Release 4.6.1, or maintenance Release 4.1.3 (or any later release) to avoid further risk.
The VcCheck utility and its associated README file (in the same directory with the tool) provide details on how to temporarily alleviate this issue before upgrading to a release in which the issue is resolved.
This issue is resolved in Releases 4.6 and later, and in maintenance Releases 4.1.3 and later (caveated herein because of the upgrade issue).
Maintenance and Administration
CautionVxWorks is intended for qualified Cisco personnel only. Customer use of VxWorks is not recommended, nor is it supported by Cisco's Technical Assistance Center. Inappropriate use of VxWorks commands can have a negative and service affecting impact on your network. Please consult the troubleshooting guide for your release and platform for appropriate troubleshooting procedures. To exit without logging in, enter a Control-D (hold down the Control and D keys at the same time) at the Username prompt. To exit after logging in, type "logout" at the VxWorks shell prompt.
Note
In releases prior to 4.6 you could independently set proxy server gateway settings; however, with Release 4.6.x and forward, this is no longer the case. To retain the integrity of existing network configurations, settings made in a pre-4.6 release are not changed on an upgrade to Release 7.x. Current settings are displayed in CTC (whether they were inherited from an upgrade, or they were set using the current GUI)
CSCse83671
In Multishelf configuration, Node Controller (NC) can be changed from Ethernet Switch to Stand Alone with equipped Subtended Shelf Controller (SSC). CTC user is allowed to change the NC from Ethernet Switch mode to Stand Alone. When the NC is up again in Stand Alone mode the SSC shelf is lost. No workaround available. This issue will be resolved in a future release.
CSCse53347
8.0 SW Activation fails in Multishelf configuration. Activating 8.0 SW release or next releases when previous release is 7.01. Upgrades from 7.01 to 9.0 shall require an intermediate upgrade to 7.04, 7.2, 7.22 or 8.0. Workaround is to extract one of the SSC TCCs and activate. This issue will be resolved in a future release.
CSCse04064
Activate revert with 2 TCC sometimes fails after displaying it succeeded. During SW release Activate/Revert. No workaround available. This issue will be resolved in a future release.
CSCsd91724
MSTP MS SW Activation fails. No internal LAN redundancy and the only Ethernet cable are
connected to Standby TCC of subtended shelf.
Workaround:
Step 1
Connect internal LAN redundancy.
Step 2
Switch Active with Stand-By TCC in Node Controller Shelf
This issue is expected to be resolved in future releases.
CSCsd53751
Unable to provision the AREA ID with circuits routed. When there is an active circuit between the nodes, CTC and TL1deny provisioning of an OSPF Area ID. TL1 rejects the command with a proper error message, but CTC needs modification to make the error message appropriate. No workaround available. This issue will be resolved in Release 8.0.
CSCse90736
SSC connected via MS-ISC is not discovered by NC. After activation from previous Multishelf releases to 7.02
Workaround:
Step 1
Reset the active NC TCC,
Step 2
Reset both MS-ISC,
Step 3
Reset the TCC2s boards,
Step 4
Reset MS-ISC-100 boards.
This issue will be resolved in a future release.
CSCse98553
The cards plugged in the sub shelves are reported as "not present" even if they are plugged and working. MSTP Multishelf NE. This may occur after a reset of the TCCs of the Node Controller (i.e. during SW activate or DB restore)
Workaround: SW reset the Active TCC of the subtended shelves.
This issue will be resolved in a future release.
CSCsf09350
The cards plugged in the sub shelves are reported as "not present" even if they are plugged and working. MSTP Multishelf NE. This may occur after a reset of the TCCs of the Node Controller (i.e. during SW activate or DB restore) .
Workaround: SW reset the Active TCC of the subtended shelves. This issue will be resolved in a future release.
CSCsf22525
A link fails while connecting an SSC to NC in a multishelf environment. Changing the node configuration from single shelf to multishelf and assigning the SSC role, the SSC will be able to connect to NC only after 6 minutes. No workaround available. This issue will be resolved in a future release.
CSCse36337
When a Server Trail is created on a 1+1 Protection Group, the Node's database gets deleted, and the Node goes for continuous reboot. No workaround available. This issue will be resolved in Release 7.22, 8.0.
CSCse89357
CTC Network view shows up without any Nodes. The initialization of the network view sometimes would get interrupted with exceptions. Workaround is to relaunch CTC. This issue will be resolved in a future release.
CTC Network view shows up without any Nodes. The initialization of the network view sometimes would get interrupted with exceptions. Workaround is to relaunch CTC. This issue will be resolved in a future release.
CSCse96077
On an IO port with this issue false TCAs that indicate line or traffic problems are raised every 15 min after the 15 min pm report. There are no alarms with the associated ports. Traffic is not affected. In Release 7.2, during a very short period when the defect is present (less than 1 sec), false TCAs might be raised. This can be reproduced by either removing or then reinserting the card, or by a small burst of defects.
The cards affected are:
•
ONS 15454 DS1, DS1_E1_56, DS3 (including DS3, DS3N, DS3E, DS3NE), DS3_EC1, DS3XM.
•
DWDM, E1, E1_42, OC3-8, OC12-4, MRC-12, OC192XFP; and ONS 15310-CL and ONS 15310-MA IO ports.
There are two workarounds:
•
Place the affected ports in OOS-DSBLD and then back to IS. This clears the problem for the specific port on the card, but the traffic will be down during the period of OOS-DSBLD.
•
Soft reset the card with problem ports. This clears the problem on all ports on the card. Soft reset might cause a protection switch if any circuit path on the card or any port on the card or the card itself is in a protection group. Note that the protection switch itself might cause a defect burst, which might introduce false TCAs. Before resetting the card, check if any circuit, port, or card is in a protection group. If there is path protection, BLSR, 1+1 or 1:1/1:N protection on the card, lock the protection using a switch command (for example, LOCKOUT/LOCKON) available to users before you reset the card ensuring that no protection switch occurs during soft reset, and that traffic will not be affected. For a card with no protection type, simply soft reset the card and traffic will not be affected.
This issue will be resolved in a future release.
CSCsd92505
Traffic hit from 100mS to 300ms might occur during unit SW reset or firmware upgrade.
The problem is present on OPT-PRE and OPT-BST with the vendorID=1025, visible from the Inventory panel of the CTC.
The problem appears under the following conditions:
OPT-PRE
Control Gain: Always OK
Control Power: Hits below -33dBm
OPT-BST
Control Gain: Might have hits for gain > 17 dB and Pin < -10 dBm (3chs @ ~ -14dBm)
Control Power: N/A
No workaround available. This issue is expected to be resolved in 7.01 and above, except 7.2.
CSCsh21989
Clearing of HP PPJC/NPJC-PDET PM counters is not working. HP PPJC/NPJC-PDET PM counters will not be reinitialized when clear command is executed.
Step 1
Have one STM1_8 card and one any other card.
Step 2
Create a circuit between STM1_8 and other card.
Step 3
Enable PCVC4Mon# to 1 and enable IPPM on STM1_8 card.
Step 4
Check for pdet params in PM, wait for 15 to 20 mins.
Step 5
Do clear params, once this is done pdet params in PM must be reinitialized.
This issue will be resolved in a future release.
CSCsd47626
Bulk deletion of Low Order Server Trails can cause a TCC card to reset. To avoid this delete low order server trails one by one. This issue will be resolved in Release 8.0.
CSCsc64015
Rarely, in an STM 1+1 configuration with VC3 traffic from one E3 to another where the source node has a 1:1 protection group, if you perform a parallel upgrade from Release 5.0.2 to 7.0, E3 traffic might incur a 13.2 ms hit. This issue will be resolved in a Release 8.0.
CSCeh84908
A CTC client session can disconnect from an ONS node during simultaneous deletion of large numbers of VT level circuits (3000+). Connectivity to the node will recover without any user action. If the condition persists, restart the CTC session to reconnect. This issue is under investigation.
CSCin92246
When one of the underlying connections of a circuit moves to the Unlocked-disabled, failed state, CTC treats the Unlocked-disabled, failed state as out of service and interprets part of the circuit to be out of service, or Locked. However, this is incorrect, as none of the underlying connections is in a Locked state. The result is that the circuit state is displayed as Locked[Partial], even though all of the underlying connections are technically Unlocked. This issue will be resolved in Release 8.0.
CSCin90057
A signal degrade or signal failure is not reported when you inject bit errors into the line for an E3 card. To see the SD or SF, inject a code violation error instead. This issue will not be resolved.
CSCeh92201
When you create a bidirectional MS-SPRing-SNCP IDRI circuit using autorouting and select the PCA option for secondary spans, the circuit is created over working MS-SPRing spans and does not use PCA spans. To enforce the use of the PCA option, provision the circuit using manual routing. This issue will not be resolved.
CSCef53317
A traffic hit can occur during a clock reference switch. To see this issue, complete the following steps.
Step 1
Set up two ONS 15454 SDH nodes with STM16 SNCP (call the nodes STM16-1 and STM16-2).
Step 2
Set up two ONS 15454 SDH nodes with MXP_MR_2.5G_10G (call the nodes MXP-1 and MXP-2).
Step 3
Place MXP-1 and MXP-2 in Transparent Termination Mode.
Step 4
Ensure that STM16-1 is connected to MXP-1 client 1.
Step 5
Ensure that STM16-2 is connected to MXP-2 client 1.
Step 6
Ensure that MXP-1 trunk is connected to MXP-2 trunk.
Step 7
Connect a traffic generator to MXP_MR_2.5G_10G Port 3 (client) of MXP-1 and feed a PRC clock.
Step 8
Set MXP-1 Clock Reference 1 to MXP_MR_2.5G_10G Port 3, leaving the other two clock references as INTERNAL.
Step 9
Provision circuits such that a combination of VC4-4C, VC12, VC3 and VC4 traffic flows between STM16-1 and STM16-2 through MXP-1 and MXP-2.
Step 10
Gradually inject increasingly negative frequency offset through the traffic generator, in steps of 3 ppm, where you perform the next decrement step only when the node returns to NORMAL state.
When the clock offset reaches around 17 ppm, Clock Reference 1 fails and MXP-1 switches to Clock Reference 2. During the clock switch a traffic hit might occur for less than one second. The same is behavior can occur when injecting positive frequency offset. This issue will not be resolved.
CSCuk49106
The amplifier gain set point shown by CTC and the actual measured amplifier gain differ. The following steps illustrate this issue.
Step 1
Reduce the insertion loss of the span just before the amplifier.
Step 2
Execute the APC procedure.
The APC procedure does not check consistency between the gain set point and the real gain, but rather only verifies the amplifier total output power. As a workaround, manual setting can be performed to align these values, although the discrepancy does not impact the normal functioning of the amplifier. This issue will not be resolved.
CSCef54670
The SQUELCHED condition is not raised when a non-enhanced MXP card is in MS termination mode. To see this issue perform the following steps.
Step 1
Set up one ONS 15454 SDH node with MXP_2.5G_10G (MXP-1).
Step 2
Provision MXP-1 Port 1 (client) with any payload.
Step 3
Set MXP-1 Port 1 (client) and Port 5 (trunk) to the UNLOCKED state.
LOS and LOS-P alarms are reported on MXP-1 Port 1 (client). The SQUELCHED condition is not reported on MXP-1 Port 1 (client) because AIS is sent out the client port instead. This is as designed.
CSCef05162
Clearing the displayed statistics for a port will also clear the displayed history for that port. Clearing the displayed statistics for all ports will also clear the displayed history for all ports. There is no warning message from the TCC2. If History information is to be retained, do not clear displayed statistics for any port without first documenting the displayed history information for the associated port. This issue will not be resolved.
CSCef29516
The ALS pulse recovery min value is 60 instead of 100. If this occurs, increase the value to 100. This issue will not be resolved.
CSCeb36749
In a Y-Cable configuration, if you remove the client standby RX fiber; a non-service affecting LOS is raised, as expected. However, if you then remove the trunk active RX fiber; a non-service affecting LOS-P is raised, but the previously non-service affecting LOS on the client port is now escalated to a service affecting alarm, in spite of no traffic having been affected. This issue will not be resolved.
CSCee82052
After setting the node time (either manually or via NTP) you must wait for the endpoint of the interval to be reached before the end time will reflect the recently-set node time. Until this has occurred, the date time stamp for the end of the retrieved interval remains 12/31/69. This issue will not be resolved.
CSCeb39359
When changing NE timing from External or Mixed to Line timing, a Transient IEF alarm might be reported against the standby XC10G. This issue will be resolved in a future hardware release.
CSCdz62367
When replacing a failed working E1-42 card in a 1:1 or 1:N protection configuration with the protect card carrying the switched traffic, bit errors, less than 50ms in duration, are possible on the activated protection card. This issue will not be resolved.
CSCdy10030
CVs are not positively adjusted after exiting a UAS state. When a transition has been made from counting UAS, at least 10 seconds of non-SES must be counted to exit UAS. This issue will not be resolved.
CSCdx35561
CTC is unable to communicate with an ONS 15454 SDH that is connected via an Ethernet craft port. CTC does, however, communicate over an SDCC link with an ONS 15454 SDH that is Ethernet connected, yielding a slow connection. This situation occurs when multiple nodes are on a single Ethernet segment and the nodes have different values for any of the following features:
•
Enable OSPF on the LAN
•
Enable Firewall
•
Craft Access Only
When any of these features are enabled, the proxy ARP service on the node is also disabled. The ONS 15454 SDH proxy ARP service assumes that all nodes are participating in the service.
This situation can also occur immediately after the aforementioned features are enabled. Other hosts on the Ethernet segment (for example, the subnet router) may retain incorrect ARP settings for the ONS 15454 SDHs.
To avoid this issue, all nodes on the same Ethernet segment must have the same values for Enable OSPF on the LAN, Enable Firewall, and Craft Access Only. If any of these values have changed recently, it may be necessary to allow connected hosts (such as the subnet router) to expire their ARP entries.
You can avoid waiting for the ARP entries to expire on their own by removing the SDCC links from the affected ONS 15454 SDH nodes. This will disconnect them for the purposes of the proxy ARP service and the nodes should become directly accessible over the Ethernet. Network settings on the nodes can then be provisioned as desired, after which the SDCC can be restored. This issue will not be resolved.
CSCdy11012
When the topology host is connected to multiple OSPF areas, but CTC is launched on a node that is connected to fewer areas, the topology host appears in CTC, and all nodes appear in the network view, but some nodes remain disconnected. This can occur when the CTC host does not have routing information to connect to the disconnected nodes. (This can happen, for example, if automatic host detection was used to connect the CTC workstation to the initial node.)
CTC will be able to contact the topology host to learn about all the nodes in all the OSPF areas, but will be unable to contact any nodes that are not in the OSPF areas used by the launch node. Therefore, some nodes will remain disconnected in the CTC network view.
To work around this issue, if no firewall enabled, then the network configuration of the CTC host can be changed to allow CTC to see all nodes in the network. The launch node must be on its own subnet to prevent network partitioning, and craft access must not be enabled. The CTC host must be provisioned with an address on the same subnet as the initial node (but this address must not conflict with any other node in the network), and with the default gateway of the initial node. CTC will now be able to contact all nodes in the network.
If a firewall is enabled on any node in the network, then CTC will be unable to contact nodes outside of the initial OSPF areas. This issue will not be resolved.
CSCdy57891
An LOP-P alarm can be inadvertently cleared by an LOS that is raised and cleared. On older STM-N cards, when an LOP condition and an LOS condition are both present on the input, an LOS will be raised. However, upon clearing the LOS with the LOP still present, the LOP alarm is not raised. An AIS-P condition will be visible. This issue will not be resolved.
CSCdw38283
If a node has one good BITS reference and is running in a normal state, and you configure a second BITS reference, then reconfigure the second reference within 30 seconds of applying the first configuration, the node will enter FAST START SYNC mode. To avoid this problem, wait a minute before configuring the second reference a second time. This issue is a hardware limitation, and there are no current plans to resolve it.
CSCdw23208
Table 1 summarizes B1, B2, and B3 error count reporting for SDH optical cards. Note that not all reporting is done according to ITU specifications. In particular, ITU specifies error counts for B1 and B3 as the number of blocks with errors (refer to ITU-T G.826 for paths and ITU-T G.829 for RS and MS).
CSCdw82689
After creating 509 VLANs and provisioning many Ethernet circuits, Ethernet circuit provisioning can become very slow, or possibly fail. Ethernet traffic may also incur an outage of a few minutes. To avoid this problem, delete any VLANs that are created but not used, and do not recreate them. There is no resolution planned for this issue.
CSCdv10824: Netscape Plugins Directory
If you use CTC, JRE, and the Netscape browser with a Microsoft Windows platform, you must ensure that any new installation of Netscape uses the same Netscape directory as the previous installation did, if such an installation existed. If you install Netscape using a different path for the plugins directory, you will need to reinstall JRE so that it can detect the new directory.
"Are you sure" Prompts
Whenever a proposed change occurs, the "Are you sure" dialog box appears to warn the user that the action can change existing provisioning states or can cause traffic disruptions.
Common Control and Cross Connect Cards
CSCse32518
TCCs intermittently restart. Noise or communication problem in the TCC to fan tray communication channel that occurs during normal operation causes TCC card to reset. Workaround is to replace fan tray. This issue will be resolved in a future release.
CSCsg40898
SHELF-COMM-FAIL after upgrade to 8.0 and TCC SW reset. Multi-shelf in secure mode from 7.2 to 8.0 releases. Activation is successful. SW reset SSC active TCC. Wait to complete reboot. SW reset NC active TCC. The SSC is lost, SHELF-COMM-FAIL raises. No workaround available. This issue will be resolved in a future release.
CSCsd88118
MSTP MS in secure mode. SSC duplicate alarm and loss of SSC. Connecting any host with the same IP address of the internal shelf subnet (192.168.190.0).
Workaround: Disconnect the host and SW reset of the NC active TCC. This issue will be resolved in a future release.
CSCse02598
Multishelf, MSTP. The FDI/PMI is cleared and the alarms which were suppressed by NLAC are instead raised back as alarms. SW Reset the active TCC of the Node Controller. No workaround available. This issue will be resolved in a future release.
CSCse31217
The Standby TCC continuously reboots. MSTP Multishelf NE. Change any sub shelf to stand alone shelf via LCD.
Workaround: Unplug the standby TCC before changing multishelf role. After the active TCC has come back as stand alone (at least 2 min.) re-plug the second TCC.
This issue is expected to be resolved in future releases.
CSCse77589
SSC connectivity lost after removing the LAN cable from TCC2P LAN port. Remove the LAN cable from LAN port. It is expected SSC to be reachable via routing with TCC on slot 11 (standby). A COMM-SHELF alarm is reported from CTC and the connectivity to the SSC is lost (i.e. all the boards are greyed out). No workaround available. This issue will be resolved in a future release.
CSCsf14879
TCC of Node Controller reloads continuously. Multishelf MSTP NE with several DCC/GCC/OSC provisioned (approx. more than 10) involving cards plugged in subtended shelves. No workaround available. This issue will be resolved in a future release.
CSCsg27342
The Ethernet front port on the TCC has the LEDs turned off (no activity no link). Multishelf MSTP NE after a TCC reload for any reason (i.e. DB restore, SW activate, SW reset).
Workaround: SW reset the TCC suffering the fault. This issue will be resolved in a future release.
CSCsg32221
The subtended shelf is disconnected and a SHELF-COMM-FAIL alarm is correctly reported. Multishelf MSTP NE after a reload of the TCC of the Node Controller for any reason (DB restore, SW activate). No workaround available. This issue will be resolved in a future release.
CSCsb62127
A DCC Link discovered by CTC, can show incorrect bandwidth. When a DCC tunnel is created using two different OC cards, like OC12 and OC48 at its ends, CTC Network view shows incorrect bandwidth. Such a provisioning is a provisioning mistake. No workaround available. This issue will be resolved in a future release.
CSCse53413
Creation of Low Order Server Trails (like VC12 or VT1.5) might reset the active TCC. No workaround available. This issue is expected to be resolved in 7.22, 8.0.
CSCse53413
Creation of Low Order Server Trails (like VC12 or VT1.5) might reset the active TCC. No workaround available. This issue is expected to be resolved in 7.22, 8.0.
CSCec82148
Rarely, traffic hits can occur on TCC2/TCC2P card removal. To avoid this issue, remove the card quickly. To recover from this issue, soft reset the TCC2/TCC2P card. This issue will not be resolved.
Ethernet Polarity Detection
The TCC2/TCC2P does not support Ethernet polarity detection. The TCC+ and TCCI both support this feature. If your Ethernet connection has the incorrect polarity (this can only occur with cables that have the receive wire pairs flipped), the TCC+/I will work, but the TCC2/TCC2P will not. In this event, a standing condition, "LAN Connection Polarity Reverse Detected" (COND-LAN-POL-REV), will be raised (a notification will appear on the LCD, and there will be an alarm raised). This issue will most likely be seen during an upgrade or initial node deployment. To correct the situation, ensure that your Ethernet cable has the correct mapping of the wire wrap pins. For Ethernet pin mappings, consult the user documentation.
Active Cross Connect or TCC2/TCC2P Card Removal
Active cross connect or TCC2/TCC2P cards should not be removed. If the active cross connect or TCC2/TCC2P card must be removed, to minimize network interruption you can first perform an XCVXL side switch and then remove the card once it is in standby, or you can perform a lockout on all circuits that originate from the node whose active cross connect or active TCC2/TCC2P will be removed (performing a lockout on all spans will also accomplish the same goal).
CautionIf you mistakenly remove an active cross connect or TCC2/TCC2P card and you subsequently lose traffic on some interface cards, you may need to physically reset these cards if they fail to regain traffic.
Optical IO Cards
CSCee17695 and CSCed26246
Rarely, an STM1-8 card might fail to read MFG EEPROM and will show MEA in CTC. This issue can be reproduced by power cycling the node several times, by quickly removing and reinserting a fuse, or when the fuse is removed for several minutes and then replaced; however, the issue is not likely to be due to the power cycling. If a card enters this state, remove and reseat it, or cycle power again to recover STM1-8 operation. This issue will not be resolved.
CSCdw44431
Cisco ONS 15454 optical cards are not provisioned for particular path labels (C2 bytes). Consequently, they cannot raise a PLM condition. However, the ONS 15454 electrical card that terminates traffic ensures that the C2 byte is correct for the type of traffic carried. If the C2 byte is incorrect, this card raises a PLM condition that is reported against the optical port of ingress. An optical card will not raise a PLM against traffic that passes through a node, though it will appear to raise a PLM against traffic with the wrong C2 byte that is terminated on an electrical card within the node. This issue will not be resolved.
Note
Optical cards do ensure that the C2 byte is nonzero (Equipped), and will raise a UNEQ condition if the C2 byte is 0 (Unequipped).
Electrical IO Cards
CSCsh15211
Pump unframed E1 traffic for E1 port whose frame format is E1_MF.LOF will be raised as expected and SF led will be glown.Now change the format to UNFRAMED in CTC.But still the SF led will be glown. Workaround is Soft reset of the card. This issue will be resolved in Release 8.01.
CSCse96077
On an IO port false TCAs that indicate line or traffic problems might be raised every 15 min after the 15 min pm report. There are no alarms with the associated ports. Traffic is not affected.
In Release 7.2, during a very short period when the defect is present (less than 1 sec), false TCAs might be raised. This can be reproduced by either removing and then reinserting the card, or by a small burst of defects.
The cards affected are: DS3i, DWDM, E1, E1_42, STM1-8, STM4-4, MRC-12, STM64XFP
There are two workarounds:
Place the affected ports in locked,disabled and then back to Unlocked. This clears the problem for the specific port on the card, but the traffic will be down during the period of locked,disabled.
Soft reset the card with problem ports. This clears the problem on all ports on the card.
Soft reset might cause a protection switch if any circuit path on the card, or any port on the card or the card itself is in a protection group. Note that the protection switch itself might cause a defect burst, which might introduce false TCAs. Before resetting the card, check if any circuit, port, or card is in a protection group. If there is SNCP, MSSP, 1+1 LMSP or 1:1/1:N protection on the card, lock the protection using a switch command (for example, LOCKOUT/LOCKON) available to users before you reset the card ensuring that no protection switch occurs during soft reset, and that traffic will not be affected. For a card with no protection type, simply soft reset the card and traffic will not be affected.
This issue will be resolved in a future release.
CSCsd71602
On a four node STM16 SNCP with E1-42 cards set up in a 1:N protection group on a single node, if slots 1, 2, and 4 are designated as working cards, with slot 3 as the protect card, and with circuits provisioned on slot 1 ports, and then you fail the working card on slot 1 and the protect card takes over, and finally you alter the protection group by first removing and then replacing the working card in slot 2, CTC might fail to deny on a subsequent attempt to delete the entire protection group, in spite of the need for the protect card to continue to manage the traffic for the failed card in slot 1. Deletion of the protection group should be denied, because it can result in a loss of traffic. This issue will be resolved in a future release.
CSCeg80233
Long traffic hits can occur on E1-42 when using cross connect FIT cards. This can occur when, on the FIT card, you toggle the 155 mhz clock going to the E1-42 cards to the off position. This issue cannot be resolved.
CSCeg81428
Rarely, a long traffic hit (117 ms) can occur on E1-42 after an XC side switch. In multinode BLSR setups, switching the cross connect cards repeatedly might cause traffic hits greater that 60 ms. To avoid this issue side switch the XC only when needed (and not repeatedly). This issue will not be resolved.
CSCeg19255
Rarely, DS3I VC3 traffic takes a hit greater than 60 ms during a cross connect card soft reset. This issue will not be resolved.
CSCef67059
Bit errors can occur on E1-42 line cards passing traffic, when other E1-42 line cards are initially inserted into adjacent slots. Specifically, inserting line cards into adjacent slots or 1:N protect slots (Slots 3 and 15) can cause hits on Ports 1-14. Also, when the card in the 1:N protection slot is passing traffic, inserting E1-42 line cards into adjacent slots can cause bit errors. The bit errors characteristically last less than 5 ms. After the card is inserted, no further bit errors occur. Ports 15-42 behave differently. No bit errors occur on a line card residing in a non-1:N slot if adjacent line cards are inserted. Bit errors will only occur for these ports if line cards are inserted into the 1:N protection slots (Slots 3 and 15). Bit errors might also occur if traffic passes through the 1:N protected slot, and you insert a line card into any other working slot. A future version of E1-42 hardware will resolve this issue.
Interoperability with SONET DS3i-N-12
When provisioning circuits in SDH to interoperate with SONET DS3i-N-12, you must create a VC4 containing VC3s as a payload in the exact order in which they will attach to port groups on the SONET side.
CSCea52722
With DS3-I cards in a 1:2 protection group, when the protect card is active and in the WTR condition, removing another working card from the protection group clears the WTR condition. To work around this issue, remove the working card from the protection group when the protect card is in the standby state. This issue will be resolved in a future release.
CSCdw80652
When one traffic card in a DS3I 1:N protection group is reset, and then another card is reset, there will be a loss of traffic on the second card, after the first card completes its reset, lasting until the second card completes its reset. This only occurs when the protect card tries to handle the traffic of a card that is resetting, and that card is carrying traffic because when it reset the protect card was carrying traffic for another card. This loss of traffic occurs because the protect card attempts to set its relays to handle the traffic of the working card, but the relays on the working card are also set to carry the traffic, and since the card is resetting, no software is running to switch its relays. This issue most frequently presents itself when testing a double-failure scenario: resetting two cards in a protection group. Wait until the first card completes its reset sequence before resetting the second card to prevent this problem. Configuring cards in 1:1 instead of 1:N protection should also avoid the problem. This issue will not be resolved.
DWDM Cards
CSCsd92505
Traffic hits of 100 ms to 300 ms might occur during an OPT-PRE or OPT-BST card software reset or firmware upgrade. This occurs only with cards displaying the vendor ID 1025 in the CTC node level inventory tab when the following conditions are present for the affected card.
•
OPT-PRE
–
WorkingMode is set to Output Power and the Input Com Power value is less than -33dBm.
•
OPT-BST
–
WorkingMode is set to Gain with a Gain value of greater than 17 dB, and Input Com Power is less than -10 dBm (three channels at approximately -14 dBm).
This issue is resolved in Release 7.0.1 and all subsequent releases except for Release 7.2.
CSCeh22604
When an MXP_MR_2.5G card is in MIXED or ESCON mode, TCA and alarm optical thresholds of Tx power for laser bias are configurable for ESCON payload, though not supported. This issue will be resolved in the future release.
CSCei19148
When a port is placed in-service while the conditions necessary to squelch the port are present, as in when the trunk port on a DWDM card is OOS,DSBLD and a client port is placed in-service, the client will momentarily enable, emitting light, before squelching due to the trunk OOS,DSBLD condition. The pulse is approximately 500 ms. This issue will not be resolved.
CSCei87554
When using a 1GE payload over the TXP_MR_2.5G the IfInErrors counter does not report oversized, undersized, or CRC errored frames, but rather, reports frame coding only. This issue will not be resolved.
CSCsb47323
For MXP_MR_10DME-C and MXP_MR_10DME-L cards, an unexpected RFI condition might be raised along with an OTUk-BDI. When there is an LOS downstream, the node receives OTUk-BDI. Because of the placement of dual OTN and SONET wrappers, it can also receive an RFI. This issue will not be resolved.
CSCsb79548
A long traffic hit can occur when an active TCC2/TCC2P resets while an MXP_MR_10DME-C or MXP_MR_10DME-L card is rebooting.
This issue can be reproduced as follows:
Step 1
Set up two MXP_MR_10DME-C or MXP_MR_10DME-L cards, connected back-to-back in two different nodes, A and B.
Step 2
Ensure that Node A has two TCC2 cards; one is active, and the other is standby.
Step 3
Set up any kind of traffic between the two MXP_MR_10DME-C or MXP_MR_10DME-L cards.
Step 4
Soft reset the MXP_MR_10DME card in Node A, then soft reset the active TCC2/TCC2P.
OTUk/ODUk-SD, FEC Uncorrected word alarms are raised on the trunk port. Traffic goes down and does not recover until the MXP_MR_10DME card is able to come up. It is not known when or if this issue will be resolved.
CSCsb94736
After a fault condition (trunk LOS or Y-cable switch) an MXP_MR_10DME card might fail to detect the login message and traffic might not start for some minutes (after multiple login trials). This can occur in an N-F configuration with MDS switch and MXP_MR_10DME distance extension on, where test equipment traffic is set to 2G Fibre channel (FC) full bandwidth occupancy and started. Stop traffic or keep bandwidth occupancy below 80% during the login phase to work around this issue. This issue will not be resolved.
CSCsb95918
All GFP related alarms are raised with their active severities on the standby card after a Y-Cable protection switch. When a DWDM card (with GFP support) in a Y-Cable protection group becomes standby as a result of a Y-Cable protection switch, the GFP alarms raised when the card was active retain their severities instead of assuming standby severities. The alarms can be seen in the alarm pane if not suppressed, or in the condition pane if suppressed. This issue will be resolved in a future release.
CSCsc36494
Manual Y cable switches with squelching turned off can cause a Fibre channel link with brocade switches to go down.
This issue can be reproduced as follows:
Step 1
Set up MXP_MR_10DME cards so that they are Y cable protected. Squelching is provisioned to be off. Distance extension is turned on.
Step 2
The path between the working pair of Y cable protected cards, has no distance introduced. But the protect path has a delay of 800 km introduced.
Step 3
Start Fibre channel traffic with brocade switches.
Step 4
Perform user-initiated manual Y cable switches from CTC.
After a few switchovers, the FC link will go down. SIGLOSS and GFP-CSF alarms are seen on the CTC.
Cisco recommends you provision squelching to be on when interworking with brocade switches. If for some reason, squelching must be off with brocade switches, Cisco recommends you use a FORCE command to perform Y cable switches. It is not known when or if this issue will be resolved.
CSCsc60472
CTC is not able to discover a TL1 OCHCC circuit provisioned over an ITU-T line card (ITU-T OC48/STM16 and ITU-T OC192/STM64). This issue can occur when, using the TL1 client interface, you create the OCHNC layer that will be used by the OCHCC circuit, then create the OCHCC connections that involve the ITU-T line cards. The result is an OCHNC and two OCHCC partial circuits, instead of an OCHNC and a single OCHCC complete circuit. This issue will not be resolved.
CSCsc14290
LOW communication between two nodes equipped with TXP-MR-10E and AIC-I cards does not work with TXP-MR-10E cards in line termination mode, G.709 enabled, GCC present on the trunk port, and LOW circuits created between the transponders and AIC-I; Cisco recommends that you use EOW instead. This issue will be resolved in a future release.
CSCsc58941
Trunk ports of the TXPP_MR_2.5G and MXPP_MR_2.5G can be in facility and terminal loopback at the same time. this can occur if you provision terminal loopback on the protected trunk port after putting the trunk ports in facility loopback. You can clear this condition by removing loopback provisioning on the trunk ports. This issue will be resolved in a future release.
CSCeh94567
Setting a Terminal loopback on an MXP-2.5G-10G trunk port causes OTUK alarms.
This can occur under the following conditions.
1.
Two MXP-2.5G-10G cards are connected via the trunk ports.
2.
The client ports are connected to respective STM16 line cards.
3.
SDCC is enabled on the client ports and the line cards' STM16 port.
4.
A terminal loopback is set on the MXP-2.5G-10G trunk port.
This terminal loopback causes OTUK-LOF and OTUK-IA alarms to be reported on both MXP-2.5G-10G trunk ports. This issue will not be resolved.
CSCef15415
RMON TCAs are not raised on the TXPP_MR_2.5G client port after a hardware reset. To see this issue, provision two nodes with TXPP_MR_2.5G (TXP-1 and TXP-2) as follows.
Step 1
Connect the TXP-1 DWDM-A trunk to the TXP-2 DWDM-A trunk.
Step 2
Connect the TXP-1 DWDM-B trunk to the TXP-2 DWDM-B trunk.
Step 3
Create an external fiber loopback on the TXP-1 client.
Step 4
Connect the TXP-2 client to a traffic generator.
Step 5
Provision 1G FC payload on the TXP-1 and TXP-2.
Step 6
Ensure that traffic is running smoothly.
Step 7
Provision RMON thresholds using TL1 for all TXPP_MR_2.5G ports (client and trunks).
Step 8
Apply a hardware reset to the TXPP_MR_2.5G.
After the card reboots, only DWDM-A and DWDM-B (trunk) port RMON TCAs are raised in the CTC History pane. RMON TCAs for port 1 (client) are not raised. This issue will not be resolved.
CSCef15452
RMON TCAs are not raised when the RMON history is cleared on TXPP_MR_2.5G card. To see this issue, provision two nodes with TXPP_MR_2.5G (TXP-1 and TXP-2) as follows.
Step 1
Connect the TXP-1 DWDM-A trunk to the TXP-2 DWDM-A trunk.
Step 2
Connect the TXP-1 DWDM-B trunk to the TXP-2 DWDM-B trunk.
Step 3
Create an external fiber loopback on the TXP-1 client.
Step 4
Connect the TXP-2 client to a traffic generator.
Step 5
Provision 1G FC payload on the TXP-1 and TXP-2.
Step 6
Ensure that traffic is running smoothly.
Step 7
Provision RMON thresholds using TL1 for all TXPP_MR_2.5G ports (client and trunks).
Step 8
While the traffic is running reset the RMON history by clicking the Clear button in the CTC Payload PM pane.
RMON TCAs are not raised for any port. This issue will not be resolved.
CSCef50726
Receive client fiber removal can cause a switch from the protect to the active in a TXPP_MR_2.5G. To see this issue, perform the following steps.
Step 1
Set up two nodes with TXPP_MR_2.5G (call the nodes TXP-1 and TXP-2).
Step 2
Ensure that TXP-1 DWDM-A trunk is connected to TXP-2 DWDM-A trunk with a 100 Km span.
Step 3
Ensure that TXP-1 DWDM-B trunk is connected to TXP-2 DWDM-B trunk with a 0 Km span.
Step 4
Ensure that TXP-1 client has an external fiber loopback.
Step 5
Connect the TXP-2 client to a traffic generator.
Step 6
Provision TXP-1 and TXP-2 with FICON 1G payload.
Step 7
Ensure that traffic is running smoothly on the protected span.
Step 8
Remove the receive client fiber at the near end.
This causes the far end trunk to switch from protect to working span. Similarly, removal of the receive Client fiber at far end causes the near end trunk to switch from the protect to the working span. (Note that the traffic is already lost due to the receive client fiber pull.) To work around this issue, manually switch via CTC from the working to the protect span. This issue will not be resolved.
CSCef13304
Incorrect ALS initiation causes a traffic outage on an FC payload. This issue can be seen by performing the following steps.
Step 1
Set up two nodes with TXPP_MR_2.5G (call these nodes TXP-1 and TXP-2).
Step 2
Connect the TXP-1 DWDM-A trunk to the TXP-2 DWDM-A trunk.
Step 3
Connect the TXP-1 DWDM-B trunk to the TXP-2 DWDM-B trunk.
Step 4
Provision the TXP-1 client with an external fiber loopback.
Step 5
Connect the TXP-2 client to a traffic generator.
Step 6
Ensure that TXP-1 and TXP-2 have 1G FC payload provisioned.
Step 7
Enable ALS on TXP-1 trunk port and set it to "Manual Restart."
Step 8
When traffic is running, remove the receive and transmit fibers on TXP1 port 1 (client). Traffic goes down and shutdown on TXP-1 port 2 (trunk) displays "No."
Step 9
Reconnect the fibers for TXP-1 port 1 (client).
ALS is now initiated on TXP-1 port 2 (trunk) and the laser shuts down. Traffic never comes back.
Note
This issue is restricted to the TXPP_MR_2.5G card.
To recover from this situation, perform a manual restart or disable the ALS in this configuration. This issue will not be resolved.
CSCuk51184
When downloading Release 4.7 to nodes with Release 4.6 installed, The 15454-32MUX-O and 15454-32DMX-O report an AWG Temperature fail low alarm that subsequently clears. This also occurs when downgrading from Release 4.7 to Release 4.6, where the AWG Temperature alarm fail is high. This issue cannot be resolved.
CSCec22885
AS-MT is not enabled in Port 3 when a loopback is applied. To see this issue, on the TXPP card, make the following 3 changes before clicking Apply:
Step 1
Change Port 2 to OOS-MT from IS.
Step 2
Change Port 3 to OOS-MT from IS.
Step 3
Change Port 2 to facility or terminal loopback.
Now, when you click Apply, CTC issues the error message: "Error applying changes to row2 peer trunk port must not be IS." Port 3 is still IS and the loopback changes are not applied. You must place Port 3 in the OOS-MT state, apply the changes, and then change the loopback to recover.
This error occurs only when all three of the above changes are attempted at the same time.
To avoid this issue, first change both the trunk ports to OOS-MT, click Apply, and then place port 2 in loopback and click Apply again. This issue will not be resolved.
CSCed76821
With Y-cable provisioned for MXP-MR-2.5G cards, if you remove the client receive fiber on one side, the far end takes greater than 100 ms to switch away from the affected card. This issue will not be resolved.
CSCef44939
Under certain conditions you may be unable to provision an Express Order Wire (EOW) circuit using an MXP_2.5G_10G or TXP_MR_10G card trunk port. This can occurs as follows.
Step 1
Provision an MXP_2.5G_10G or TXP_MR_10G card within a node.
Step 2
Disable OTN.
Step 3
Provision DCC on both client and trunk ports.
Step 4
Go to the Network view Provisioning > Overhead Circuits tab.
During the EOW circuit provisioning only the MXP/TXP client ports are listed for the selection. This issue will not be resolved.
CSCuk51185
After a soft reset of an OSCM or OSC-CSM card, a CONTBUS-IO alarm is raised. This issue will not be resolved.
CSCuk50144
Neither E1 nor E2 circuits are available for EOW circuits on TXP_MR_2.5 TXT in Section and Line Termination mode. This issue will not be resolved.
CSCee45443
When the FICON bridge does not receive the expected number of idle frames between data packets it will transition to SERV MODE. The MXP-MR-2.5G should not be used in scenarios where there is a FICON Bridge in place. This issue will not be resolved.
CSCec40684
After a database restore TXPP trunk ports might report SF, resulting in a traffic outage. The SF occurs when you restore the database and then put the port OOS for DWDM cards; then the operating mode in the database is different from the current operating mode. To avoid this issue, either put the DWDM port OOS before restore the database, or, after restoring the database, reset the DWDM cards. This issue will not be resolved.
CSCec51270
Far end traffic does not switch in line termination mode with .G709 off. This can occur with non-revertive Y-cable, and DCC enabled, under certain specific conditions. To avoid this issue, turn on .G709 when in line mode. This issue will not be resolved.
CSCuk42668
TXP-MR-2.5G F1-UDC may not be passed through in a line-terminated configuration with OTN off. This can occur with clean, OC-3/STM-1, line-terminated traffic, with OTN disabled, when you create a D1-D3 tunnel, a D4-D12 tunnel, and an F1-UDC from client to client. This issue will not be resolved.
CSCuk42752
If you go to the Overhead Circuits Tab in network view and select any User Data, F1 or User Data D4-D12 circuit type, no nXP cards are available for selection in the Endpoints. However, user Data type circuits can still be made end-to-end (where "end-to-end" refers to external cards, such as AIC to AIC) if the nXP cards are put in Transparent mode. This issue will not be resolved.
CSCeb49422
With TXPP cards, a traffic loss up to six seconds can occur during a DWDM protection switch. This behavior may be exhibited during protection switches by certain third-party fiber channel switches due to loss of buffer credits resulting in a reconvergence of the fiber channel link. This issue will not be resolved.
CSCeb53044
The 2G Fiber Channel (FC) payload data type in the TXP_MR_2.5G and TXPP_MR_2.5G cards does not support any 8B/10B Payload PM monitoring. This is by design.
CSCeb32065
Once engaged, the ALR will not restart on the trunk lines of a TXP or TXPP card. This occurs whenever ALR engages on the trunk lines of a TXP or TXPP card and the recover pulse width is provisioned to less than 40 seconds. This is a function of the trunk laser turn-on time, and the limiting recovery pulse width will vary by card. To avoid this issue, provision the pulse width to 40 seconds or more. This issue will not be resolved.
CSCeb37346
Near end and far end PMs might increment simultaneously on TXPP-2.5G cards. This can occur when two nodes have TXPP-2.5G cards and two nodes have STM16 cards in a four node network, where both TXPP-2.5G cards have STM16 SFPs on them, and are in MS (Line Termination) mode. By default, the TXPP-2.5G cards are in Splitter protection: the first DWDM port is working and the second is protect. If you remove the receive fiber of the first DWDM port on one TXPP-2.5G card, both near and far end counts begin to increment. The far end counts should not increment in this case. This issue is seen only when the Txpd cards have G709 and FEC on. If the cards have G709 and FEC off, only the near end counts will increment, as expected.
CSCeb26662 and CSCea88023
With TXP-MR-2.5G cards, when the current 1 day Optics PM rolls over, the information is inaccurate. This issue will not be resolved.
CSCuk42588
With ALS mode configured as "Auto Restart" or "Manual Restart," it is possible the ALS Pulse Duration Recovery time can be set to values out of ITU-T recommendation G.664. You can use values out of the range defined in ITU-T recommendation G.664 only in order to interoperate with equipment that lasers cannot turn on or off within the required pulse time. To stay within the specification, you can set this value to 2 seconds and up to 2.25 seconds.
CSCea81219
On the TXPP, the default value for Tx Power High for TCAs & Alarms is too high for the trunk ports. Since Tx Power TCA and Alarm are not supported for trunk ports, this caveat is for informational purposes only.
CSCeb24815
With TXP-MR-2.5G cards, ratios are calculated incorrectly after clearing statistics. This is because after you clear statistics the entire time period becomes invalid. Once the time period rolls over again, values will be reliable for the new period.
CSCeb27187
During a Y-Cable protection switch, the client interface sends 200,000 to 300,000 8B/10B errors towards the attached Catalyst 3550 switch. The switch reacts to this large amount of 8B/10B errors by reinitializing the interface and spanning tree. The end result is that a protection switch can lead to a 30-45 second traffic hit if the switch is running spanning tree (default mode). This is expected behavior.
CSCea87290
In a Y-Cable protection group, if GCCs are defined on both cards, both cards' active LEDs will be green. This is by design.
CSCeb12609
For the TXPP, attenuating Port 2 Rx signal, SD, and SF alarms are not declared before LOS-P is raised. This is due to the intrinsic design of the optical interface, which allows required BER performances with dispersion and OSNR penalties.
This can occur when Port 2 is in back to back or has low dispersions and high OSNR.
CSCea68773
The ACTV/STBY LED shows AMBER when a 2.5G transponder is first connected. The DWDM cards introduced a new design: When all the ports are OOS on a card, the card is considered to be in standby mode.
Data IO Cards
SONET and SDH Card Compatibility
Tables 2, 3, and 4 list the cards that are compatible for the ONS 15454 SONET and ONS 15454 SDH platforms. All other cards are platform specific.


