Table Of Contents
Release Notes for Cisco ONS 15454
Release 5.0.4Maintenance and Administration
ONS 15454 Conducted Emissions Kit
DDTS # CSCdv10824: Netscape Plugins Directory
Common Control and Cross Connect Cards
Active Cross Connect (XC10G/XCVT) or TCC2/TCC2P Card Removal
SONET and SDH Card Compatibility
DDTS # CSCds02031 E1000-2/E100
DDTS # CSCed05502 and CSCef43911
DDTS # CSCds13769: Fujitsu FLM-150 and Nortel OC-3 Express
Active Cross Connect (XC10G/XCVT) or TCC2/TCC2P Card Removal
Resolved Software Caveats for Release 5.0.4
Maintenance and Administration
DDTS # CSCec75064 and CSCec75019
New Features and Functionality
New Electrical Interface Assemblies
New Software Features and Functionality as of Release 5.0.2
New Software Features and Functionality as of Release 5.0
Additional Support for In Service Topology Upgrades
SL-Series Fibre Channel Card Enhancements
State Verification Scan Before Activation
Linear Port-Mapped Ethernet Mode (8-port 10/100 Ethernet Linear Mapper)
VCAT Member Routing Enhancements
New Software Features and Functionality as of Release 4.7
Provisioning Parameters for Terminal and HUB Sites
OC3/STM1 Performance Monitoring for OSCM and OSC-CSM Cards
LOS-P Threshold Configuration on OPT-BST/OSC-CS/OPT-PRE COM-RX Port
Circuit Size Label Removed from OCHNC Circuits
Wavelength Path Provisioning Changes
Calibration Value by Port Service State
High Level Functional Differences
Obtaining Technical Assistance
Contacting TAC by Using the Cisco TAC Website
Release Notes for Cisco ONS 15454
Release 5.0.4
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 SONET multiplexer. For detailed information regarding features, capabilities, hardware, and software introduced with this release, refer to the "Release 5.0.2" version of the Cisco ONS 15454 DWDM Installation and Operations Guide; and the "Release 5.0" version of the Cisco ONS 15454 Procedure Guide; Cisco ONS 15454 Reference Manual; Cisco ONS 15454 Troubleshooting Guide; and Cisco ONS 15454 SONET TL1 Command Guide. For the most current version of the Release Notes for Cisco ONS 15454 Release 5.0.4, visit the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/ong/15400/454relnt/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 Software Caveats for Release 5.0.4
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 Release 5.0.4 since the production of the Cisco ONS 15454 System Software CD for Release 5.0.4.
The following changes have been added to the release notes for Release 5.0.4.
Changes to Caveats
The following caveats have been added.
Changes to Resolved Caveats
The following caveat has been resolved.
Caveats
Review the notes listed below before deploying the ONS 15454. 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.
Software Upgrades
DDTS # CSCei29741
On nodes with DS3/EC1-48 cards, where port line buildouts are set to long (for use with 900 ft cables), a software upgrade from Release 5.0 or maintenance Release 5.0.2 to any release after 5.0.2 can result in traffic hits up to 50 ms on the ports set to long line buildout. The length of the hit depends on the operative slot, port, actual cable length, UBIC type, and cable type. This issue cannot be resolved for upgrades from the two affected releases. No other release has this issue, and upgrades from Release 5.0 to 5.0.2 are also not affected.
Hardware
DDTS # 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 be resolved in a future release. Note, however, that in normal network configurations the muxponder is operated with G.709 and FEC turned on, and the jitter tolerance tests pass.
DDTS # 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 release.
DDTS # CSCuk44284
An optical connector and optical attenuators inserted into the SFP may force the fiber against the shelf door when it is closed. Use the following types of optical connectors and optical attenuators when connecting to the SFP:
•
•
–
–
–
DDTS # CSCdw57215
In a configuration with OC-48 Any Slot cards and an STS-24c circuit, provisioned between G1000-4 cards with traffic going over the OC-48 span, extracting the G1000-4 card at one end of the STS-24c circuit before deleting the circuit will result in a traffic hit on all existing SONET circuits defined over that same span. This only occurs when the STS-24c is provisioned on timeslot 25.
In the Cisco ONS 15454 Procedure Guide, Release 4.1.x, refer to the "NTP-77 Delete Circuits" procedure to delete the 24c circuit before removing the card. Once you have deleted the circuit, refer to the "DLP-191 Delete a Card from CTC" task (also in the procedure guide) to delete the G1000-4 card. This issue will be resolved in Release 6.0.
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 future release. DDTS numbers related to this issue include CSCdv50357, CSCdv63567, CSCdv68418, CSCdv68441, CSCdv68389, CSCdv59621, and CSCdv73402.
DDTS # CSCdz49928
When using KLM type fuses with specific types of fuse and alarm panels, the PWR-REDUN alarm may not be displayed once the fuse is blown. A KLM fuse does not have a blown fuse indicator built into it. As a result, the blown fuse detection circuitry on the FAP may continue to provide voltage on its output despite a blown fuse.
Maintenance and Administration
Caution
Note
Note
DDTS # CSCee96164
The Wait To Restore (WTR) alarm does not appear to be raised for as long as the WTR timer is set for. The WTR is raised correctly, but the alarm is hidden for the first 12 seconds due to the clear soaking time for a CLDRESTART alarm. You can see this behavior if you set up a 1+1 bidirectional revertive protection group, remove the working card, and then reinsert the card. There are no plans to change this behavior.
DDTS # CSCee25136
If you create a PM schedule with the Start time for the PM report equal to 00:00 (in TL1, "0-0"), after a few minutes the PM report start time might change to 23:59 (in TL1, "23-59"). This issue will not be resolved.
DDTS # CSCed23484
A user might remain in the logged-in state after rebooting the PC while logged into a node running CTC. The user login will time out once the "Idle User Timeout" limit is up. Alternatively, you can log in as a superuser and force the user off. This issue will not be resolved.
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 # CSCdy57891
An LOP-P alarm can be inadvertently cleared by an LOS that is raised and cleared. On OC48AS, OC192, and OC12-4 cards, when an LOP condition and an LOS condition are both present on the input, an LOS will be raised as per Telcordia GR 253 alarm hierarchy. However, upon clearing the LOS with the LOP still present, the LOP alarm, which should then be raised, is not. An AIS-P condition will be visible. This issue will be resolved in Release 6.0.
DDTS # CSCds88976
When a new circuit is created around a ring (path protection or BLSR), the SD BER or SF BER alarm can be raised depending on the order in which the spans are provisioned. The alarms will eventually clear by themselves. Traffic is not affected. This issue will not be resolved.
DDTS # CSCdu82934
When you auto-route a VT circuit on an ONS 15454 node, a path is computed based on the availability of STSs on the nodes involved. This selection process, when combined with a lack of VT matrix (or STS-VT connections) on an auto-route selected node, can result in the VT circuit creation failing with the message "unable to create connection object at node." To correct this situation, manually route VT circuits in cases when auto-routing fails. The error message will indicate which node is at issue.
DDTS # CSCef28522
When you inject errors on a splitter protection card in the node's working port, CVL and ESL are incremented for the working and protect far end ports. This issue will not be resolved.
DDTS # CSCuk49106
The amplifier gain set point shown by CTC and the actual measured amplifier gain differ. The following steps illustrate this issue.
Step 1
Step 2
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.
DDTS # CSCuk52850
In a fiber cut scenario on the LINE-RX, with OSC and channels provisioned, transient LOS-P or LOS-O alarms might be raised. This issue will be resolved in Release 6.0.
DDTS # 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.
DDTS # CSCef29516
The ALS pulse recovery minimum value is 60 instead of 100. If this occurs, increase the value to 100. This issue will not be resolved.
DDTS # 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 LOC 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. It is not known when or if this issue will be resolved.
DDTS # 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 has been closed and will not be resolved.
DDTS # CSCdx35561
CTC is unable to communicate with an ONS 15454 that is connected via an Ethernet craft port. CTC does, however, communicate over an SDCC link with an ONS 15454 that is Ethernet connected, yielding a slow connection. This situation occurs when multiple ONS 15454s 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 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 15454s.
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 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 # CSCdy56693
Microsoft Windows XP uses more memory than previous Microsoft operating systems, and this may result in reduced CTC performance. To avoid reduced performance, you can:
•
•
•
•
•
DDTS # CSCdy62092
When a node connected via SDCC has no Ethernet LAN connectivity, display of SDCC termination alarms is delayed if the fiber connecting a DCC connected node is removed. This issue cannot 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. When this event occurs, Telcordia GR-253 specifies that CVs that occurred during this time be counted, but they are not. There are no plans to resolve this issue at this time.
DDTS # CSCdy55556
In a 1:N protection group, where a protect card is protecting a failed card and another working card, which is missing, has a lockon condition, upon removing the lockon condition from the missing working card, the protect card may switch from the card it had been protecting to carry the traffic of the missing working card that just had the lockon removed. To avoid this issue, replace the failed working card before removing the lockon. This issue will be resolved in a future release.
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.
NE Defaults
The following caveats apply for NE defaults when managing older, non-Release 4.5 nodes.
•
•
•
ONS 15454 Conducted Emissions Kit
If you are deploying the Cisco ONS 15454 within a European Union country that requires compliance with the EN300-386-TC requirements for Conducted Emissions, you must obtain and install the Cisco ONS 15454 Conducted Emissions kit (15454-EMEA-KIT) in order to comply with this standard.
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.
Common Control and Cross Connect Cards
DDTS # CSCeh08430
Rarely, short line card data hits can occur intermittently on a variety of circuits when the active TCC2P card is removed while the XC-VXC-10G card is being used. This issue is under investigation.
DDTS # CSCdw27380
Performing cross connect card switches repeatedly might cause a signal degrade condition on the lines or paths that can trigger switching on these lines or paths. If you must perform repeated cross connect card switches, lock out the corresponding span (path protection, BLSR, or 1+1) first. This issue will not be resolved.
Active Cross Connect (XC10G/XCVT) or TCC2/TCC2P Card Removal
You must perform a lockout in BLSR, path protection, and 1+1 before physically removing an active cross connect (XC10G/XCVT) or TCC2/TCC2P card. The following rules apply.
Active cross connect (XC10G/XCVT) cards should not generally be physically removed. If the active cross connect or TCC2/TCC2P card must be removed, you can first perform an XCVT/XC10G side switch or TCC2/TCC2P reset 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). No lockout is necessary for switches initiated through CTC or through TL1.
Caution
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.
Optical IO Cards
DDTS # CSCdw66444
When an SDH signal is sent into an ONS 15454 OC-12/STM-4 (IR, 1310 LR and 1550 LR) or an OC-48/STM-16 high-speed (IR and LR) port which has been configured to support SDH, an SD-P (Signal Degrade) alarm will appear as soon as the circuit is created. This alarm will continue to exist until the circuit is deleted.
To avoid this problem, when provisioning an OC-12/STM-4 (IR, 1310 LR and 1550 LR) or an OC-48/STM-16 high-speed (IR and LR) port to support SDH, disable the signal degrade alarm at the path level (SD-P) on the port.
Also, PM data at the path level will not be reliable. You must set associated threshold values to 0 in order to avoid threshold crossing alerts (TCA) on that port. The path threshold values to set to zero are CV-P, ES-P, SES-P, and UAS-P.
These issues are the result of a hardware limitation, and there are no current plans to resolve them.
DDTS # CSCdw09604
If you are using an XC10G with OC-48, you must use either OC-48AS or OC-48 cards with a revision number higher than 005D.
Electrical IO Cards
DDTS # CSCsb43614
An EC1-12 card might incorrectly report a loss of signal as LOF when a receive input is absent. This can be seen by placing a port in service or creating a circuit in the absence of a signal. This issue will be resolved in a future release.
DDTS # CSCsb56826
If you have a long cable connected to a DS3/EC1-48 port for which the LBO parameter has been provisioned for long (256-450), SD might occur with cable lengths of 900 ft or greater. Occurrence of this issue is dependent upon the slot the card is in, the port you are using, the type of UBIC you are using, and the type of cable you are using. This issue can occur on Slot 1 or Slot 17, for Ports 14, 27, or 28 of the DS3/EC1-48 card. This issue is more likely to occur after a node power cycle. This issue will be resolved in Releases 5.0.6 and 6.0.
DDTS # CSCeg79605
When a DS3 STS1 path protection circuit that is not a "Go and Return" circuit is upgraded to BLSR via ISTU, the circuit might take a long hit in one direction. To avoid this issue use Go and Return path protection circuits when upgrading DS3 STS circuits from Unprotected to path protection. This issue will be resolved in Release 6.0.
DDTS # CSCdx40300
A transient WKSWPR condition is raised upon deletion of a DS3XM 1:1 protection group. This issue will be resolved in a future release.
DDTS # CSCea58275
In a 1:N protection group, the DS3N card will attempt to protect a preprovisioned card (that is, when you right-click an empty card slot in the CTC node view and select the DS3 card), leaving it unavailable to protect another, actual card that is also in the protection group, should that card fail. To avoid this issue, do not include the pre-provisioned card in the protection group. Once the card is physically installed, you can edit the protection group and add the card.
DDTS # CSCec39567
Deleting a DS3I 1:N protection group may leave the protect card LED in a standby state. This can occur in a DS3I 1:N protection group with a LOCKON applied to the working card (ONS 15454 ANSI chassis only). Upon deleting the protection group, the LED on the protect DS3I card and the CTC display are still in the standby state. Soft reset the protect card to update the LED on the card and in CTC. An alternative workaround is to remove the LOCKON before deleting the protection group. This issue will be resolved in Release 6.0.
Data IO Cards
DDTS # CSCeg90341
A greater than 2 second traffic hit can occur with 255 subinterfaces on DRPRI. This issue can occur when the GEC member interface is shut/fiber-pull. This issue will be resolved in Release 6.0.
DDTS # CSCeg86115
When traffic is switched from one GEC member to the other GEC member in a DRPRI node, the traffic hits could be between 400 ms and 2 seconds. This issue can occur when one of the GEC member interfaces goes down. This issue will be resolved in Release 6.0.
DDTS # CSCeg87785
A greater than 200 ms traffic hit can occur when an active DRPRI node is reset. This issue can occur with a soft or hard reset of ML1000 in a DRPRI setup. For manual resets, shut down the Gig ports before issuing reload to avoid this issue. This issue will be resolved in Release 6.0.
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 # CSCeh26707
Loss of Ethernet signal on one of the front ports takes longer than expected to be propagated to the remote port. Link integrity operates slower than expected for Ethernet failures (though it works as expected for SONET failures). To see this, any condition that causes an Ethernet loss of signal (removal of a front port Ethernet cable, for example) will invoke the Ethernet integrity function. This issue will be resolved in a future release.
DDTS # CSCef46191
A specifically crafted Transmission Control Protocol (TCP) connection to a telnet or reverse telnet port of a Cisco device running Internetwork Operating System (IOS) might block further telnet, reverse telnet, Remote Shell (RSH), Secure Shell (SSH), and in some cases Hypertext Transport Protocol (HTTP) access to the Cisco device. Telnet, reverse telnet, RSH and SSH sessions established prior to exploitation are not affected.
All other device services will operate normally.
The detail advisory is available at:
http://www.cisco.com/warp/public/707/cisco-sa-20040827-telnet.shtml
DDTS # CSCeg15044
IOS does not allow telnet connections when there are simultaneous Telnet requests, even though there might be unused tty lines available. If this issue occurs, a "No Free TTYs error" message is displayed. This issue will be resolved in a future release.
DDTS # CSCdy37198
On Cisco ONS 15454s equipped with XCVT cross-connect cards, neither the E100T-12 nor the E1000-2 cards raise an alarm or condition in CTC when Ethernet traffic is predictably lost due to the following circumstances:
Circuits exist between Ethernet cards (E100T-12 and/or E1000-2) built over Protection Channel Access (PCA) bandwidth on BLSR spans. When BLSR issues a switch, the PCA bandwidth is preempted. Since there is no longer a connection between the ends of the Ethernet circuit, traffic is lost.
Note
This issue will be resolved in a future release.
DDTS # CSCdr94172
Multicast traffic can cause minimal packet loss on the E1000-2, E100-12, and E100-4 cards. Packet loss due to normal multicast control traffic should be less than 1%. This issue was resolved in Release 2.2.1 for broadcast, and in Release 2.2.2 for OSPF, and some multicast frames. As of Release 3.0.3, the ONS 15454 supports HSRP, CDP, IGMP, PVST, and EIGRP, along with the previously supported broadcast and OSPF.
Note
Note
Note
Multicast MAC addresses used by the control protocols in Table 4 have been added to the static MAC address table to guarantee no loss of unicast traffic during normal usage of these MAC addresses.
E1000-2/E100T
Do not use the repair circuit option with provisioned stitched Ethernet circuits.This issue is under investigation.
Single-card EtherSwitch
Starting with Release 2.2.0, each E100/E1000 card can be configured as a single-card EtherSwitch configuration to allow STS-12c of bandwidth to be dropped at each card. The following scenarios for provisioning are available:
1.
2.
3.
4.
5.
6.
7.
When configuring scenario 3, the STS-6c must be provisioned before either of the STS-3c circuits.
Multicard EtherSwitch
When deleting and recreating Ethernet circuits that have different sizes, you must delete all STS circuits provisioned to the EtherSwitch before you create the new circuit scenario. (See the preceding "Single-card EtherSwitch" section 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.
DDTS # CSCds02031 E1000-2/E100
Whenever you drop two 3c multicard EtherSwitch circuits onto an Ethernet card and delete only the first circuit, you should not provision STS-1 circuits to the card without first deleting the remaining STS-3c circuit. If you attempt to create an STS-1 circuit after deleting the first STS-3c circuit, the STS-1 circuit will not work and no alarms will indicate this condition. To avoid a failed STS-1 circuit, delete the second STS-3c prior to creating any STS-1 circuit.
DDTS # CSCeg30605
The diagnostics information provided for ML cards in the diagnostic file is incomplete. This issue will be resolved in a future release.
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. For documentation of this command, consult the Ethernet Card Software Feature and Configuration Guide.
DDTS # CSCec52443
On an ML-series RPR ring circuit deletion or creation causes an approximately 200 ms traffic loss. 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, 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 # CSCea46580
SPR input counters do not increment on a BVI with an SPR interface. This issue will not be resolved.
DDTS # CSCea35971
A monitor command may disappear from the configuration after a TCC reboots. To avoid this issue, use the exec command, "terminal monitor," instead (a minor drawback is that this command applies to all VTYs), or, alternatively, reapply the monitor command after connection is lost. This is as designed.
DDTS # CSCdz49700
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 # 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. This issue will not be resolved.
DDTS # CSCdy47284
ML-100 FastEthernet MTU is not enforced. However, frames larger than 9050 bytes may be discarded and cause Rx and Tx errors.
DDTS # CSCdz74432
Issuing a "clear IP route *" command can result in high CPU utilization, causing other processes to be delayed in their execution. To avoid this issue do not clear a large number of route table entries at once, or, if you must use the "clear IP route *" command, do not install more than 5000 EIGRP network routes.
DWDM Cards
DDTS # CSCeg42512
Occasionally, jumbo packets are not counted in the Performance Monitoring tab for the TXP-MR-10E. This issue can occur with Ethernet traffic running on a TXP-MR-10E, where the trunk side of the card is set up for 10E LAN with G.709 and FEC. JUMBO packets (2500 bytes) flow through the client port, but the oversized packet counter is not incremented. This is a hardware issue that cannot be resolved.
DDTS # CSCei04981, CSCeg42532
The ifInErrorBytePkts counter for TXP-MR10-E cards running Ethernet traffic might fail to report negative or inconsistent numbers. This issue will be resolved in a future release.
DDTS # CSCei64727
The GFP-CSF alarm might oscillate on the MXP-MR-2.5G card. This issue can occur when you have two MXP-MR-2.5G cards connected back to back, and you generate either a loss of signal, or a loss of sync at the near end client receive port. This should result in a GFP-CSF alarm at the far end for the duration of the condition; however, the GFP-CSF alarm is intermittently raised and cleared.
Although this issue has been seen predominantly in a Y cable protected configuration, it can also occur in an unprotected configuration, with any payload type. In a Y cable configuration with Distance Extension on, this issue is easily reproducible and continuous protection switches can occur due to the oscillating alarm. This issue will be resolved in a future release.
DDTS # CSCuk56032
Facility Loopback on a TXP-MR-10E trunk port can cause a traffic outage. This can occur when you have two TXP-MR-10E cards on two ETSI systems connected to each other on trunk ports, with running traffic, and a GCC is created, then a Facility (LINE) loopback is set on the Trunk port of one TXPs. Traffic goes down permanently and the following conditions are reported by the transponder where the loopback has been set:
•
•
•
The other transponder raises following alarms:
•
•
Releasing the Facility loopback restores the original situation with traffic running fine. This issue will be resolved in a future release.
DDTS # CSCuk56248
The Span Loss Verification feature is not available in Release 5.0.x. This can be seen when a Booster Enhanced is present in the node (BST-ENH). This issue will be resolved in Release 6.0.
DDTS # CSCuk56210
If, on a TXP-MR-10E card client port, the "synch msg" option is deselected (SSM-OFF) and then reselected, the message synchronization remains OFF. This can occur when you have two TXP-MR-10E cards connected via their trunk ports, the client port is the timing source for the node, and Synch messages are ON. When Synch messages are turned off from CTC, and then ON, the SSM-OFF message remains. To recover from this issue perform a software reset of the affected card. This is non-traffic affecting. This issue will be resolved in a future release.
DDTS # CSCef71428
If two TXPP-MR-2.5G units are connected via trunk ports, with the Working Trunk facility set to OOS,DSBLD state, and a FORCE switch is applied on the working trunk, and then the working port is put into OOS,DSBLD state, the WKSWPR condition in the Conditions pane fails to clear. This issue will be resolved in a future release.
DDTS # 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
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
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.
DDTS # 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
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
RMON TCAs are not raised for any port. This issue will not be resolved.
DDTS # CSCuk48503
Under very specific conditions the MXPD fails the Telcordia GR-253/G.825 Jitter generation mask test on the 10G transmit trunk port. The 2.5 G transmit client jitter generation remains within mask and does not exhibit this issue.
This only occurs when, in SONET mode, with no FEC, no G,709, and client interfaces looped back, with non-synchronous clocking, and performing the following steps.
Step 1
Step 2
The jitter testbox TX clock recovers from RX with an additional 5 ppm offset added. This issue will not be resolved.
DDTS # 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
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
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.
DDTS # CSCef13304
Incorrect ALS initiation causes a traffic outage on an FC payload. This issue can be seen by performing the following steps.
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
ALS is now initiated on TXP-1 port 2 (trunk) and the laser shuts down. Traffic never comes back.
Note
To recover from this situation, perform a manual restart or disable the ALS in this configuration. This issue will not be resolved.
DDTS # CSCuk51184
When downloading Release 4.7 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.
DDTS # 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
Step 2
Step 3
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.
DDTS # 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.
DDTS # 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
Step 2
Step 3
Step 4
During the EOW circuit provisioning only the MXP/TXP client ports are listed for the selection. This issue will not be resolved.
DDTS # CSCuk51185
After a soft reset of an OSCM or OSC-CSM card, a CONTBUS-IO alarm is raised. This issue will not be resolved.
DDTS # 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 be resolved in a future release.
DDTS # CSCee45443
When the FICON bridge does not receive the expected number of idle frames between data packets it will transition to SERV MODE. This issue will be resolved in a future release.
DDTS # 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.
DDTS # 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.
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. This is as designed.
DDTS # CSCea78210
The TXP_MR_2.5G and TXPP_MR_2.5G cards do not support TX Optical power performance monitoring on the trunk port. This is as designed.
DDTS # CSCeb32065
Once engaged, 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 # 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 # 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.
SNMP
DDTS # CSCed05502 and CSCef43911
SNMP Traps are generated for TCA when the OC3-4 port state is OOS-AINS/MT (whereas TL1 TCAs are inhibited). This issue will be resolved in a future release.
Alarms
DDTS # CSCed64269
The "Failed SW-Prot-Ring" alarm reports inconsistently. The alarm only sometimes appears when a Lockout of Protection is present on the BLSR and a transmit or receive fiber is pulled on the node with the Lockout. This issue will be resolved in a future release.
Interoperability
DDTS # CSCds13769: Fujitsu FLM-150 and Nortel OC-3 Express
You cannot provision the FLM-150 and OC-3 Express in 1+1 revertive switching mode. The problem occurs when the ONS 15454 issues a user request in revertive mode to the protect channel. When the user request is cleared, the ONS 15454 issues a No Request. However, the FLM-150 and OC-3 Express issues a Do Not Revert, which causes traffic to remain on the protection channel. Based on Telcordia GR-253, section 5.3.5.5, the FLM-150 and the OC-3 Express should respond with a No Request.
BLSR Functionality
DDTS # CSCed10127
Extra traffic is not restored when an SF-R occurs on the same span where a lockout of protect is applied at the opposite node, and where the extra traffic is sourced, destined, or travels through the node with the SF-R. to work around this, issue a lockout on each end of the span at the node where the SF-R occurs. Extra traffic should then be restored. This issue will not be resolved.
DDTS # CSCea59342
DS3 PCA traffic may take up to 20 seconds to recover after a BLSR switch is cleared. This can occur with DS3 PCA traffic on two-Fiber or four-Fiber BLSR configuration with XCVT cards in the same nodes as the DS3 cards. This issue will be resolved in a future release.
DDTS # CSCdw58950
You must lock out protection BLSR, 1+1, and path protection traffic to avoid long, or double traffic hits before removing an active XCVT or XC10G card. You should also make the active cross connect card standby before removing it.
DDTS # CSCdv53427
In a two ring, two fiber BLSR configuration (or a two ring 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.
DDTS # CSCct03919
VT1.5 and VC3/VC12 squelching is not supported in BLSR/MS-SPRing.
Database Restore on a BLSR
When restoring the database on a BLSR, follow these steps:
Step 1
Step 2
Step 3
Step 4
Path Protection Functionality
DDTS # CSCee53579
Traffic hits can occur in an unprotecte
Guest
