Release Notes for Cisco ONS 15305 Release 2.0.4

Table Of Contents

Release Notes for Cisco ONS 15305 Release 2.0.4

Contents

Software Upgrade Procedure

General Important Information

Changing Default Setting for DCC IpEncapsulation

Network Release Content R.2.0.4

Contents of Network Release 55004-01BA_PM_ED16.zip File

Upgrade Procedure

Before You Begin

Upgrading from R2.0.0 to R2.0.4

Upgrade Time

Release Level Verification (After Upgrade)

Example for Release Verification for System Controller

Caveats for R2.0.4 and R2.0.3

Resolved Caveats for R2.0.4

OCN (IP/IPUN): CDB Restore May Fail

OCN (PPP): PPP Improvements

OCN (IP/IPUN): Software Issues Could Cause Spontaneous Restarts for the NE in IP Unnumbered DCN Topologies (Critical)

CDB Cannot be Restored

Modules Containing Ethernet Switches Do Not Initialize

Device Restart During Bulk-Transfer

Miscellaneous Synchronization Problems for SSM Enabled T0 Candidates

Resolved Caveats for R2.0.3

OCN: Unnecessary LINK_DOWN Events Reported in History After Bootup or Restart

OCN: IS-IS Issue Causing Suboptimal Performance for Third Party Devices in an OSI DCN

Misc: Intermittent Power Module Out Alarms

Misc: Software Download Flash Failure

Misc: RMON Probes on Ethernet Ports Could Cause Restarts

Ethernet: Correlation of WANX and WAN Alarms

Ethernet Over SDH: Persistent WrongSeqChannel Alarm for AXXESSIT Proprietary Mapping (Major)

SDH: T0 Holdover Was Reported After a Software Reset

SDH: T0 Synchronization Entries (E12/EXT) Had Default SSM-enabled Setting

SDH: Changed Threshold for Pointer Justification Alarm Reporting

SDH: Software Restart Could Cause a Short Interrupt of SDH Traffic Being Transported by STM-4 and STM-16 Aggregates (Major)

SWDL: Improved SWDL Triggering (Major)

Misc: Improved Process Prioritizing to Avoid Conflicts Causing Software Restart (Critical)

Misc: Time Protocol Did Not Accept TP Update Interval Larger Than 1093 Minutes

Misc: Improved Diagnostics in AXXCLI to Determine Fault Conditions and Configuration Issues

Misc: Corrected MNGT-Port Disable and Enable Handling

DCN (IP/IPUN): Added O-bit in Hello Similar to DD-Packets

ETHERNET: Spontaneous Restart Triggered When Receiving a Specific BootP Frame (Major)

ETHERNET: IS-IS Multicast Frames Are Not Properly Filtered (Major)

Misc: Too Short Interval Range for System-Up-Time

Misc: Software Default Parameter Changes

Misc: Changed for Default Severity of Epj Alarm Conditions

Misc: Improved Diagnostics in AXXCLI to Determine Fault Conditions and Configuration Issues

DCN (IPUN): Removed the Gateway Owner Command for Nodes Without L3 License

Misc: Interrupt Avalanche When Optical Loop on Selected Sync-Source

Misc: Power Alarms for Overloaded AXXEDGE Chassis

ETHERNET: LED Status for Ethernet Ports on 2xGE+SMAP Module Did Not Properly Display Link and Status for Traffic

Misc: Incorrect Power Module attributes Was Displayed After Power Change. (AXXCRAFT R.2.0 ICS04 and Onwards)

Misc: Hanging Power Alarms When Changing Power Modules.

Misc: Changing IpmFftMaxEntriesAfterReset Did Not Prompt to Restart the Node to Activate Configuration

Misc: Spontaneous Reboots Caused by Memory Overflow and SNMP Bad Value (Critical)

Misc: CDB-Restore Provokes FATAL-ERROR (Provider-tag Enabled) (Major)

DCN (IPUN): Lost IP Connectivity in Multiple OSPF Areas (Major)

Ethernet Over SDH: WAN-Delay Alarm for WANx- and LANx-Ports (in L1) With AXX-Proprietary EoS Mapping Missing

DCN (IPUN): Incorrect OSPF Interface Table Content

DCN (IPUN): Change of IP (in AXXCLI) Was Not Possible When OSPF Was Enabled

DCN (IPUN): NE Reboots When Adding OSPF Area Number 8 (Major)

DCN (IPUN): Routing Ceases to Work Because of Loss of Management Connectivity (MAJOR)

DCN (IPUN): Node Not Reachable After Software Reset

DCN (IPUN): IP Address Already in Use is Reported on NE

DCN (IPUN): The IPUN Router Could Cause Severe IP Problems in a LAN (Major)

DCN (IP/IPUN): L1CC (Inband) Ports Support CSF Alarm Condition (AXXCRAFT R.2.0 ICS04 Onwards)

DCN (IP/IPUN): IP Inband (L1CC) Did Not Work for 2xGE_SMAP in Mode 192 KBS

DCN (IP/IPUN): PPP/DCC Problem With SDH Loop-Back

DCN (IP/IPUN): Change of DCN System Mode Should Raise a Warning

