|
|
Table Of Contents
Release Notes for Cisco ONS 15305 Release 2.0.2
Resolved Caveats for Release 2.0.2
New Features and Functionality
Cisco Product Security Overview
Reporting Security Problems in Cisco Products
Obtaining Technical Assistance
Cisco Technical Support Website
Definitions of Service Request Severity
Obtaining Additional Publications and Information
Release Notes for Cisco ONS 15305 Release 2.0.2
June 2005
Release notes address closed (maintenance) issues, caveats, and new features for the Cisco ONS 15305. For detailed information regarding features, capabilities, hardware, and software introduced with this release, refer to Release 2.0 of the Cisco ONS 15305 Installation and Operations Guide. For the most current version of the Release Notes for Cisco ONS 15305 Release 2.0.2, visit the following URL:
http://www.cisco.com/en/US/products/hw/optical/ps2001/prod_release_notes_list.html
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 2.0.2
New Features and Functionality
Cisco Product Security Overview
Obtaining Technical Assistance
Obtaining Additional Publications and Information
Changes to the Release Notes
This section documents supplemental changes that have been added to the Release Notes for Cisco ONS 15305 Release 2.0.2 since the production of the Cisco ONS 15305 System Software CD for Release 2.0.2.
No changes have been added to the release notes for Release 2.0.2.
Caveats
Review the notes listed below before deploying the ONS 15305. 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.
DDTS # CSCei15120
Incoming IGMP packets are VLAN-tagged, and hold the VID of a VLAN that is configured on the device. The ingress port is not a member of a named VLAN. In some rare configurations this could create a loop in the topology, and a storm of replicated IGMP packets. The IGMP packets reach the VLAN even though the ingress port is not member of the VLAN. Thus VLAN-tagged IGMP packets bypass ingress filtering.
Workaround
There is usually no need for a configuration that allows this to happen.
Verify that the VLAN configuration in the topology is consistent and does not contain any partially configured links. This issue is under investigation.
DDTS # CSCei15125
Changing the system mode from IP (default) to IP unnumbered can result in problems.
Release 2.0 software is limited with respect to changing the system mode from IP (default) to IP unnumbered.
Even though there are IP addresses and routing protocols configured on an NE the operator does not receive any notification. Notification could enable the operator to forestall the change until necessary configuration changes have been made.
From a software design point of view, the configuration of system mode for DCN routing is seen as a strategic choice, which the operator should configure prior to configuring the IP address and protocols on the device. The reason for this is that the network design is different for each of the system modes.
The consequence for changing the system mode from IP to IP unnumbered is complicated and severe problems can result if handled incorrectly. In the worst case, you might not be able to regain IP connectivity to the NE.
Workaround
Generally, the safest alternative is to erase the configuration prior to changing the system mode. If you do not wish to lose your configuration, however, the following steps have proved successful.
Step 1
Locally connect to a MNGT-port and connect with CiscoEdgeCraft.
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Note
Resolution
N/A
DDTS # CSCeg61386
FE port blocked when a port configuration is changed. The port does not forward traffic, but port status is reported as up.
This issue can occur when the FE port has been configured for L1 and a bandwidth larger than 0 has been allocated. If the port is reconfigured to L2, the port will not forward traffic when there is an alarm on the vcgroup connected to the port, in L1 mode, prior to the reconfiguration to L2.
Workaround:
Ensure that on a port running in L1 mode, with an administrative capacity larger than 0, your operational capacity downstream is larger than 0, then reduce the administrative bandwidth of the port to 0 before switching over to L2 configuration.
If a reconfiguration of the port has occurred without following the above procedure, the module must be restarted. A reconfiguration back to L1 operation will not be sufficient unless an operational capacity greater than zero is restored and the procedure described above is repeated. This issue will be resolved in the next release.
DDTS # CSCea33337
Port priority is not strictly enforced when flow control is on. This can occur under the following conditions.
The four input ports are set for 100 MB (64 bytes).
Port 1 priority is set for 6
Port 2 priority is set for 4
Port 3 priority is set for 0
"Port 4 priority is set for 1
VLAN tagging is turned off for all of the FE ports while VLAN tagging is turned on for the STM1 trunk port. (This adds an additional 4 bytes to each stream.) Flow control is turned on for all the FE ports When all the ports are turned on, only Port 1 should have priority. Instead, traffic is received on both Ports 1 and 2 at almost 60/40% on each port (81,168 versus 60,876). This issue will be resolved in a future release.
DDTS # CSCeb22543
The failure is present in different corners and at different temperatures. We have Errors (#14 B3 errors in 24 hour of test, #1 Loss of Pattern) on a STM-1 link with #3 8xSTM-1 modules. We records also packet lost on a FE link mapped into STM-1 optical path. When these errors / packet lost happens, we record from Cisco Craft a lot of "DXC inlet bit error" alarms. No other type of alarms has been recorded from the Cisco-Craft. All these 3 event happens at the same time, so the root cause should be the same.
DDTS # CSCea71600
The fail is related on module 8xSTM-1. During EDVT corner 5 & corner 7:
Corner 5: power supplies on the modules at -5% except power supply DC-DC module at +5%, Temperature= +50°C
Corner 7: each power supplies at -5%, Temperature= +50°C this module does not starts. This cause fail on the traffic path related to this modules.
The number of fails is:
•
•
•
When this fail happens, record the following alarm from the Cisco EdgeCraft:
"slot3 inlet Fail DXC inlet failure".
64 byte packets are lost when testing flow control
DDTS # CSCea31245
Conditions:
When sending 100 Mb from two ports to a single port, the packets are lost when the size is 64 byte. When the size is increased to 75 byte, the packet loss goes away
Workaround:
This type of traffic is not typical for a device in normal operation but it can occur in a lab test setup
Resolution:
None
DDTS # CSCea33354
No pause packets received on ports sending traffic to a congested mirrored port.
Conditions:
If a mirrored port becomes congested and flow control is enabled, no pause packets are generated toward ports belonging to other modules. Flow control is not working properly if ports used for mirroring become congested. If traffic to a mirrored port is sent from a LAN port situated in a different module than the mirrored port pause packets are not received and mirrored packets are lost. The real traffic flow is not disturbed by the mirrored port flow control problem, and the copy port traffic handling is working fine.
Workaround:
None
DDTS # CSCeg58254
When operating in L2 mode, Ethernet frames with MAC destination address in the range 01:80:C2:00:00:10 to 01:80:C2:00:00:FF are not correctly filtered due to limitations in the switch ASIC. Special steps are taken to forward 0 1:80:C2:00:00:14 and:15 (IS hello).
01:80:C2:00:00:14 and:15 are not forwarded if one is employing Provider VLAN by using Ethertype 0xFFFF (legacy provider VLAN).
Conditions:
Legacy VLAN tunneling in use.
Workaround:
Use protocol tunneling supported by 2xGE + SMAP and 8xFE + SMAP to provide transparent Ethernet (with or without provider VLAN).
DDTS # CSCea33042
Same priority and same packet size yields different traffic flows.
Conditions:
There are 4 streams setup each has the same packet size (64 byte) going across 100 Mb STM-1 path to another ONS15305. Each of the streams can be off as much as 50%. This is not always the case, sometimes the traffic can be equally distributed. However, using random packet sizes, the distribution seems to be more equal.
Workaround:
This type of traffic in not typical for a device in normal operation, but it can occur in a lab test setup.
Resolution:
None
DDTS # CSCea33196
Unfair distribution of intermodular traffic with flow control can occur. If traffic is sent from several ports in different modules and flow control is active, traffic throughput is less for ports belonging to same module as the congested.
Typical scenario:
Port 2 module 1, port 1 module 2 and port 1 module 3 send 100Mb traffic streams to port 1 module 1. All ports have flow control enabled. The result is that more traffic is sent from the ports in module 2 and 3 compared to what is sent from the port in module 1. No packet loss from any module occurs. This issue will be resolved in a future release.
DDTS # CSCeg58260
System-up-time should be able to store up-time up to approximately 497 days. Experience shows this counters wraps around well before (appr. 40 days).
Workaround:
None
Resolution:
Ongoing investigation.
DDTS # CSCeg58273
AbortTftp events reported on unsuccessful ping.
Conditions:
When using \223ping utility\224 from AXXCRAFT, and the ping is not successful, abortTftp events are reported. Tftp events are not relevant in this context.
Workaround:
None.
DDTS # CSCeg58278
802.1p does not work satisfactorily for WAN ports on 4xFE+4xMAP, 8xSTM-1+8xMAP and 8xMAP modules.
Symptom:
In some cases the different priority tags of frames going out on WAN ports are ignored.
Conditions:
The number of VC-12s allocated to a WAN port is less than 47 (i.e. the capacity of the WAN link is less than 100M it/s). The switch sees the wan port as an FE port, and will not see the need for prioritizing between the frames. Thus adapting the traffic to the actual bandwidth is handed over to the FPGA mapping the frames into SDH.
Workaround:
Solved for 2xGE + SMAP and 8xFE + SMAP modules.
Resolution:
Ongoing investigation.
DDTS # CSCeg58295
Disabling OSPF causes device-restart if Stub area exists (IP-Numbered mode only).
Symptom:
Device restarts when disabling OSPF if stub area exists.
Workaround:
None
Resolution:
Ongoing investigation.
DDTS # CSCeg58300
Static Unicast Table (number of entries) causes device-restart.
Symptom:
Administratively set a value for Unicast-Global-Forwarding Table causes device restart.
Conditions:
If configuring a value for Unicast-Global-Forwarding table \223AfterReset\224 lower than the number of static entries in the table, and then select software reset for the device, a device restart will be experienced.
Workaround:
Avoid configuring a lower number than statically configured in the Unicast-Global-Forwarding table.
Resolution:
Ongoing investigation.
DDTS # CSCeg58312
Max aging time is 650 sec.
Symptom:
When the setting for aging time is set above 650 seconds, aging still starts at 650 seconds.
Conditions:
1.
2.
Workaround:
None.
DDTS # CSCeg58361
Unnecessary LINK_DOWN events reported in history after boot/restart.
Symptom:
DCC Link "down" events reported in "notification history" after boot.
Conditions:
All DCC channels, even if not represented by DCC applicable HW, reports LINK "DOWN" in notification history after device power up (restart).
Workaround:
None
Resolution:
Ongoing investigation.
DDTS # CSCeg58364
Auto negotiation for Flow control on LANx-ports does not work (2xGE_SMAP only).
Symptom:
The PAUSE-capable bit is not announced during auto negotiation when Flow Control is set to AutoNeg.
Only for 2xGE_SMAP.
Workaround:
None.
Resolution:
Ongoing investigation.
DDTS # CSCeg58372
There is an RSTP and GVRP conflict.
Symptom:
If both RSTP and GVRP run simultaneously, a device-restart may be experienced when disabling GVRP.
Workaround:
RSTP must be disabled before disabling GVRP.
Resolution:
Ongoing investigation.
DDTS # CSCeg58380
SNC Protected unidirectional cross-connection not supported. When one direction of a path forms part of an SNC protected unidirectional cross-connection, the other direction can not form part of a different SNC protected unidirectional cross-connection. But the two directions can form part of two different unidirectional un-protected cross-connections. This applies to unidirectional cross-connections on all path layers.
For example, suppose the unidirectional VC-12 cross-connection from 1/1/1.1.1.1.1 (input) to 1/2/1.1.1.1.1 (output) is SNC protected by 1/3/1.1.1.1.1 (input). In this case, the output direction of 1/1/1.1.1.1.1 and /3/1.1.1.1.1, and the input direction of 1/2/1.1.1.1.1 are un-used. However, due to the above mentioned limitation, they can not be part of a new SNC protected unidirectional cross-connection, e.g. from 1/2/1.1.1.1.1 (input) to 1/1/1.1.1.1.1 (output) protected by 1/14/1.1.1.1.1. They may however form part of un-protected unidirectional cross-connections.
Workaround:
None.
Resolution:
Release R3.0
DDTS # CSCeg58388
Device reboots if switching OSPF InterfaceType from "point-to-point" to "broadcast," or if disabling OSPF while InterfaceType is "point-to-point". This issue is observed when OSPF is enabled, the OSPF Interface table is populated and the InterfaceType of an entry in the OSPF Interface table is changed to "point-to-point."
Workaround
Restore a CDB-backup without the incorrect interface type configured. If you don't have such a CDB-backup, SUPPORT can assist in modifying the CDB-backup of your current configuration.
DDTS # CSCeg58398
Device initiates an additional boot sequence when restarted after CDB-restoration, to clean up invalid configuration data, after which the ProviderTags parameter is set to "disabled."
VLAN membership or tag status of an Ethernet port has been changed after the parameter ProviderTags has been enabled, and the device has been rebooted (due to software/firmware upgrade, or restore of configuration database).
Workaround:
Disable ProviderTags parameter when removing the port from the VLAN or changing its tag status.
DDTS # CSCef88892
When first configuring IP numbered DCN management link between ONS15305 and ONS15454SDH, the link may not come up.
Workaround:
For the DCN link to come up, one must toggle the mode field, on ONS15305, from "IpOverDcc" to "Not Used" then back to "IpOverDcc".
DDTS # CSCeg11010
Some dccR and dccM Mode field may reset to "Not Used" after upgrade to R2.0 in IP numbered mode.
Workaround:
Mode fields for all pre-provisioned dccR and dccM must be revisited and reconfigured for "Poverty".
DDTS # CSCeg11478
Reverting from R2.0 back to R1.1.1 will fail.
Workaround:
The following procedure must be used to successfully revert back to Release 1.1.1, after upgrading to release 2.0:
1.
2.
3.
DDTS # CSCeg45943
The Mac table overflow "Duration Timer" does not increment.
After overloading the forwarding database a "bridge table overflow" occurs, but the duration of the condition stays at 0h 0m 0s.
Resolved Caveats for Release 2.0.2
The following caveats are resolved as of Release 2.0.2.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
The following caveats are resolved as of Release 2.0.
•
•
•
•
•
New Features and Functionality
This section highlights new features and functionality for Release 2.0. For an overview of features of the 15305, consult the Cisco ONS 15305 Installation and Operations Guide, Release 2.0.
The following new module types have been added for Release 2.0.
•
•
The following additional features have been added for Release 2.0.
•
•
•
•
•
•
•
•
•
•
–
–
•
•
•
•
•
–
The following miscellaneous features have been added for Release 2.0.
•
•
•
•
•
•
•
•
•
•
•
•
•
General improvements/enhancements
•
•
•
•
•
Related Documentation
Release-Specific Documents
•
•
•
Platform-Specific Documents
•
•
Obtaining Documentation
Cisco documentation and additional literature are available on Cisco.com. Cisco also provides several ways to obtain technical assistance and other technical resources. These sections explain how to obtain technical information from Cisco Systems.
Cisco.com
You can access the most current Cisco documentation at this URL:
http://www.cisco.com/univercd/home/home.htm
You can access the Cisco website at this URL:
You can access international Cisco websites at this URL:
http://www.cisco.com/public/countries_languages.shtml
Documentation DVD
Cisco documentation and additional literature are available in a Documentation DVD package, which may have shipped with your product. The Documentation DVD is updated regularly and may be more current than printed documentation. The Documentation DVD package is available as a single unit.
Registered Cisco.com users (Cisco direct customers) can order a Cisco Documentation DVD (product number DOC-DOCDVD=) from the Ordering tool or Cisco Marketplace.
Cisco Ordering tool:
http://www.cisco.com/en/US/partner/ordering/
Cisco Marketplace:
http://www.cisco.com/go/marketplace/
Ordering Documentation
You can find instructions for ordering documentation at this URL:
http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm
You can order Cisco documentation in these ways:
•
http://www.cisco.com/en/US/partner/ordering/
•
Documentation Feedback
You can send comments about technical documentation to bug-doc@cisco.com.
You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address:
Cisco Systems
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883We appreciate your comments.
Cisco Product Security Overview
Cisco provides a free online Security Vulnerability Policy portal at this URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
From this site, you can perform these tasks:
•
•
•
A current list of security advisories and notices for Cisco products is available at this URL:
If you prefer to see advisories and notices as they are updated in real time, you can access a Product Security Incident Response Team Really Simple Syndication (PSIRT RSS) feed from this URL:
http://www.cisco.com/en/US/products/products_psirt_rss_feed.html
Reporting Security Problems in Cisco Products
Cisco is committed to delivering secure products. We test our products internally before we release them, and we strive to correct all vulnerabilities quickly. If you think that you might have identified a vulnerability in a Cisco product, contact PSIRT:
•
•
Tip
Never use a revoked or an expired encryption key. The correct public key to use in your correspondence with PSIRT is the one that has the most recent creation date in this public key server list:
http://pgp.mit.edu:11371/pks/lookup?search=psirt%40cisco.com&op=index&exact=on
In an emergency, you can also reach PSIRT by telephone:
•
•
Obtaining Technical Assistance
For all customers, partners, resellers, and distributors who hold valid Cisco service contracts, Cisco Technical Support provides 24-hour-a-day, award-winning technical assistance. The Cisco Technical Support Website on Cisco.com features extensive online support resources. In addition, Cisco Technical Assistance Center (TAC) engineers provide telephone support. If you do not hold a valid Cisco service contract, contact your reseller.
Cisco Technical Support Website
The Cisco Technical Support Website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The website is available 24 hours a day, 365 days a year, at this URL:
http://www.cisco.com/techsupport
Access to all tools on the Cisco Technical Support Website requires a Cisco.com user ID and password. If you have a valid service contract but do not have a user ID or password, you can register at this URL:
http://tools.cisco.com/RPF/register/register.do
Note
Submitting a Service Request
Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests. (S3 and S4 service requests are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Service Request Tool provides recommended solutions. If your issue is not resolved using the recommended resources, your service request is assigned to a Cisco TAC engineer. The TAC Service Request Tool is located at this URL:
http://www.cisco.com/techsupport/servicerequest
For S1 or S2 service requests or if you do not have Internet access, contact the Cisco TAC by telephone. (S1 or S2 service requests are those in which your production network is down or severely degraded.) Cisco TAC engineers are assigned immediately to S1 and S2 service requests to help keep your business operations running smoothly.
To open a service request by telephone, use one of the following numbers:
Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227)
EMEA: +32 2 704 55 55
USA: 1 800 553-2447For a complete list of Cisco TAC contacts, go to this URL:
http://www.cisco.com/techsupport/contacts
Definitions of Service Request Severity
To ensure that all service requests are reported in a standard format, Cisco has established severity definitions.
Severity 1 (S1)—Your network is "down," or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation.
Severity 2 (S2)—Operation of an existing network is severely degraded, or significant aspects of your business operation are negatively affected by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation.
Severity 3 (S3)—Operational performance of your network is impaired, but most business operations remain functional. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels.
Severity 4 (S4)—You require information or assistance with Cisco product capabilities, installation, or configuration. There is little or no effect on your business operations.
Obtaining Additional Publications and Information
Information about Cisco products, technologies, and network solutions is available from various online and printed sources.
•
http://www.cisco.com/go/marketplace/
•
•
•
http://www.cisco.com/go/iqmagazine
•
•
http://www.cisco.com/en/US/learning/index.html
This document is to be used in conjunction with the documents listed in the Related Documentation section.
Copyright © 2005 Cisco Systems, Inc. All rights reserved.
Posted: Thu Sep 13 13:18:03 PDT 2007
All contents are Copyright © 1992--2007 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
