Table Of Contents
Release Notes for Cisco ONS 15454 SDH Release 4.6.3
DDTS # CSCec42769 Database Corruption with ONS 15454 SDH Release 4.0, 4.0.1, 4.1
Circuit State Transition from OOS-AINS
Interoperability with SONET DS3i-N-12
Active Cross Connect or TCC2 Card Removal
SONET and SDH Card Compatibility
DDTS # CSCeb26662 and CSCea88023
Maintenance and Administration
DDTS # CSCdv10824: Netscape Plugins Directory
Database Restore on an MS-SPRing (or BLSR)
Active Cross Connect or TCC2 Card Removal
[no] pos vcat resequence {enable | disable}
Resolved Caveats for Release 4.6.3
DDTS # CSCec88426, CSCec88508, CSCed85088
DDTS # CSCec59739, CSCed02439, CSCed22547
DDTS # CSCec88402, CSCed31918, CSCed83309, CSCec85982
DDTS # CSCea16455, CSCea37089, CSCea37185
J1 and J2 Path Trace with E1-42 Cards
DDTS # CSCeb43397 and CSCeb42187
DDTS # CSCeb34655 and CSCeb39337
Maintenance and Administration
Transmission Control Protocol Specification
DDTS # CSCdy56668 and CSCdy26822
New Features and Functionality
10-Gbps Multirate Transponder Card
New Software Features and Functionality
DWDM and TDM Hybrid Node Support
FC_MR-4 Fiber Channel Card Support
New Default Superuser Password
DCC Capacity, Management, and Tunneling
Configurable Superuser Clear PM
K2 Bits Alarm Notification on 1+1 APS
Alarming on Duplicate Node IDs
Rear Panel Ethernet Connection Detach Alarm
Port Status via Front Panel LCD
Obtaining Technical Assistance
Contacting TAC by Using the Cisco TAC Website
Release Notes for Cisco ONS 15454 SDH Release 4.6.3
August, 2007
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.
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 4.6" version of the of the Cisco ONS 15454 SDH Installation and Operations Guide, and Cisco ONS 15454 SDH Troubleshooting and Reference Guide. For the most current version of the Release Notes for Cisco ONS 15454 SDH Release 4.6.3, 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 4.6.3
New Features and Functionality
Obtaining Technical Assistance
Changes to the Release Notes
This section documents supplemental changes that have been added to the Release Notes for Cisco ONS 15454 SDH Release 4.6.3 since the production of the Cisco ONS 15454 SDH System Software CD for Release 4.6.3.
The following changes have been added to the release notes for Release 4.6.3.
Changes to Caveats
The following new caveats have been added.
Caveats
Review the notes listed below before deploying the ONS 15454 SDH. Caveats with DDTS tracking numbers are known system limitations that are scheduled to be addressed in a subsequent release. Caveats without DDTS tracking numbers are provided to point out procedural or situational considerations when deploying the product.
Hardware
STM1E-12 Card Support
The STM1E-12 card is not supported in this release. This card will be supported in a future release. Caveats herein pertaining to this card also do not apply.
DDTS # 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
DDTS # 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:
•
•
•
•
The alarms could potentially occur on any of these boards, as well: OC48AS, GigE, OC192 or OC192LR. This issue will be resolved in a future release.
DDTS # CSCdw50903
E1-14 boards with second source components can incur bit errors under extreme environmental conditions. When these boards operate under voltage and temperature stress conditions and a temperature ramp rate of 1 degree per minute, the boards could exhibit dribbling bit errors at high temperatures: BER = 5.5e-6. To avoid this, you must apply the temperature ramp rate at 0.5 degree per minute. This ramp rate complies with the NEBS standard; however, this issue will be revisited in a future release.
Upgrades
DDTS # CSCee36132, CSCee66259
Activating to Release 4.6.2 or 4.6.3 might result in a stuck Protection Not Available (PROTNA) alarm on the cross connect card after activation completes. One of the cross connect cards would be in active state and the other in standby state. Reset the Active TCC (Shelf Controller Card) to recover from this issue. This issue will be resolved in a future release.
DDTS # CSCec42769 Database Corruption with ONS 15454 SDH Release 4.0, 4.0.1, 4.1
Caution
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 reboot, TCC2 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 flash memory. The previous saved database is then loaded instead. When all saved databases on a TCC2 contain the corruption, the TCC2 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 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 and 4.6.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 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 Release 4.6 and maintenance Release 4.1.3 (caveated herein because of the upgrade issue).
Line Cards
DDTS # CSCed89610
The E1-42 LOSS-L threshold in CTC is not displayed or provisionable. The three other line-related thresholds are displayed properly. This issue will be resolved in Release 5.0.
DDTS # CSCef59835
In E1-42 card view, if you select Provisioning > SDH Thresholds, the VC4 button is greyed out. Hence, the E1-42 VC4 threshold is not provisionable. This issue will be resolved in Release 5.0.
DDTS # CSCef61339
A monitor circuit in the IS-AINS state might fail to switch to IS in an STM-16 and STM-64 SNCP-DRI ring with E1-42 circuits. This issue will be resolved in a future release.
DDTS # CSCef72687
When a one way circuit is created on an SDH electrical card, and the direction of the circuit is toward the backplane from the port, where the LP and HP PMs are measured from the backplane in the direction of the port, though there is no circuit present in that direction, the VC3 and VC12 PMs might count anyway. This issue will be resolved in a future release.
DDTS # 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.
Circuit State Transition from OOS-AINS
For the following cards, a circuit might inappropriately transition from the OOS-AINS state to the IS, or OOS-AINS-PARTIAL state.
•
•
•
•
•
•
This can occur when the circuit and the port for the circuit are both in the OOS-AINS state. Upon a soft reset of the card or a software upgrade, the circuit might transition into the IS or the OOS-AINS PARTIAL state, resulting in false path level alarms. For the DS1 card, this issue occurs only on STS circuits. This issue is non-service affecting and will be resolved in a future release.
DDTS # CSCee17695
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; however, the issue is not likely to be due to the power cycling. If a card enters this state, remove and reseat it. This issue will be resolved in Release 5.0.
DDTS # CSCed14006
Rarely, after you power cycle a node, an installed E1-14 card might report LOF on various ports. Provisioning will clear the LOF. This issue will be resolved in a future release.
DDTS # CSCed15073
Rarely, a WKSWPR condition resulting from loss and recovery of power to the node can become stuck when there are multiple 1+1 protection groups provisioned on a single OC3-8 card. This issue will be resolved in a future release.
DDTS # CSCec82148
Rarely, traffic hits can occur on TCC2 card removal. To avoid this issue, remove the card quickly. To recover from this issue, soft reset the TCC2 card. This issue will be resolved in Release 6.0.
DDTS # CSCed26246
Rarely, an STM1-8 card reports MEA after an NE power cycle. This can occur when a power cycle is induced by quickly removing and reinserting a fuse, or when the fuse is removed for several minutes and then replaced. Cycle power again to recover STM1-8 operation. This issue is under investigation.
DDTS # CSCec82450
When the Active TCC2's power supply fails (using a failure insertion test card) and the Standby TCC2 takes over; the circuits on the DS3I and E1-42 cards in that node might incur a traffic hit. This issue will be resolved in a future release.
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.
DDTS # 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 Release 6.0.
Ethernet Polarity Detection
The TCC2 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 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 "DLP-A 21 Install LAN Wires on the Backplane" procedure in the user documentation.
Active Cross Connect or TCC2 Card Removal
Active cross connect or TCC2 cards should not be removed. If the active cross connect or TCC2 card must be removed, to minimize network interruption you can first perform an XC10G (or 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 will be removed (performing a lockout on all spans will also accomplish the same goal).
Caution
SONET and SDH Card Compatibility
Tables 1, 2, and 3 list the cards that are compatible for the ONS 15454 SONET and ONS 15454 SDH platforms. All other cards are platform specific.
DDTS # 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. It is not known at this time when or if this issue will be resolved.
Note
DDTS # 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.
DDTS # CSCdw57215
In a configuration with STM16 Any Slot cards and an VC4-8c circuit, provisioned between G1000-4 cards with traffic going over the STM16 span, extracting the G1000-4 card at one end of the VC4-8c circuit before deleting the circuit can result in a traffic hit on all existing SDH circuits defined over that same span. There are no issues if the circuit is deleted prior to the removing the G1000-4 card.
XC10G Boot Process
If you install a new XC10G card to the node and it fails to boot, remove the card and reinsert it. If the card still fails to boot, return it using the RMA procedure. This issue will be resolved in future hardware.
Jitter Performance with XC10G
During testing with the XC10G, jitter generation above 0.10 UI p-p related to temperature gradient testing has been observed. This effect is not expected to be seen under standard operating conditions. Changes are being investigated to improve jitter performance in a subsequent version of the XC10G cross connect card. DDTS numbers related to this issue include CSCdv50357, CSCdv63567, CSCdv68418, CSCdv68441, CSCdv68389, CSCdv59621, and CSCdv73402.
DWDM Cards
DDTS # CSCed18225
When the trunk ports for two back-to-back connected MXPs or TXPs have different ALS modes enabled (such as if one of them is ALS-Manual, and other is ALS-Auto), or have the same ALS mode for both sides (with ALS-Manual or ALS-Auto enabled), MXP or TXP might enter a state in which there are oscillating LOS-P, ALS, and Client Squelch alarms. If this occurs, either choose ALS-Disable on MXP/TXP, or remove the trunk transmit fiber on either end for 15-20 seconds and then reinsert it. This issue is resolved in Release 5.0.
DDTS # CSCed21403
Occasionally, in a node with MXP-2.5G-10G cards, when you hard reset the active TCC2, the MXP-2.5G-10G traffic can take a hit of 1-4 ms. It has not been determined when or if this issue will be resolved.
DDTS # CSCed01940
The TXPP card does not squelch the near end client on putting trunk ports OOS. This can occur where two TXPP cards are connected via trunks. Each TXPP card is in transparent mode with GCC enabled. Testsets are connected to each client port. On the near end, place both trunk ports OOS. The far end client squelches because of LOS-P. The near end client, however, does not squelch. The near client should also squelch. To work around this, place the client port OOS, or place the far-end trunk port OOS. This issue will be resolved in a future release.
DDTS # CSCeb25490
Occasionally CTC displays a LO-TXPOWER alarm when SMT4 and STM1 SFP is installed at the client port of a TXP or TXPP card. The LO-TXPOWER alarm is displayed when the alarm threshold is set to the default value in the TX POWER LOW field of the Optical Threshold in the CTC provisioning window. To work around this issue, lower the alarm threshold value (TX POWER LOW (dBm)) of Optical Threshold in the CTC provisioning window. Refer to Table XX for threshold values. This issue will be resolved in Release 5.0.
Table 4 contains the High and Low Alarm Thresholds of Tx-power and Rx-power of SFPs in TXP and TXPP cards. The values of these thresholds are read from the EEPROM inside the SFPs. This table can be used as a reference in PM alarm provisioning and Threshold Alarm verification.
Table 4 Alarm Thresholds
10-1421-02
OC48-SR
2.0
-14.6
0
-21.0
10-1422-01
OC48-IR
4.0
-9.6
3.0
-23.2
10-1829-01
OC12-IR
-6.9
-13.1
-6.0
-31.0
10-1828-01
OC3-IR
-6.9
-13.9
-6.0
-31.0
10-1832-01
2FC/2GB-LX
0.9
-13.2
1.0
-24.0
10-1590-01
2FC
1.0
-14.6
N/A2
N/A
10-1750-01
ESCON
N/A
N/A
N/A
N/A
1 The power unit for TxHi/TxLow/RxHi/RxLow used is dBm.
2 N/A means Not Available. The vendor did not provide the information in this field.
DDTS # 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.
DDTS # 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.
DDTS # 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.
DDTS # 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.
DDTS # 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.
DDTS # 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.
DDTS # 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.
DDTS # 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.
DDTS # 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.
DDTS # 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.
DDTS # CSCea87290
In a Y-Cable protection group, if GCCs are defined on both cards, both cards' active LEDs will be green.
DDTS # CSCeb12609
For the TXPP, attenuating Port 2 Rx signal, SD, and SF alarms are not declared before LOC 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.
DDTS # 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.
E Series and G Series Cards
E1000-2/E100T
Do not use the repair circuit option with provisioned stitched Ethernet circuits. It is not known at this time when or if this issue will be resolved.
Single-card EtherSwitch
Each E100/E1000 card can be configured as a single-card EtherSwitch configuration to allow VC4-4c of bandwidth to be dropped at each card. The following scenarios for provisioning are available:
VC4-4c
VC4-2c, VC4-2c
VC4-2c, VC4, VC4
VC4, VC4, VC4, VC4
When configuring scenario 3, the VC4-2c must be provisioned before either of the VC4 circuits.
Multicard EtherSwitch
When deleting and recreating Ethernet circuits that have different sizes, you must delete all VC4 circuits provisioned to the EtherSwitch before you create the new circuit scenario. (See the preceding "Single-card EtherSwitch" section on page 6 for details on the proper order of circuit creation.) Enable front ports so that the VLANs for the ports are carried by the largest circuit first. A safe approach is to enable the front port before you create any circuits and then retain the front port VLAN assignment afterwards. If you break the rules when creating a circuit, or if you have to delete circuits and recreate them again, delete all circuits and start over with the largest first.
ML Series Cards
DDTS # CSCef62420
On ML100t and ML1000, defects might not be detected and alarms not be reported on a POS port. This can occur when you provision a circuit to POS 0, provision another circuit to POS 1, and then delete the circuit on POS 1. To work around this issue, delete and reprovision the POS 0 circuit. This issue will be resolved in Release 5.0 and the next maintenance release after 4.6.3.
DDTS # CSCed96068
If an ML-Series card running Software Release 4.6.2 or later is interoperating with an ML-Series card running Software Release 4.6.0 or 4.6.1, then the pos vcat resequence disable command must be added to the configuration of the ML-Series card running R4.6.2 or later.
DDTS # CSCec52443
On an ML-series RPR ring circuit deletion or creation causes an approximately 200 ms traffic loss. Traffic loss is expected to be less than 50 ms for RPR. To avoid this issue, from the ML-series CLI, perform a "shutdown" on both ends of the circuit prior to circuit changes. This issue will not be resolved.
DDTS # CSCec52372
You must issue a "shut" command to both ends of a POS circuit before placing the circuit OOS, and issue IS before a "no shut" command. Placing a POS circuit OOS without shutting down can cause long traffic hits. This issue will not be resolved.
DDTS # CSCec51252
You must issue a "shut" on both ends of affected POS circuits before performing a maintenance action on those circuits. If a POS circuit is restored without first issuing the shut commands, traffic loss is greater than 50 ms. When a maintenance action is taken, one end of the circuits could come up before the other. During that time, traffic is lost because the other end is not up yet. This issue will be resolved in a future release.
DDTS # CSCed06286
If you create several bridgegroups before provisioning POS circuits, POS stays in the BLK state. If this issue occurs, perform a shut/no shut on POS interface that is stuck in the BLK state. This issue will be resolved in a future release.
DDTS # CSCeb25778
When a MAC-SA is seen for the first time, it is learned, but may age out in less than 5 minutes. If the same MAC-SA is seen again before the first ages out, the entry will age out after 5 minutes, as expected. This issue will not be resolved.
DDTS # CSCin43669
Timer expiration can cause a system crash when you attempt to remove 250 Shared Packet Ring (SPR) subinterfaces using the "no int spr1" command, while Cisco Discovery Protocol (CDP) is also enabled. To avoid this issue, either turn off CDP, issue the command, and then turn CDP back on; or remove the SPR subinterfaces explicitly. This issue will not be resolved.
DDTS # CSCea36829
The broadcast packet count is always 0 for the SPR interface. The ML100 and ML1000 hardware does not support counting broadcast packets. This issue will not be resolved.
DDTS # CSCeb21996
When the POS interface is removed from SPR due to a defect, while SPR is configured in immediate mode, the defect type may not be reported. This only occurs if the defect is set and clears in less then 50 ms.
DDTS # CSCdz49700
ML-series cards do not appear in the Cisco Discovery Protocol (CDP) adjacencies and do not participate in the Spanning-Tree Protocol. All packets are counted as multicast.
The ML-series cards always forward Dynamic Trunking protocol (DTP) packets between connected devices. If DTP is enabled on connected devices (which might be the default), DTP might negotiate parameters, such as ISL, that are not supported by the ML-series cards. All packets on a link negotiated to use ISL are always counted as multicast packets by the ML-series card, and STP and CDP packets are bridged between connected devices using ISL without being processed. To avoid this issue, disable DTP and ISL on connected devices. This functionality is as designed.
DDTS # CSCdz68649
Under certain conditions, the flow-control status may indicate that flow control is functioning, when it is not. Flow-control on the ML-series cards only functions when a port-level policer is configured. A port-level policer is a policer on the default and only class of an input policy-map. Flow-control also only functions to limit the source rate to the configured policer discard rate, it does not prevent packet discards due to output queue congestion.
Therefore, if a port-level policer is not configured, or if output queue congestion is occurring, policing does not function. However, it might still mistakenly display as enabled under these conditions. To avoid this issue, configure a port-level policer and prevent output queue congestion. This issue will not be resolved.
DDTS # CSCdz69700
Issuing a shutdown/no shutdown command sequence on an ML1000 port clears the counters. This is a normal part of the startup process and there are no plans to change this functionality.
DDTS # CSCea01675
Packets without an 802.1q VLAN tag are classified as COS 0. This issue will not be resolved.
DDTS # CSCea20962
No warning is displayed when applying OOS to ML drop ports on the circuit provisioning window. This issue will be resolved in Release 5.0.
DDTS # CSCea26847
An unexpected card reload can occur when a card is configured to route IP-Multicast traffic and subsequently sends IP-Multicast frames larger than 1649 bytes. To prevent this, avoid routing IP-Multicast frames larger than 1649 bytes. This issue is under investigation.
DDTS # CSCin29274
When configuring the same static route over two or more interfaces, use the following command:
ip route a-prefix a-networkmask a.b.c.d
Where a.b.c.d is the address of the outgoing gateway, or, similarly, use the command:
ip route vrf vrf-name
Do not try to configure this type of static route using only the interface instead of the address of the outgoing gateway in Release 4.0. This issue will be resolved in a future release.
DDTS # CSCin32057
If no BGP session comes up when VRF is configured and all interfaces have VRF enabled ensure that at least one IP interface (without VRF) is configured and add an IP loopback interface on each node.
DDTS # CSCdy55437
The maximum MAC Address Learn Rate for the ML-Series cards is 1300 MAC addresses per second. This number varies based on the ML-Series control and forwarding plane loads. If the forwarding and control planes are heavily loaded, the maximum MAC Address Learn Rate could be as low as 100 MAC addresses per second. To correct a situation where an ML-Series card has stopped learning MAC addresses, reduce the load on these cards. This load limit is by design.
DDTS # CSCdy47284
Oversize frames are not supported on ML100 Fast Ethernet ports. Oversize frames cause egress traffic to incur CRC, line, and fragment errors on these ports. To avoid this issue, do not send jumbo packets to ML far end ports. This is as designed.
Maintenance and Administration
Caution
Note
DDTS # CSCef75019
In the CTC node view Provisioning > Security > Access tabs, the option to enable SSH access instead of telnet does not function. This issue will be resolved in a future release.
DDTS # CSCee39968
The Timing Report in the Maintenance window of CTC fails to update the report of a new timing failure after a previous reference has failed. For example, if you inject LOS and then switch to injecting LOF, the Timing Report fails to display the LOF against the reference, or only displays the failure briefly, upon clearing. This issue will be resolved in a future release.
DDTS # CSCed27389
Under certain conditions, you cannot unlock a cross-connect from CTC and TL1. If you lock a cross-connect, then quickly click the SWITCH button, the Clear is sent only to the protect XC side. This causes the Unlock command to fail. This issue is resolved in Release 5.0.
DDTS # CSCec17281
When the "Status" field for a circuit in the circuit table shows "INCOMPLETE," this can be interpreted as an alarm or traffic-affecting condition on the circuit. On SNCP and MS-SPRing circuits, a circuit is shown as INCOMPLETE if either the working or protect path is missing a network span or connection, even if traffic is flowing without error on the other, redundant path. This can lead to confusion, since the meaning of "INCOMPLETE" is not well-defined. You can see this if you, for example, introduce LOS on a span in a MS-SPRing network such that traffic is switched to another path around the ring. Ignore the INCOMPLETE circuit status in such cases and instead look for any alarms in the network. The circuit Status will be defined more clearly in Release 5.0.
DDTS # CSCec21668
Do not create more than three VC3 or VC12 circuits in auto-range mode. The VC3 or VC12 circuits can be created in batches of three, or manually. When you create more than three VC3 or VC12 circuits in auto-range mode, CTC creates the first three circuits and then issues the error message:
"Exception: Source is not fully specified"
This can occur with an SDH node when you wish to create more than three VC3 or VC12 circuits in auto-range mode. This issue will be resolved in a future release.
DDTS # CSCed27389
In some instances, you might not be able to unlock a cross-connect from both CTC and TL1. After locking the cross-connects, if you quickly click the SWITCH button, the unlock command might fail. This issue is resolved in Release 5.0.
DDTS # CSCeb39359
When changing NE timing from extern/mix to Line timing, a Transient IEF alarm may be reported against the standby XC10G. This issue will be resolved in a future release.
DDTS # CSCea81001
When a fault condition exists against a circuit or port that is in the OOS-MT or OOS-AINS state (or when you are using the "Suppress Alarms" check box on the CTC Alarm Behavior pane), the alarm condition is not assigned a reference number. If you were to place the circuit or port in service at this time, in the absence of the reference number, the CTC alarm pane would display the condition with a time stamp indicating an alleged, but incorrect, time that the autonomous notification was issued. Clicking the CTC alarm "Synchronize" button at this stage will correct the alarm time stamp. There is no way to remedy the lack of reference number. This issue will be resolved in Release 6.0.
DDTS # CSCea78364
Simultaneous failure of working and protect cards in 1:N protection groups may not be alarmed as service affecting. This can occur when the working card of the protection group has been removed from the chassis, and the protect card of the protection group is subsequently issued a Manual Reset. Since the working and protect facilities are impaired, the Improper removal alarm should clear and be reissued as a Critical and service affecting condition. This issue will be resolved in Release 6.0.
DDTS # 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.
DDTS # 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.
DDTS # 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:
•
•
•
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.
DDTS # 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.
DDTS # CSCdy57891
An LOP-P alarm can be inadvertently cleared by an LOS that is raised and cleared. On 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.
DDTS # 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.
DDTS # CSCdw23208
The following table 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).
DDTS # 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.
DDTS # 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.
Alarms
DDTS # CSCef63240
Rarely, an LP TIM alarm displays its severity as NR instead of MJ in CTC. This can occur when a VC3 circuit is created on Port 5 and IO has detected a VC4 PLM alarm. This issue will be resolved in Release 5.0.
DDTS # CSCee29901
A CARLOSS alarm can take up to 3 minutes to be reported depend of the number of VLANs configured on a node. When the alarm does appear, if you clear this major alarm, the severity changes to minor, but then the alarm disappears. This alarm's severity change behavior is under investigation.
MS-SPRing Functionality
DDTS # CSCee65471
Rarely, during software upgrade of passthrough node in MS-SPRing, the VC3 traffic on a DS3I card might incur a hit. This issue will be resolved in a future release.
DDTS # CSCec34856
When you create a circuit over MS-SPRing or DRI, the resource usage in the Maintenance > Cross-Connect > Resource Usage tab will display the incorrect VC# for the circuit you created. Use the Circuit Edit > Monitors window to view the correct VC#. This issue will be resolved in a future release.
DDTS # CSCea81000
In a two-fiber or four-fiber MS-SPRing, MS-RFI is not reported for an LOS or LOF with a ring lockout in place on a different span. This issue will be resolved in Release 6.0.
DDTS # CSCeb09217
Circuit states are not updated after a span update. If you update a four node OC-12 two-fiber MS-SPRing to a four node OC-192 two-fiber BLSR, the previous PCA circuits should be shown as two-fiber MS-SPRing protected, but they are shown as "UNKNOWN" protected. If you relaunch CTC this situation is corrected. This issue will be resolved in Release 5.0.
DDTS # CSCdz66275
When creating a MS-SPRing from the network view, the node default values for reversion are not initially used. To see this, starting with no preferences file, log into a node with CTC, and set the node default values for MS-SPRing reversion. Now, in Network view, use the MS-SPRing wizard to create a MS-SPRing. The node level default values are initially ignored while the wizard is still in operation. If you encounter this issue, you may need to change values as appropriate for your network while you are still using the MS-SPRing wizard. Once the wizard is finished, these values are saved to a preferences file and will be used henceforth. This issue will not be resolved.
DDTS # CSCdw53481
Two MS-Rs are not allowed to coexist. If you execute a manual ring switch command on one side of an MS-SPRing node and apply another manual ring switch command on other side of the node, the second manual ring switch command is rejected. This works as designed. The implementation complies with Telcordia GR-1230, R6-102.
DDTS # CSCdx45851
On a four fiber MS-SPRing, restoring the database for all nodes at the same time could cause VC4-16c traffic to fail to switch. Do not restore the database for multiple nodes simultaneously. The proper procedure for restoring the database for multiple nodes is to restore one node at a time. This procedure is documented in the user documentation.
DDTS # CSCdx19598
A rare hardware failure on an STM16AS card transmitter can trigger SEF on the receiving STM16AS card in a four fiber MS-SPRing (or BLSR) configuration. The BER calculations are suspended when SEF is detected, so SD or SF is never raised. Likewise SEF is not considered a signal failure condition like LOS or LOF, so a protection switch will not occur. If this occurs, use the CTC GUI to force a protection switch on the MS-SPRing (or BLSR). This issue will not be resolved.
DDTS # CSCdv53427
In a two ring, two fiber MS-SPRing (or BLSR) configuration (or a two ring MS-SPRing or BLSR configuration with one two fiber and one four fiber ring) it is possible to provision a circuit that begins on one ring, crosses to a second ring, and returns to the original ring. Such a circuit can have protection vulnerabilities if one of the common nodes is isolated, or if a ring is segmented in such a way that two non-contiguous segments of the circuit on the same ring are each broken. There are two possible workarounds for this issue:
1.
2.
This issue will be resolved in a future release.
Database Restore on an MS-SPRing (or BLSR)
When restoring the database on an MS-SPRing (or BLSR), follow these steps:
Step 1
Step 2
Step 3
SNCP Functionality
DDTS # CSCee68239
Low order circuits cannot be created over Integrated SNCP DRI. Circuit creation fails with an xUpsrSelectorPayloadMismatch error. This issue will be resolved in a future release.
DDTS # CSCeb37707
With a VT SNCP circuit, if you inject signals with a thru-mode test set into one path of the circuit in a particular order, you may not see the appropriate alarms. This can occur when you first inject LOP-P, then clear, then inject LOP-V. This issue will be resolved in Release 6.0.
Active Cross Connect or TCC2 Card Removal
As in MS-SPRing (or BLSR) and 1+1, you must perform a lockout on SNCP (or path protection) before removing an active cross connect or TCC2 card. The following rules apply to SNCP (or path protection).
Active cross connect cards should not be removed. If the active cross connect or TCC2 card must be removed, to minimize network interruption you can first perform an XC10G (or 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 will be removed (performing a lockout on all spans will also accomplish the same goal).
SNMP
DDTS # CSCec75857
There is no SNMP return value for dsx1TotalTable when you configure an ONS 15454 with DSX 1 day stats, then query the node. This issue will be resolved in Release 5.0.
Performance Monitoring
DDTS # CSCef72828
No TCA is generated for AISS E1 path. The default threshold in CTC is zero. This can be changed in the GUI, but is never used by the card. Thus threshold crossings on this PM do not generate a TCA. This issue will be resolved in future release.
DDTS # CSCeb85353
Bulk PM does not show 8b10b PM statistics for the TXPP_MR_2.5G card when Payload Type is set to "1G Ethernet." To see these statistics, go to the CTC card view > Performance > Payload PM tabs. This issue will be resolved in Release 5.0.
Documentation
The following ML-series command documentation applies for Release 4.6.3. This command is not in the user documentation for the 4.6 general release. Users of Release 4.6.3 should refer to the release notes for this command.
[no] pos vcat resequence {enable | disable}
Enables or disables the SW-LCAS H4 byte sequence number re-sequence feature. If an ML-Series card running Software Release 4.6.2 or later is interoperating with an ML-Series card running Software Release 4.6.0 or 4.6.1, then the pos vcat resequence disable command must be added to the configuration of the ML-Series card running Software Release 4.6.2 or later.
Syntax Description
Defaults
The default setting is Enable.
Command Modes
Per POS port configuration
Usage Guidelines
The no form of the command will set the mode to the default.
Examples
The following example disables the re-sequencing of the H4 byte sequence numbers for POS port 0:
Router(config)#int pos 0
Router(config)#pos vcat resequence disableResolved Caveats for Release 4.6.3
The following items are resolved in Release 4.6.3
Hardware
DDTS # CSCec33248
Pulling the active XCVXL card might result in a traffic outage lasting for greater than 2 seconds. It is possible to see this approximately 1 out of every 7 active XCVXL card pulls. Excessive traffic outage from this issue will not occur after a software-induced XCVXL side switch. In this case, you can expect a traffic hit of less than 60 ms, and traffic will resume normally. This issue is resolved in Release 4.6.3.
Line Cards
DDTS # CSCec30792
On a small percentage of active XCVXL card pulls, the E1-42 card can lose traffic for more than 2 seconds. To avoid this issue, do not pull active XCVXL card. First, switch to the protect XCVXL, wait for the switch, then, pull the XCVXL in question. This issue is resolved in Release 4.6.3.
DDTS # CSCed27998
Rarely, a traffic hit can occur during the TCC2 switch that occurs as a part of the upgrade procedure. Traffic hits are only expected on E1-42 traffic; all other E3 & DS3 traffic should remain errorless during the upgrade's TCC2 switch portion. Hits to the E1-42 traffic occur 90% of the time during the upgrade if all 42 circuits are provisioned on the card. This issue is resolved in Release 4.6.3.
DDTS # CSCee65098
Occasionally, E1-42 cards might incur multiple traffic hits during an upgrade to Release 4.6.2. Some working cards might switch to protect and require manual intervention to switch back. This issue is resolved in Release 4.6.3.
DDTS # CSCec83712
Avoid pulling the active cross connect when the standby is locked out. If the standby cross connect card is locked out and the active cross connect card is pulled, the E1-42 card switches to protect. This switch should not occur. After the active cross connect card reboots and traffic is restored, the reverting E1-42 card takes a hit of +/- 1 second. This issue is resolved in Release 4.6.3.
DDTS # CSCed06531
Malformed IP packets can potentially cause the XTC, TCC/TCC+/TCC2 and TCCi/TCC2 control cards to reset. Repeated transmission of these malformed packets could cause both the control cards to reset at the same time. This issue is resolved in Release 5.0, and maintenance Releases 4.1.4, 2.3.5, 4.0.3, and 4.6.2.
DDTS # CSCed86946
Malformed ICMP packets can potentially cause the XTC, TCC/TCC+/TCC2 and TCCi/TCC2 control cards to reset. Repeated transmission of these malformed packets could cause both the control cards to reset at the same time. This issue is resolved in Release 5.0, and maintenance Releases 4.1.4, 2.3.5, 4.0.3, and 4.6.2.
DDTS # CSCec88426, CSCec88508, CSCed85088
Malformed TCP packets can potentially cause the XTC, TCC/TCC+/TCC2, and TCCi/TCC2 control cards to reset. Repeated transmission of these malformed packets could cause both the control cards to reset at the same time. This issue is resolved in Release 5.0, and maintenance Releases 4.1.4, 2.3.5, 4.0.3, and 4.6.2.
DDTS # CSCec59739, CSCed02439, CSCed22547
The XTC, TCC/TCC+/TCC2 and TCCi/TCC2 control cards are susceptible to a TCP-ACK Denial of Service (DoS) attack on open TCP ports. The controller card on the optical device will reset under such an attack.
A TCP-ACK DoS attack is conducted by withholding the required final ACK (acknowledgement) for a 3-way TCP handshake to complete, and instead sending an invalid response to move the connection to an invalid TCP state. This issue is resolved in maintenance Releases 4.1.4, 2.3.5, 4.0.3, and 4.6.2.
DDTS # CSCec88402, CSCed31918, CSCed83309, CSCec85982
Malformed UDP packets can potentially cause the XTC, TCC/TCC+/TCC2, and TCCi/TCC2 control cards to reset. Repeated transmission of these malformed packets could cause both the control cards to reset at the same time. This issue is resolved in Release 5.0, and maintenance Releases 4.1.4, 2.3.5, 4.0.3, and 4.6.2.
DDTS # CSCea16455, CSCea37089, CSCea37185
Malformed SNMP packets can potentially cause the XTC, TCC/TCC+/TCC2 and TCCi/TCC2 control cards to reset. Repeated transmission of these malformed packets could cause both the control cards to reset at the same time. This issue is resolved in Release 4.6, and maintenance Releases 4.0.1, 4.0.3, and 4.1.3.
DDTS # CSCee27329
If an account has a blank password set, and an attempt is made to log into the device with a password greater than ten characters, the attempt will be successful. This vulnerability only affects the TL1 login interface. The CTC login interface is not vulnerable to this vulnerability. The CTC and TL1 user interfaces prevent the setting of a blank password as the password. Only the CISCO15 userid, during initial install process, has a blank password, which is to be changed as part of the initial install process. This issue is resolved in Releases 4.6.2 and 5.0.
DDTS # CSCed30150
When the E1-42 card is fully loaded, J2 path trace cannot be retrieved on VC12 circuits. This issue is resolved in Release 4.6.2.
DDTS # CSCed25636
Rarely, it can take approximately 20 seconds for a 1:N soft switch command to take effect on E1-42 after a software upgrade, and when several circuits are provisioned. Soft reset the card or reprovision all circuits if this occurs. This issue is resolved in Release 4.6.2.
DDTS # CSCed41691
Rarely, high switch times for E1-42 protection switches can occur with a four node system, where spans are mixed, with 1+1, path protection, and two-fiber BLSR, where drops are E1-42 with 1:N protection. If you perform a 1:N protection switch on E1-42, traffic hits might be greater than 60 ms. This issue is resolved in Release 4.6.2.
DDTS # CSCuk39201
The E1-42 J2 expected input field is longer than 15 characters. This issue is resolved in Release 4.6.2.
DDTS # CSCed47356
For J2 path trace provisioned as AUTO mode, the expected path trace is not updated in CTC when the E1-42 port is greater than 21. Use "Manual" Mode to avoid this issue. This issue is resolved in Release 4.6.2.
DDTS # CSCed47363
Received J2 is not shown on the Edit Pathtrace screen. This can be seen when the VC12 number is greater than 21. This issue is resolved in Release 4.6.2.
J1 and J2 Path Trace with E1-42 Cards
On E1-42 cards, do not enable J1 or J2 monitoring in Release 4.6.1. To do so can result in a loss of traffic. If you do have J1 or J2 path trace turned on, and you upgrade to Release 4.6.1, turn those features off prior to the upgrade in order to avoid possible traffic loss. This issue is resolved in Release 4.6.2.
DDTS # CSCed25636
Occasionally, a 1:N soft switch command can take approximately 20 seconds to take effect on E1-42 after a software upgrade when several circuits are provisioned. If this occurs, soft reset the card, or reprovision all the circuits. This issue is resolved in Release 4.6.2.
DDTS # CSCed31270
Rarely, E1-42 traffic might fail to recover after active XC boot up following a lockon and removal of the active XC. To work around this, induce the software to perform a "chipInitSequence." This issue is resolved in Release 4.6.2.
DDTS # CSCed29086
Resetting both TCC2s occasionally causes the IO cards to send and/or receive corrupt K bytes. If this occurs, it might cause a ring to unswitch at the passthrough node. If you cause a force switch and then clear the force switch, traffic will recover. This issue is resolved in Release 4.6.2.
DDTS # CSCed36598
When DHCP forwarding is turned on, and the forwarding to address is set to a cellbus address instead of a DHCP server address, you can lose connection to your nodes. Always set the forwarding address to a DHCP server. This issue is resolved in Release 4.6.2.
DDTS # CSCed30150
When the E1-42 card is fully loaded, J2 path trace cannot be retrieved on VC12 circuits. This issue is resolved in Release 4.6.2.
DDTS # CSCeb49210
A soft reset of the working or protect 2.5g multirate card in a Y-cable protection group clears an existing "Lockout of protection" request. This issue is resolved in Release 4.6.
DDTS # CSCdy65482
On the AIC-i card, a volume adjustment on the receive value of a four-wire orderwire circuit will be displayed as the negative of its actual value. To work around this issue, enter the negative of the value you actually want for the receive value. For example, adjust the receive value on CTC to -2 dbm for a gain of 2 dbm. This issue is resolved in Release 4.6.
DDTS # CSCeb43397 and CSCeb42187
Rarely, E1-42 cards may incur a greater than 60 ms traffic disruption during protection switches. This can occur when you pull the active working E1-42 card. This issue is resolved in Release 4.6.
DDTS # CSCeb34655 and CSCeb39337
Very rarely, E1-42 takes greater than 2 second hits on an active XCVXL pull. To avoid this issue, side switch the XCVXL cards. This issue is resolved in Release 4.6.
<
Guest