DCN (IP): PPP link on DCC Was Not Taken Down or Up When Configuring the IP Address (AXXCRAFT R.2.0 ICS04 Onwards)

DCN (IP): Disabling OSPF Generates Fatal Error if Stub Area Exists (Major)

ETHERNET: Static Unicast Fatal Error (Major)

ETHERNET: RSTP and GVRP Conflict Caused Fatal Error (Major)

ETHERNET: VLAN-Tagged IGMP Packets Bypass Ingress Filtering (Major)

ETHERNET: Modifying or Adding a Description on a LANx-Port or WANx-Port May Cause Interrupt of Ethernet Traffic (Major)

ETHERNET: Maximum Aging Time is 630 Seconds

Ethernet Over SDH: VCAT-VC4 (LCAS) WithinCapacityUpStream NOK

Ethernet Over SDH: Grooming Mode, 2xLANx-Port and 14xWANx-Port Did Not Function Properly (Critical)

Ethernet over SDH: Ethernet Over SDH Cross-Connections on VC-4 Level with SNC/N Leave NIM Hanging

SDH/TDM: G.826/829 Counters Did Not Properly Report Historical Performance Data

SDH: Synergy Between EgressSSM and Selected SYNC-Source

CPU on System Controller Seems to Run at Half Speed (Critical)

Known Caveats for R2.0.4

Obtaining Optical Networking Information

Where to Find Safety and Warning Information

Cisco Optical Networking Product Documentation CD-ROM

Obtaining Documentation and Submitting a Service Request

Release Notes for Cisco ONS 15305 Release 2.0.4

---

OL-21367-01

May 2010

The release notes covers the software upgrade procedure from earlier releases to Cisco ONS 15305 Release 2.0.4. It also addresses resolved issues and caveats for the Cisco ONS 15305 platform. The Cisco ONS 15305 Release 2.0.4 does not include any new features. For detailed information on bugs fixed, refer to the respective sections in this document.

For the most current version of the Release Notes for Cisco ONS 15305 Release 2.0.4, visit the following URL:

http://www.cisco.com/en/US/docs/optical/15000r2_0_4/release/notes/305_204_rn.html

Cisco also provides Bug Toolkit, a web resource for tracking defects. To access Bug Toolkit, see the following URL:

http://tools.cisco.com/Support/BugToolKit/action.do?hdnAction=searchBugs

---

Note Unless otherwise specified, "ONS 15305" refers to Cisco ONS 15305.

---

Contents

Software Upgrade Procedure

Caveats for R2.0.4 and R2.0.3

Obtaining Optical Networking Information

Obtaining Documentation and Submitting a Service Request

Software Upgrade Procedure

General Important Information

We recommend that you use the latest version of Management Software when you upgrade a network element (NE) from an older release. This is because an upgrade may imply either a change in the object identifier (OID) or a change in feature attributes for features supported by the device, or both. Any management software that Ericsson supplies would require support for the new OID and changed feature attributes. Check the release note for the management software about supported NE versions.

If you are using AXX 9820 CRAFT, you may require to reconnect to the device to re-synchronize the changes after download.

History of changes in object ids for the ONS 15305:

•R1.01.3.6.1.4.1.7546.1.4.1.1.1

•R1.11.3.6.1.4.1.7546.1.4.1.1.2

•R2.01.3.6.1.4.1.7546.1.4.1.1.3

Cisco Edge Craft (CEC) R.2.2 is the minimum required for operating this network release of ONS 15305. Cisco ONS 15305 2.x includes CEC and network release.

---

Caution Do not insert the new Ethernet modules such as 2xGE + SMAP, 8xFE + SMAP, and 8xFE-SFP, before the NE is upgraded to network release 2.x. The software package must be loaded on the Compact Flash card. Both the main card and system controller must be upgraded before the modules are inserted, else it will cause the device to continuously restart.

---

---

Note When upgrading from a device running release 1.x, download the system controller software (45004-77BA_PM_ED16.bin) separately before you upgrade to R.2.1. When restarted, the network release download (55004-01BA_PM_ED16.def) can be issued, which will be stored in the Compact Flash card on the system controller.

---

---

Note Upgrading nodes, that have active DCC links, from R.1.x to R.2.0.4, may require reconfiguration of the DCC mode locally. Refer DDTS#CSCEG11010.

---

---

Note Spanning Tree Protocol (STP) for each VLAN is no longer a feature supported for ONS 15305. From R.2.x onwards, STP for each VLAN is removed and attributes are no longer available as management solutions. The implementation in R.1.x was according to an early draft of IEEE 802.1 and interoperability with third party vendors could not be guaranteed successful. An additional reason for this feature removal is the introduction of Rapid Spanning Tree Protocol (RSTP). An upgrade from R.1.x to R.2.x will turn off the STP for each VLAN algorithm, even though it is set in the CDB file.

---

Changing Default Setting for DCC IpEncapsulation

Reconfigure all DCC channels configured with mode set to IpOverDcc and IpEncapsulation set to proprietary (Figure 1).

For all DCC channels on the system where mode is set to IpOverDcc and IpEncapsulation is set to proprietary, the IpEncapsulation needs to be reconfigured before upgrading from R.1.x to R.2.0.4.

Figure 1 Default Setting for Mode and DCC IpEncapsulation

---

Note If the DCC IpEncapsulation is not reconfigured before upgrading to R.2.0.4, loss of connectivity over the DCC channels might occur.

---

---

Note For all DCC channels on the system where mode is set to notUsed, remModule, osi, or transparent, reconfiguration of IpEncapsulation is not required and must be skipped. For all DCC channels on the system where IpEncapsulation is set to ppp, this step is not required and must be skipped.

---

To change the default setting for DCC IpEncapsulation:

---

Step 1 Set IpEncapsulation to ppp.

Step 2 Set IpEncapsulation back to proprietary.

Step 3 Save this configuration.

Step 4 Upgrade software to R2.0 as described in "Upgrade Procedure" section.

Network Release Content R.2.0.4

The Cisco ONS 15305 Release 2.0.4 Network Release ensures that all files in the network release package is stored on the Compact Flash card of the system controller card. If a module is inserted after the upgrade to release 2.0.4, the module is updated automatically as the system controller verifies the firmware level and starts flashing a green LED on the module if it contains an older version. Alternately, the status of flashing is seen in the software download progress table. Depending on the module type, this may take some time to be completed. A constant green LED lighting on module indicates "in service" state. This can also be verified through CEC.

The automatic module update can be disabled for each module type in the Update Policy menu.

---

Note All traffic is interrupted when upgrading from R.1.x to R.2.0.4. When upgrading from release 1.x, the Ethernet Layer 2 traffic is interrupted twice. First, when restarting after an upgrade of the system controller and second, when restarting the node after the network release package is completely downloaded. The TDM traffic is interrupted when restarting the node after the complete network release download.

---

Contents of Network Release 55004-01BA_PM_ED16.zip File

When upgrading from older releases than R.2.0.3, you must read through the history of the release notes to check what traffic will be interrupted in your node configuration. Items in bold are new in this release (compared to R.2.0.3).

55004-01BA_PM_ED16.def (Network Release definition file)

45004-70AA_PM_ED06.bin Main Card FW (if bold, all traffic will be interrupted)

45004-72AA_PM_ED08.bin 8xSTM1 + 8xMAP / 8xSTM1_TDM FW (if bold, traffic on module will be 
interrupted)

45004-73AB_PM_ED04.bin STM16 FW (if bold, traffic on module will be interrupted)

45004-73AA_PM_ED03.bin STM16 FW (if bold, traffic on module will be interrupted)

45004-74AA_PM_ED06.bin 8xE1 FW (if bold, traffic on module will be interrupted)

45004-74AB_PM_ED01.bin 8xE1 FW (if bold, traffic on module will be interrupted)

45004-76AA_PM_ED04.bin 6xE3 FW (if bold, traffic on module will be interrupted)

45004-77BA_PM_ED16.bin SYSTEM SW (if bold, all Ethernet traffic will be interrupted)

45004-80AA_PM_ED02.bin 4xSTM4 FW (if bold, traffic on module will be interrupted)

45004-81AA_PM_ED04.bin 2xSTM4 FW (if bold, traffic on module will be interrupted)

45004-82AB_PM_ED04.bin 63xE1 FW (if bold, traffic on module will be interrupted)

45004-83AA_PM_ED03.bin 21xE1+3xE3 FW (if bold, traffic on module will be interrupted)

45004-84AA_PM_ED03.bin 2xSTM1 FW (if bold, traffic on module will be interrupted)

45004-85AA_PM_ED06.bin 4xFE+4xMAP FW (if bold, traffic on module will be interrupted)

45004-87AA_PM_ED07.bin 8xMAP FW (if bold, traffic on module will be interrupted)

45004-88AA_PM_ED03.bin 2xSTM1+21xE1 FW (if bold, traffic on module will be interrupted)

45004-89AA_PM_ED02.bin 3xE3 FW (if bold, traffic on module will be interrupted)

45004-90AA_PM_ED07.bin 8xFE+16xSMAP FW (if bold, traffic on module will be interrupted)

45004-91AA_PM_ED07.bin 2xGE+2xSMAP FW (if bold, traffic on module will be interrupted)

45004-90AB_PM_ED06.bin 8xFE+16xSMAP FW (if bold, traffic on module will be interrupted)

45004-91AB_PM_ED06.bin 2xGE+2xSMAP FW (if bold, traffic on module will be interrupted)

45004-92AA_PM_ED02.bin 63xE1 FW (RAI) (if bold, traffic on module will be interrupted)

45016-01BA_PM_ED04.bin AXX10/AXX11 SW (if bold, traffic will be interrupted)

---

Note Some module types are listed with several FW-files (AA/AB). These files are related to specific hardware with either specific ICS or variants. Download procedures only allow modules to be upgraded with compatible FW (meaning matching product-number, including variant-code. For example, 45004-91AB).

---

Upgrade Procedure

When using CEC R.2.2, there are two different options for upgrading the ONS 15305. The first option is to use the option from the Management Tree with an external TFTP server. The second option is to use the NE maintenance GUI with the internal TFTP server in CEC R.2.2. This section explains how to upgrade the ONS 15305 using an external TFTP server.

Note that there are different upgrade procedures based on which release you upgrade from.

Before You Begin

•Install CEC R.2.2 on a PC.

•A third party TFTP server is installed and available from the PC running CEC or on a separate PC in the DCN.

•Unzip the ONS 15305 R2.0.4.package.zip package into the TFTP root folder.

Upgrading from R2.0.0 to R2.0.4

To upgrade Cisco ONS 15305 Release 2.0.0 to Cisco ONS 15305 Release 2.0.4:

---

Step 1 Download the complete network release package to the Compact Flash card (Figure 2). The filename is 55004-01BA_PM_ED16.def and the menu path is CiscoEdgeCraft - Device\SwDownload.

Figure 2 Download of Network Release Package to Compact Flash

Step 2 Click Save in CEC to start the download and follow the progress of files being sent from the TFTP server. When all the files have been sent, the flashing of modules inserted will start. This progress can be monitored in the SwdlProgress table.

---

Note If a manual restart is desirable instead of an automatic option, verify the status of download in the SwdlProgress menu. Any attempts to restart the system controller during the download or flash period will lead to unpredictable behavior.

---

---

Note Flashing of inserted traffic modules and main card will not start until all files in the network release have been downloaded through TFTP.

---

Upgrade Time

The total upgrade time varies depending of equipped modules. Typically an upgrade from R.2.0.1 to R.2.0.4 takes approximately 30 minutes when directly connected through the management port. This is based on the node, which is equipped with the following traffic modules:

•8xSTM-1

•2xSTM-4

•8xE1

•8xMAP

Release Level Verification (After Upgrade)

To ensure that the software update or upgrade has been successful, verify the operational status of the banks on traffic modules, base unit, and system controller. Ensure that the operational release is identified by the correct name and ICS. Crosscheck with names and edition (ICS) of files included in the network release package.

In Cisco ONS 15305 Release 2.0 (CEC R.2.2), a new feature Network Release Validation is introduced to facilitate the release level verification.

Example for Release Verification for System Controller

To verify the release:

---

Step 1 Identify the software name and edition for release 2.0 of the system controller software. The filename is 45004-77BA_PM_ED16.bin.

Step 2 Verify the operational status through the tree in AXXCRAFT (Figure 3).

Figure 3 Verify Operational Status in AXXCRAFT

Step 3 Verify the operational bank.

Step 4 Verify if the product number is the same as the first part of filename.

Step 5 Verify if the ICS is the same as the last part of the filename.

Caveats for R2.0.4 and R2.0.3

Review the notes listed below before deploying the ONS 15305. Caveats with tracking numbers are known system limitations that are scheduled to be addressed in a subsequent release. Caveats without tracking numbers are provided to point out procedural or situational considerations when deploying the product.

Resolved Caveats for R2.0.4

This section documents the resolved caveats for Release 2.0.4.

OCN (IP/IPUN): CDB Restore May Fail

An issue occurred that caused the CDB file restoration to fail for IP unnumbered configured NEs. Restore failed when the CDB contained route entries that exist in the working configuration. For example, this could be a static configured default.

OCN (PPP): PPP Improvements

Miscellaneous improvements are implemented for PPP. In previous releases, the PPP link was vulnerable to ending up in a lock state without reporting a CSF alarm. Additionally, the Echo Request counter was not reinitialized when a PPP channel was started.

OCN (IP/IPUN): Software Issues Could Cause Spontaneous Restarts for the NE in IP Unnumbered DCN Topologies (Critical)

Various improvements are now implemented for the IP unnumbered router to avoid spontaneous software restarts. The restarts could occur as a result of large OSPF topologies, recalculations, memory leakage, and routing table overflows. The stack is now proper.

CDB Cannot be Restored

Configuration Database Backup (CDB) taken on devices running ONS 15305 Release 1.1.1 and older releases cannot be restored on devices running ONS 15305 Release 1.1.1 and later releases. After ONS 15305 Release 1.1.1 (and later releases) is online, a new configuration backup should be maintained, which is forward compatible.

Modules Containing Ethernet Switches Do Not Initialize

When upgrading ONS 15305 from R.1.x, the modules containing Ethernet switches do not initialize (HotSwap Failure alarm). A solution for this issue (too short GALNET reset) is corrected from R1.1.1, but is only activated on the next system restart.

Workaround: Restart individual modules. Upgrade through a local management connection, even when the device is available through other management connections (affected module can be part of the management setup).

Device Restart During Bulk-Transfer

When preparing topology data for bulk-transfer, incorrect data was sent back to BXFER, leading to eternal loops, or even overwriting other code-areas. This results in watch dog-reset and external hard-reset restarts.

Miscellaneous Synchronization Problems for SSM Enabled T0 Candidates

A code change caused a destructive effect on the interaction between firmware (SETS) and software. The problems are noticed for synchronization schemes with SSM enabled and two or more T0 candidates.

Resolved Caveats for R2.0.3

This section documents the resolved caveats for Release 2.0.3.

OCN: Unnecessary LINK_DOWN Events Reported in History After Bootup or Restart

All DCC channels, even if not represented by DCC applicable HW, reported a link DOWN state in the notification history after a device was powered up (restarted).

OCN: IS-IS Issue Causing Suboptimal Performance for Third Party Devices in an OSI DCN

A software issue for IS-IS messaging caused suboptimal performance for third party management signals and application.

Misc: Intermittent Power Module Out Alarms

Power module out alarms were raised and cleared after a NE restart. When power alarms are enabled for power modules equipped in AXXEDGE, a raised and cleared power module out alarm occurred after software reset.

Misc: Software Download Flash Failure

To prevent software download lockup (SWDL-lockup), downloading processes have been improved, by a time supervision mechanism.

Misc: RMON Probes on Ethernet Ports Could Cause Restarts

Adding RMON probes on LANx-ports that are not yet physically equipped and known by the system, provoke a device restart. The RMON probe validation process is now extended with additional check to verify whether the port is physically equipped and known by the system.

Ethernet: Correlation of WANX and WAN Alarms

In previous releases, WANx specific alarms were reported against a WAN port. This mapping is now corrected. Refer to the Source field in the Alarm list view.

Ethernet Over SDH: Persistent WrongSeqChannel Alarm for AXXESSIT Proprietary Mapping (Major)

There was a possibility of a complete traffic disruption that could occur for AXXESSIT proprietary mapping. This issue was triggered by an SDH error present for a very short period of time on one or more of the involved channels, for example, incidents on intermediate nodes or SNCP switching. The condition was recognized by a persistent WrongSeqChannel alarm reported for one of the VC's in the group. In addition the port was reported down and the operational bandwidth reflected the administratively set bandwidth (1-50 VC-12s). The remedy was to set bandwidth to 0 and return it to desirable bandwidth again (on opposite WAN[x]-port).

SDH: T0 Holdover Was Reported After a Software Reset

Previous software releases implied a T0 holdover stage for a period after software reset. From this release onwards, this issue will not occur.

SDH: T0 Synchronization Entries (E12/EXT) Had Default SSM-enabled Setting

When adding E12/EXT synchronization references in the T0 table, the SSM field was always set to enabled. Since this field did not represent the selected ports (E12/EXT), the default value is now changed to disabled.

SDH: Changed Threshold for Pointer Justification Alarm Reporting

In the previous releases of ONS 15305, the Epj alarm was reported for a threshold of 100 justifications within a 15 minutes interval.

This low threshold caused alarms to be present for links even though the SDH traffic did not suffer severely. From this release onwards, a greater threshold (30000) is introduced. If it is desirable to keep a low threshold for raising Epj alarm, the operator may configure this from CRAFT/TMN.

SDH: Software Restart Could Cause a Short Interrupt of SDH Traffic Being Transported by STM-4 and STM-16 Aggregates (Major)

A software error caused a short traffic interruption (milliseconds) for SDH traffic (VCs).

SWDL: Improved SWDL Triggering (Major)

Enable SNMP to set the swdlTrigger operation faster to reduce re-entrance and conflict possibilities.

Misc: Improved Process Prioritizing to Avoid Conflicts Causing Software Restart (Critical)

•Moved up all priority 3 processes to priority 4. Now WatchDog and AXXCLI processes can run when other priority 4 tasks are heavily loaded.

•Enabled time-slice on AXXCLI process, so that WatchDog handler can run during AXXCLI running-config command execution.

•Refined UpdCDB handling (flowcontrol parameter setting) to prevent extra background load on the system.

Misc: Time Protocol Did Not Accept TP Update Interval Larger Than 1093 Minutes

Changed timer data from WORD to LONG to accept TP update interval larger than 1093 minutes. Maximum value now is 71.582.788 minutes.

Misc: Improved Diagnostics in AXXCLI to Determine Fault Conditions and Configuration Issues

•Minor corrections for status reports in running-config command.

•Minor corrections in the logging of bootup sequence stored as a part the display-debug-info command.

•Minor corrections for RIP parameters display.

•Reduction in information dumping in the running-config command, that is, MAC address table and alarm log.

Misc: Corrected MNGT-Port Disable and Enable Handling

Management port recovers (without the need of removing or reinserting the cable) when disabled and enabled again from the AXXCLI.

DCN (IP/IPUN): Added O-bit in Hello Similar to DD-Packets

ETHERNET: Spontaneous Restart Triggered When Receiving a Specific BootP Frame (Major)

An AXXEDGE connected to a DCN through any IP addressed Ethernet port rebooted after operating for some duration. The root cause was vulnerability for a specific BootP frame.

The following reason for boot could be captured from the VT100 during the restart:

FATAL ERROR: DHCP: Excm-CommonExceptionHandler - dump call-stack (?) 

ETHERNET: IS-IS Multicast Frames Are Not Properly Filtered (Major)

The Ethernet switch discarded large IS-IS multicast frames.

Typically frames with destination MAC address 01:80:C2:00:00:14, and :15 were forwarded by the CPU due to ASIC limitations.

A fix introduced for a MTU issue to resolve problems with IP connectivity in a large scaled DCN, introduced this problem. This fix caused the IS-IS multi-cast frames of sizes above 1500 to stop being forwarded.

Misc: Too Short Interval Range for System-Up-Time

The system-up-time counter wrapped around before the expected day. It should store the system-up-time up to approximately 497 days. A software bug caused this counter to wrap around after approximately 40 days.

Misc: Software Default Parameter Changes

•Alarm reporting for traffic modules changed from disabled to enabled¹ .

•EgressSSM for S1 byte changed from DoNotUse to T0² .

•Global alarm reporting for AXX10 and AXX11 changed from disabled to enabled.

•Default ageing time for bridge changed from 3600 seconds to 300 seconds (recommended by 802.1D).

Misc: Changed for Default Severity of Epj Alarm Conditions

Release 2.0 for AXXEDGE introduced an alarm to identify frequent pointer adjustments for configured AU-4 and AU-4-4c, and for either configured AU-4 or AU-4-4c.

The alarm is identified as Excessive Pointer Justification (Epj) in AXXCRAFT/TMN, and is raised by default if the number of justifications for each 15 minutes interval is greater than 100 minutes.

In order to clear Epj alarms, increase the threshold for alarm reporting or make sure that the network is properly synchronized.

Misc: Improved Diagnostics in AXXCLI to Determine Fault Conditions and Configuration Issues

•More information in running-config command (optical Rx, PM, SDH-port status, and so on).

•Miscellaneous corrections for status reports in the running-config command.

•Log of bootup sequence is now stored as a part display-debug-info command.

•Extended diagnostics for HW (SPI bus, VBAT, SETS FPGA).

DCN (IPUN): Removed the Gateway Owner Command for Nodes Without L3 License

Misc: Interrupt Avalanche When Optical Loop on Selected Sync-Source

When an optical loop was in place for a SDH port, which was a preferred synchronization source, there was reduced system performance. This is because the CPU could be busy, no response from CLI, and no IP connectivity.

This issue could be experienced for the following conditions:

•STM-n port defined as T0 synchronization source (SSM enabled)

•STM-n port Egress SSM = T0

•STM-n port looped optically

Misc: Power Alarms for Overloaded AXXEDGE Chassis

When using AXXCRAFT R.2.0 ICS04 and later releases, you can expect power alarms to be reported if the device is preconfigured or installed with traffic modules exceeding maximum supported power consumption for the chassis (105W due to heating) and as a limitation for the power module type. That is, 105W if fed by DC or 75W if equipped with AC module in one of the two power slots.

The alarm cannot be read in AXXCLI, as the alarm is a result of a power calculation performed in the Craft/TMN. Refer to the alarm document available in the Help menu for proposed troubleshooting and detailed descriptions for the two new power alarms.

ETHERNET: LED Status for Ethernet Ports on 2xGE+SMAP Module Did Not Properly Display Link and Status for Traffic

Misc: Incorrect Power Module attributes Was Displayed After Power Change. (AXXCRAFT R.2.0 ICS04 and Onwards)

When removing or replacing power modules in AXXEDGE, the power module attributes did not change dynamically in AXXCRAFT. A reconnect was required to get the attributes correct. This is definitely an issue when a power module is added in an empty power slot. In this case the power type remained "none" and the power module alarm attribute presentation was the defaults IN_A / IN_B, even when a 230 VAC power module was inserted.

Misc: Hanging Power Alarms When Changing Power Modules.

When changing from the 230 VAC power module type to 48 VDC, hanging alarms (-input low) were observed that referred to the previous module type (230 VAC).

Misc: Changing IpmFftMaxEntriesAfterReset Did Not Prompt to Restart the Node to Activate Configuration

AXXCRAFT R.2.0 ICS04 onwards you will be prompted to restart to apply change in configuration.

Misc: Spontaneous Reboots Caused by Memory Overflow and SNMP Bad Value (Critical)

The problem with memory overflow was especially sensitive for nodes connecting AXX10 and AXX11. A constant defining the AXXEDGE alarm-log size (5000) was misused in the AXX10/11 alarm-log size calculation. The extended alarm history log introduced in R.2.0 of AXXEDGE was not taking into account remote modules, and spontaneous restarts can be expected whenever the size of alarm log for remote modules exceeds 1000 historical alarms or events.

Misc: CDB-Restore Provokes FATAL-ERROR (Provider-tag Enabled) (Major)

AXXCRAFT R.2.0 ICS04 onwards the CDB restore provoke fatal error issue is resolved by enhanced logic and sequence control.

DCN (IPUN): Lost IP Connectivity in Multiple OSPF Areas (Major)

When the IP unnumbered network is running OSPF with multiple areas, it was observed that randomly the IP connectivity to NEs in other areas is lost.

Ethernet Over SDH: WAN-Delay Alarm for WANx- and LANx-Ports (in L1) With AXX-Proprietary EoS Mapping Missing

DCN (IPUN): Incorrect OSPF Interface Table Content

When changing the IP address on a node running IP unnumbered mode, the OSPF interface table incorrectly displayed the old IP address for the active instances listed in the table.

DCN (IPUN): Change of IP (in AXXCLI) Was Not Possible When OSPF Was Enabled

In previous releases for an AXXEDGE running IP unnumbered mode, the IP interface of the node could not be changed without temporarily disabling the OSPF.

DCN (IPUN): NE Reboots When Adding OSPF Area Number 8 (Major)

The maximum areas to be configured for IP unnumbered are 8. A software code error caused a spontaneous restart when adding the eighth area.

DCN (IPUN): Routing Ceases to Work Because of Loss of Management Connectivity (MAJOR)

One or more OSPF topology changes trigger the problem and cause loss of management connectivity to one or more NEs. The lost nodes are random and may occur on any node running OSPF in the topology. This is a severe DCN problem and all nodes running IP unnumbered with OSPF enabled should be upgraded.

DCN (IPUN): Node Not Reachable After Software Reset

When the node is running in IP unnumbered mode and IPUN gateway is disabled, the node was not reachable after software reset when connected to the management port.

A manual flush (arp -d) of ARP table on the connected computer recovered connectivity. The manual flush of ARP table is no longer required since a solution is implemented in this release.

DCN (IPUN): IP Address Already in Use is Reported on NE

IP address already in use is reported for a NE, which is configured to system mode IP unnumbered, with the IPUN Gateway disabled. If the NE was connected to the management port and a change was applied for the IP configuration of the NE, that is, change of IP address, this issue was observed. An improvement in the ARP proxy software improves this and makes the IP addressing more convenient.

DCN (IPUN): The IPUN Router Could Cause Severe IP Problems in a LAN (Major)

The AXXEDGE management port is connected to the LAN. System mode is IP unnumbered and IPUN Gateway is disabled.

After some time, the IP unnumbered configured node takes ownership for all potential IP addresses in the LAN. The network could not be recovered before the MNGT-port was disconnected from the LAN and other router ARP tables was flushed or aged out. An improvement is added in the ARP proxy software to avoid this issue from further occurrences.

DCN (IP/IPUN): L1CC (Inband) Ports Support CSF Alarm Condition (AXXCRAFT R.2.0 ICS04 Onwards)

No alarms were reported for L1CC in previous releases of R.2.0 of AXXEDGE. This made troubleshooting difficult.

DCN (IP/IPUN): IP Inband (L1CC) Did Not Work for 2xGE_SMAP in Mode 192 KBS

The L1CC (L1 Ethernet Communication Channel) configured in 192 kbs per mode (DCC-R equivalent) did not function as expected for the 2xGE_SMAP.

DCN (IP/IPUN): PPP/DCC Problem With SDH Loop-Back

Looping a SDH interface with a DCC channel configured in PPP mode will cause the link to go down. When the loop is removed, and the SDH link re-established, it is expected that the PPP connection will be re-established, but it did not. The PPP link remained in down state, hence no communication over the link was possible.

DCN (IP/IPUN): Change of DCN System Mode Should Raise a Warning

Even though a known issue describing the design limitations for changing router system mode in chapter 4.1.8, we have in addition added the procedure for this in the help options for the system mode attribute in AXXCLI. If you issue AXXCLI>Management-Modes\sys ? a list will be presented with the recommended procedure.

DCN (IP): PPP link on DCC Was Not Taken Down or Up When Configuring the IP Address (AXXCRAFT R.2.0 ICS04 Onwards)

When configuring DCC channels, the channel should have been taken down and then up again every time an IP address was configured on a DCC interface. Without a routine in place, IP connectivity cannot be obtained. In order to resolve this issue AXXCRAFT handles this during configuration. AXXCRAFT R.2.0 ICS04 and later releases must be used for successful operation.

DCN (IP): Disabling OSPF Generates Fatal Error if Stub Area Exists (Major)

Fatal error occurred when disabling OSPF if stub area exists.

The following call-stack could be read when monitoring the spontaneous boot through CLI or in the display-debug-info log in the AXXCLI:

000e98c4 HOSTP_copy_dump_info

000e9d54 HOSTG_fatal_error

0024cf3c OSSYSG_fatal_error

0024fdb0 OSMEMG_rn_free

00141d24 OSPFC_memory_free

0011ec28 OSPFP_free_lsa

00120fd8 OSPFC_deactivate_area

0011f93c OSPFP_deactivate_general

00121238 OSPFC_update_general

0013cae4 OSPFP_snmpGenSet

001d162c SNMPC_itc_call

001c0450 SNMPG_call

0011fdf4 OSPFP_task_receive

00236e78 CMNTSKP_task

0038bf40 task_wrapper_exit

ETHERNET: Static Unicast Fatal Error (Major)

If configuring a value for "AfterReset", in the Unicast-Global-Forwarding table, lower than the number of static entries in the table, and then selecting a software reset for the device, a device restart is observed.

The following message could be read when monitoring the spontaneous boot through CLI or in the display-debug-info log in AXXCLI: FATAL ERROR: ROOT: OSBUFG_buf_alloc: Invalid pool_id

ETHERNET: RSTP and GVRP Conflict Caused Fatal Error (Major)

When both Rapid Spanning Tree Protocol (RSTP) and GARP Vlan Registration Protocol (GVRP) run simultaneously, a device restart is observed when disabling GVRP.

The following message could be read when monitoring the spontaneous boot through CLI and/or in display-debug-info log in AXXCLI: FATAL ERROR: BRMN: OSTIMG_timer_delete: timer not stopped

ETHERNET: VLAN-Tagged IGMP Packets Bypass Ingress Filtering (Major)

IGMP packets reached the VLAN even though the ingress port was not a member of the VLAN. The incoming IGMP packets were VLAN-tagged and obtained the VID of a VLAN configured on the device. The ingress port was not a member of the named VLAN. In some rare configurations, this could create a loop in the topology, and a storm of replicated IGMP packets.

ETHERNET: Modifying or Adding a Description on a LANx-Port or WANx-Port May Cause Interrupt of Ethernet Traffic (Major)

The description field, typically used for customer identification, was modified. The event history showed a LAN-port down and up event. The traffic was interrupted for approximately 3 seconds for plain Ethernet bridge connections. If STP is activated in the network, then traffic interruption will be longer. Applied for LANx-ports and WANx-ports on the 8xFE + SMAP and 2xGE + SMAP modules.

ETHERNET: Maximum Aging Time is 630 Seconds

Due to a limitation in ASIC (Ethernet switch), it is not possible to configure more than 630 seconds for aging of MAC addresses in the Unicast-Global-Forwarding table. The previous provided range for this parameter has aging up to 3600 seconds, but the automatic aging overruled this and MAC addresses were aged out after approximately 630 seconds.

Ethernet Over SDH: VCAT-VC4 (LCAS) WithinCapacityUpStream NOK

The WithinCapacityUpStream flag was not set for VCAT-VC4 (LCAS).

Ethernet Over SDH: Grooming Mode, 2xLANx-Port and 14xWANx-Port Did Not Function Properly (Critical)

A code error caused the last 6 WANx-ports to cease passing traffic and the operational status was read as down in the management tools.

Ethernet over SDH: Ethernet Over SDH Cross-Connections on VC-4 Level with SNC/N Leave NIM Hanging

The code error applied LANx-ports and WANx-ports with VC-4 and soft LCAS mapping, and cross-connections with SNC/N protection. Deletion of cross-connections, or removal of the protection leg, leave the Non Intrusive Monitoring (NIM) objects behind.

SDH/TDM: G.826/829 Counters Did Not Properly Report Historical Performance Data

The table for history of PM counters for a VC-4 mapped with GE traffic incorrectly stated no BER conditions for previous intervals. For example, when reading PM counters for a VC-4 transporting Ethernet over SDH traffic, it was recognized that history of BBE and ES counters was not properly listed.

SDH: Synergy Between EgressSSM and Selected SYNC-Source

When the current synchronization source is a SDH port with SSM enabled, the EgressSSM (outward signalling on S1 byte) should state DNU (DoNotUse). Normally this is the behavior whether the EgressSSM on the STM-1 port is (default) configured as 'DoNotUse' or 'T0' (T0 to reflect the current synchronization quality).

An issue was observed if the EgressSSM of the STM-1 port was reconfigured from 'DoNotUse' to 'T0', while the port was the active or current synchronization source, the outward signalling, egressSSM/S1, would change from DNU to PRC (based on the current synchronization quality). Instead, the outward signalling should state DNU as the STM-1 port is still being synchronized.

CPU on System Controller Seems to Run at Half Speed (Critical)

A software error caused the SDRAM bus to perform at only 50% of the speed.

Problems such as reduced performance of traffic (DCN/Ethernet L2) and MNGT-port block could be typical symptoms of this bug. For some nodes being affected by this bug it was observed that the GUN/GOV for MCC1 and MCC2 reported in CLI and in display-debug-info log available from AXXCLI.

The SDRAM refresh rate could be incorrect on the system controller boards due to an undefined value in one of the SDRAM refresh rate configuration registers. This caused the refresh to appear many times faster then necessary on some boards, slowing down SDRAM access to up to 50%.

Known Caveats for R2.0.4

The known caveats for Release 2.0.4 are the same as that for Release 2.0.3.

Obtaining Optical Networking Information

This section contains information that is specific to optical networking products. For information that pertains to all of Cisco, refer to the Obtaining Documentation and Submitting a Service Request section.

Where to Find Safety and Warning Information

For safety and warning information, refer to the Cisco Optical Transport Products Safety and Compliance Information document that accompanied the product. This publication describes the international agency compliance and safety information for the Cisco ONS 15454 system. It also includes translations of the safety warnings that appear in the ONS 15454 system documentation.

Cisco Optical Networking Product Documentation CD-ROM

Optical networking-related documentation, including Cisco ONS 15xxx product documentation, is available in a CD-ROM package that ships with your product. The Optical Networking Product Documentation CD-ROM is updated periodically and may be more current than printed documentation.

Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at: http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html

Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS version 2.0.

Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2010 Cisco Systems, Inc. All rights reserved.

¹ The default changes for alarm reporting may highlight formerly suppressed conditions for your installation. For previous software releases, if you have not changed these parameters, you may recognize alarms after the upgrade, which you suppressed before. Refer to the document explaining alarms in the AXXCRAFT/TMN Help menu for descriptions and troubleshooting hints.

² In previous releases, DoNotUse has been the default configuration for the S1 byte (active when SSM is enabled). Feedback from customers has triggered a change for this, and from this release onwards, T0 will be the default value. If your network synchronization scheme requires DoNotUse for any SDH ports, make sure to set the parameter in configuration file prior to upgrade to this release.