Release Notes for Cisco ONS 15454 SDH Release 4.6.6

Note The terms "Unidirectional Path Switched Ring" and "UPSR" may appear in Cisco literature. These terms do not refer to using Cisco ONS 15xxx products in a unidirectional path switched ring configuration. Rather, these terms, as well as "Path Protected Mesh Network" and "PPMN," refer generally to Cisco's path protection feature, which may be used in any topological network configuration. Cisco does not recommend using its path protection feature in any particular topological network configuration.

August, 2007

Release notes address closed (maintenance) issues, caveats, and new features for the Cisco ONS 15454 SDH multiplexer. For detailed information regarding features, capabilities, hardware, and software introduced with this release, refer to the "Release 4.6" version of the of the Cisco ONS 15454 SDH Installation and Operations Guide, and Cisco ONS 15454 SDH Troubleshooting and Reference Guide. For the most current version of the Release Notes for Cisco ONS 15454 SDH Release 4.6.6, visit the following URL:

Changes to the Release Notes

This section documents supplemental changes that have been added to the Release Notes for Cisco ONS 15454 SDH Release 4.6.6 since the production of the Cisco ONS 15454 SDH System Software CD for Release 4.6.6.

The following changes have been added to the release notes for Release 4.6.6

Changes to Caveats

Caveats

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

Hardware

STM1E-12 Card Support

The STM1E-12 card is not supported in this release. This card will be supported in a future release. Caveats herein pertaining to this card also do not apply.

CSCdw92634

SDH DS3-i and E3 electrical cards only support a VC4 J1 trace string setting for all VC4s together. You cannot set the J1 byte for individual VC4s. This issue is a limitation of hardware.

Note VC3 J1 strings can be set individually, but the optical cards cannot monitor the VC3 J1 string.

CSCdw14501

Interconnection Equipment failure alarms may be generated at 55 degrees C, and 72 volts. When the operating environment is at 55 degrees C and 72 volts, interconnection equipment failure alarms for the following cards can occur:

•STM16SH

•STM64LH

•STM16LH

•XC10G

The alarms could potentially occur on any of these boards, as well: OC48AS, GigE, OC192 or OC192LR. This issue will be resolved in a future release.

CSCdw50903

E1-14 boards with second source components can incur bit errors under extreme environmental conditions. When these boards operate under voltage and temperature stress conditions and a temperature ramp rate of 1 degree per minute, the boards could exhibit dribbling bit errors at high temperatures: BER = 5.5e-6. To avoid this, you must apply the temperature ramp rate at 0.5 degree per minute. This ramp rate complies with the NEBS standard; however, this issue will be revisited in a future release.

Upgrades

CSCee36132, CSCee66259

Activating to Release 4.6.2, 4.6.3, or 4.6.6 might result in a stuck Protection Not Available (PROTNA) alarm on the cross connect card after activation completes. One of the cross connect cards would be in active state and the other in standby state. Reset the Active TCC (Shelf Controller Card) to recover from this issue. This issue is resolved in Release 5.0.

Caution Before you upgrade to Release 4.6.6 from Release 4.0, 4.0.1, or 4.1, you must read this caveat and run the SDH Circuit Repair Utility (VcCheck) provided on the software CD (also available on CCO).

The XCVXL card on the ONS 15454 SDH allows the intermixing of VC12 and VC3 payloads within a single VC4. When a VC4 contains only one VC12 tributary and at least one VC3 tributary and the VC12 is deleted, the database becomes corrupt.

The database load process on the ONS 15454 SDH occurs during a TCC2 reboot, TCC2 protection switch, software activation, or database restore. When the database is loaded containing this corruption the load process fails, causing the corrupt database to be deleted from the TCC2 flash memory. The previous saved database is then loaded instead. When all saved databases on a TCC2 contain the corruption, the TCC2 will load with the default provisioning, and all existing provisioning will be lost.

If this issue occurs you will see a loss of either some or all provisioning after a TCC2 switch or reset.

To ensure that your network is not vulnerable to this issue, you must first determine if the issue already exists within your network, and if so, correct it. You can detect the issue by using the SDH Circuit Repair Utility (VcCheck) provided on the ONS 15454 SDH Release 4.1.3 and 4.6.x software CDs. The VcCheck tool is also available for download from CCO. Once you have alleviated immediate risk from the issue, you must upgrade to Release 4.6.x, or maintenance Release 4.1.3 (or any later release) to avoid further risk.

The VcCheck utility and its associated README file (in the same directory with the tool) provide details on how to temporarily alleviate this issue before upgrading to a release in which the issue is resolved.

This issue is resolved in Release 4.6 and maintenance Release 4.1.3 (caveated herein because of the upgrade issue).

Line Cards

CSCed89610

The E1-42 LOSS-L threshold in CTC is not displayed or provisionable. The three other line-related thresholds are displayed properly. This issue is resolved in Release 5.0.

CSCef59835

In E1-42 card view, if you select Provisioning > SDH Thresholds, the VC4 button is greyed out. Hence, the E1-42 VC4 threshold is not provisionable. This issue is resolved in Release 5.0.

CSCef61339

A monitor circuit in the IS-AINS state might fail to switch to IS in an STM-16 and STM-64 SNCP-DRI ring with E1-42 circuits. This issue is resolved in Release 5.0.

CSCef72687

When a one way circuit is created on an SDH electrical card, and the direction of the circuit is toward the backplane from the port, where the LP and HP PMs are measured from the backplane in the direction of the port, though there is no circuit present in that direction, the VC3 and VC12 PMs might count anyway. This issue is resolved in Release 6.0 and maintenance Release 5.0.1.

CSCef67059

Bit errors can occur on E1-42 line cards passing traffic, when other E1-42 line cards are initially inserted into adjacent slots. Specifically, inserting line cards into adjacent slots or 1:N protect slots (Slots 3 and 15) can cause hits on Ports 1-14. Also, when the card in the 1:N protection slot is passing traffic, inserting E1-42 line cards into adjacent slots can cause bit errors. The bit errors characteristically last less than 5 ms. After the card is inserted, no further bit errors occur. Ports 15-42 behave differently. No bit errors occur on a line card residing in a non-1:N slot if adjacent line cards are inserted. Bit errors will only occur for these ports if line cards are inserted into the 1:N protection slots (Slots 3 and 15). Bit errors might also occur if traffic passes through the 1:N protected slot, and you insert a line card into any other working slot. A future version of E1-42 hardware will resolve this issue.

Circuit State Transition from OOS-AINS

For the following cards, a circuit might inappropriately transition from the OOS-AINS state to the IS, or OOS-AINS-PARTIAL state.

•DS3I (SONET and SDH)

•DS1 (STS circuits only)

•DS3XM

•E1-42

•E1-14

•E3

This can occur when the circuit and the port for the circuit are both in the OOS-AINS state. Upon a soft reset of the card or a software upgrade, the circuit might transition into the IS or the OOS-AINS PARTIAL state, resulting in false path level alarms. For the DS1 card, this issue occurs only on STS circuits. This issue is non-service affecting and will be resolved in a future release.

CSCee17695 and CSCed26246

Rarely, an STM1-8 card might fail to read MFG EEPROM and will show MEA in CTC. This issue can be reproduced by power cycling the node several times; however, the issue is not likely to be due to the power cycling. If a card enters this state, remove and reseat it. This issue is resolved in Release 5.0.

CSCed15073

Rarely, a WKSWPR condition resulting from loss and recovery of power to the node can become stuck when there are multiple 1+1 protection groups provisioned on a single OC3-8 card. This issue is resolved in Release 5.0.

CSCec82148

Rarely, traffic hits can occur on TCC2 card removal. To avoid this issue, remove the card quickly. To recover from this issue, soft reset the TCC2 card. This issue will cannot be resolved; however, this issue does not occur when the newer optical line cards, TCC2P cards, and XC-VXC cards are used.

Interoperability with SONET DS3i-N-12

When provisioning circuits in SDH to interoperate with SONET DS3i-N-12, you must create a VC4 containing VC3s as a payload in the exact order in which they will attach to port groups on the SONET side.

CSCea52722

With DS3-I cards in a 1:2 protection group, when the protect card is active and in the WTR condition, removing another working card from the protection group clears the WTR condition. To work around this issue, remove the working card from the protection group when the protect card is in the standby state. This issue will be resolved in a future release.

Ethernet Polarity Detection

The TCC2 does not support Ethernet polarity detection. The TCC+ and TCCI both support this feature. If your Ethernet connection has the incorrect polarity (this can only occur with cables that have the receive wire pairs flipped), the TCC+/I will work, but the TCC2 will not. In this event, a standing condition, "LAN Connection Polarity Reverse Detected" (COND-LAN-POL-REV), will be raised (a notification will appear on the LCD, and there will be an alarm raised). This issue will most likely be seen during an upgrade or initial node deployment. To correct the situation, ensure that your Ethernet cable has the correct mapping of the wire wrap pins. For Ethernet pin mappings, consult the "DLP-A 21 Install LAN Wires on the Backplane" procedure in the user documentation.

Active Cross Connect or TCC2 Card Removal

Active cross connect or TCC2 cards should not be removed. If the active cross connect or TCC2 card must be removed, to minimize network interruption you can first perform an XC10G (or XCVXL) side switch and then remove the card once it is in standby, or you can perform a lockout on all circuits that originate from the node whose active cross connect or active TCC2 will be removed (performing a lockout on all spans will also accomplish the same goal).

Caution If you mistakenly remove an active cross connect or TCC2 card and you subsequently lose traffic on some interface cards, you may need to physically reset these cards if they fail to regain traffic.

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.

CSCdw44431

Cisco ONS 15454 optical cards are not provisioned for particular path labels (C2 bytes). Consequently, they cannot raise a PLM condition. However, the ONS 15454 electrical card that terminates traffic ensures that the C2 byte is correct for the type of traffic carried. If the C2 byte is incorrect, this card raises a PLM condition that is reported against the optical port of ingress. An optical card will not raise a PLM against traffic that passes through a node, though it will appear to raise a PLM against traffic with the wrong C2 byte that is terminated on an electrical card within the node. It is not known at this time when or if this issue will be resolved.

Note Optical cards do ensure that the C2 byte is nonzero (Equipped), and will raise a UNEQ condition if the C2 byte is 0 (Unequipped).

CSCdw80652

When one traffic card in a DS3i 1:N protection group is reset, and then another card is reset, there will be a loss of traffic on the second card, after the first card completes its reset, lasting until the second card completes its reset. This only occurs when the protect card tries to handle the traffic of a card that is resetting, and that card is carrying traffic because when it reset the protect card was carrying traffic for another card. This loss of traffic occurs because the protect card attempts to set its relays to handle the traffic of the working card, but the relays on the working card are also set to carry the traffic, and since the card is resetting, no software is running to switch its relays. This issue most frequently presents itself when testing a double-failure scenario: resetting two cards in a protection group. Wait until the first card completes its reset sequence before resetting the second card to prevent this problem. Configuring cards in 1:1 instead of 1:N protection should also avoid the problem. This issue will not be resolved.

CSCdw57215

In a configuration with STM16 Any Slot cards and an VC4-8c circuit, provisioned between G1000-4 cards with traffic going over the STM16 span, extracting the G1000-4 card at one end of the VC4-8c circuit before deleting the circuit can result in a traffic hit on all existing SDH circuits defined over that same span. There are no issues if the circuit is deleted prior to the removing the G1000-4 card.

XC10G Boot Process

If you install a new XC10G card to the node and it fails to boot, remove the card and reinsert it. If the card still fails to boot, return it using the RMA procedure. This issue will be resolved in future hardware.

Jitter Performance with XC10G

During testing with the XC10G, jitter generation above 0.10 UI p-p related to temperature gradient testing has been observed. This effect is not expected to be seen under standard operating conditions. Changes are being investigated to improve jitter performance in a subsequent version of the XC10G cross connect card. DDTS numbers related to this issue include CSCdv50357, CSCdv63567, CSCdv68418, CSCdv68441, CSCdv68389, CSCdv59621, and CSCdv73402.

DWDM Cards

CSCed18225

When the trunk ports for two back-to-back connected MXPs or TXPs have different ALS modes enabled (such as if one of them is ALS-Manual, and other is ALS-Auto), or have the same ALS mode for both sides (with ALS-Manual or ALS-Auto enabled), MXP or TXP might enter a state in which there are oscillating LOS-P, ALS, and Client Squelch alarms. If this occurs, either choose ALS-Disable on MXP/TXP, or remove the trunk transmit fiber on either end for 15-20 seconds and then reinsert it. This issue is resolved in Release 5.0.

CSCed21403

Occasionally, in a node with MXP-2.5G-10G cards, when you hard reset the active TCC2, the MXP-2.5G-10G traffic can take a hit of 1-4 ms. It has not been determined when or if this issue will be resolved.

CSCed01940

The TXPP card does not squelch the near end client on putting trunk ports OOS. This can occur where two TXPP cards are connected via trunks. Each TXPP card is in transparent mode with GCC enabled. Testsets are connected to each client port. On the near end, place both trunk ports OOS. The far end client squelches because of LOS-P. The near end client, however, does not squelch. The near client should also squelch. To work around this, place the client port OOS, or place the far-end trunk port OOS. This issue is resolved in Release 5.0.

CSCeb25490

Occasionally CTC displays a LO-TXPOWER alarm when SMT4 and STM1 SFP is installed at the client port of a TXP or TXPP card. The LO-TXPOWER alarm is displayed when the alarm threshold is set to the default value in the TX POWER LOW field of the Optical Threshold in the CTC provisioning window. To work around this issue, lower the alarm threshold value (TX POWER LOW (dBm)) of Optical Threshold in the CTC provisioning window. Refer to Table XX for threshold values. This issue will be resolved in Release 5.0.

Table 4 contains the High and Low Alarm Thresholds of Tx-power and Rx-power of SFPs in TXP and TXPP cards. The values of these thresholds are read from the EEPROM inside the SFPs. This table can be used as a reference in PM alarm provisioning and Threshold Alarm verification.

2N/A means Not Available. The vendor did not provide the information in this field.

CSCuk42668

TXP-MR-2.5G F1-UDC may not be passed through in a line-terminated configuration with OTN off. This can occur with clean, OC-3/STM-1, line-terminated traffic, with OTN disabled, when you create a D1-D3 tunnel, a D4-D12 tunnel, and an F1-UDC from client to client. This issue will not be resolved.

CSCuk42752

If you go to the Overhead Circuits Tab in network view and select any User Data, F1 or User Data D4-D12 circuit type, no nXP cards are available for selection in the Endpoints. However, user Data type circuits can still be made end-to-end (where "end-to-end" refers to external cards, such as AIC to AIC) if the nXP cards are put in Transparent mode. This issue will not be resolved.

CSCeb49422

With TXPP cards, a traffic loss up to six seconds can occur during a DWDM protection switch. This behavior may be exhibited during protection switches by certain third-party fiber channel switches due to loss of buffer credits resulting in a reconvergence of the fiber channel link. This issue will not be resolved.

CSCeb53044

The 2G Fiber Channel (FC) payload data type in the TXP_MR_2.5G and TXPP_MR_2.5G cards does not support any 8B/10B Payload PM monitoring.

CSCeb32065

Once engaged, the ALR will not restart on the trunk lines of a TXP or TXPP card. This occurs whenever ALR engages on the trunk lines of a TXP or TXPP card and the recover pulse width is provisioned to less than 40 seconds. This is a function of the trunk laser turn-on time, and the limiting recovery pulse width will vary by card. To avoid this issue, provision the pulse width to 40 seconds or more.

CSCeb26662 and CSCea88023

With TXP-MR-2.5G cards, when the current 1 day Optics PM rolls over, the information is inaccurate. This issue will not be resolved.

CSCuk42588

With ALS mode configured as "Auto Restart" or "Manual Restart," it is possible the ALS Pulse Duration Recovery time can be set to values out of ITU-T recommendation G.664. You can use values out of the range defined in ITU-T recommendation G.664 only in order to interoperate with equipment that lasers cannot turn on or off within the required pulse time. To stay within the specification, you can set this value to 2 seconds and up to 2.25 seconds.

CSCea81219

On the TXPP, the default value for Tx Power High for TCAs & Alarms is too high for the trunk ports. Since Tx Power TCA and Alarm are not supported for trunk ports, this caveat is for informational purposes only.

CSCeb24815

With TXP-MR-2.5G cards, ratios are calculated incorrectly after clearing statistics. This is because after you clear statistics the entire time period becomes invalid. Once the time period rolls over again, values will be reliable for the new period.

CSCeb27187

During a Y-Cable protection switch, the client interface sends 200,000 to 300,000 8B/10B errors towards the attached Catalyst 3550 switch. The switch reacts to this large amount of 8B/10B errors by reinitializing the interface and spanning tree. The end result is that a protection switch can lead to a 30-45 second traffic hit if the switch is running spanning tree (default mode). This is expected behavior.

CSCea87290

In a Y-Cable protection group, if GCCs are defined on both cards, both cards' active LEDs will be green.

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.

CSCea68773

The ACTV/STBY LED shows AMBER when a 2.5G transponder is first connected. The DWDM cards introduced a new design: When all the ports are OOS on a card, the card is considered to be in standby mode.

Data I/O Cards

CSCsc01211

Rarely, a unidirectional traffic outage can occur on a SW-LCAS VCAT circuit on ML-1000 or ML-100-T cards after an XC10G card reset. If this occurs you must reset the ML-series card to recover. This issue is resolved in Release 5.0.

E Series and G Series Cards

CSCsc02312

G-series adapter RMON threshold counts displayed in the CTC RMON threshold Provisioning list do not match the displayed performance monitoring counts. Most RMON threshold names displayed do not match with the performance pane statistic names. Cross reference RMON threshold names with PM statistic names to get the full set. Also note that PM statistic names for G-series are a subset of the available RMON threshold counts. This issue is resolved in Release 5.0.

E1000-2/E100T

Do not use the repair circuit option with provisioned stitched Ethernet circuits. It is not known at this time when or if this issue will be resolved.

Single-card EtherSwitch

Each E100/E1000 card can be configured as a single-card EtherSwitch configuration to allow VC4-4c of bandwidth to be dropped at each card. The following scenarios for provisioning are available:

VC4-4c

VC4-2c, VC4-2c

VC4-2c, VC4, VC4

VC4, VC4, VC4, VC4

When configuring scenario 3, the VC4-2c must be provisioned before either of the VC4 circuits.

Multicard EtherSwitch

When deleting and recreating Ethernet circuits that have different sizes, you must delete all VC4 circuits provisioned to the EtherSwitch before you create the new circuit scenario. (See the preceding "Single-card EtherSwitch" section on page 6 for details on the proper order of circuit creation.) Enable front ports so that the VLANs for the ports are carried by the largest circuit first. A safe approach is to enable the front port before you create any circuits and then retain the front port VLAN assignment afterwards. If you break the rules when creating a circuit, or if you have to delete circuits and recreate them again, delete all circuits and start over with the largest first.

ML Series Cards

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.

CSCec52443

On an ML-series RPR ring circuit deletion or creation causes an approximately 200 ms traffic loss. Traffic loss is expected to be less than 50 ms for RPR. To avoid this issue, from the ML-series CLI, perform a "shutdown" on both ends of the circuit prior to circuit changes. This issue will not be resolved.

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.

CSCec51252

You must issue a "shut" on both ends of affected POS circuits before performing a maintenance action on those circuits. If a POS circuit is restored without first issuing the shut commands, traffic loss is greater than 50 ms. When a maintenance action is taken, one end of the circuits could come up before the other. During that time, traffic is lost because the other end is not up yet. This issue will be resolved in a future release.

CSCed06286

If you create several bridgegroups before provisioning POS circuits, POS stays in the BLK state. If this issue occurs, perform a shut/no shut on POS interface that is stuck in the BLK state. This issue will not be resolved.

CSCeb25778

When a MAC-SA is seen for the first time, it is learned, but may age out in less than 5 minutes. If the same MAC-SA is seen again before the first ages out, the entry will age out after 5 minutes, as expected. This issue will not be resolved.

CSCin43669

Timer expiration can cause a system crash when you attempt to remove 250 Shared Packet Ring (SPR) subinterfaces using the "no int spr1" command, while Cisco Discovery Protocol (CDP) is also enabled. To avoid this issue, either turn off CDP, issue the command, and then turn CDP back on; or remove the SPR subinterfaces explicitly. This issue will not be resolved.

CSCea36829

The broadcast packet count is always 0 for the SPR interface. The ML100 and ML1000 hardware does not support counting broadcast packets. This issue will not be resolved.

CSCeb21996

When the POS interface is removed from SPR due to a defect, while SPR is configured in immediate mode, the defect type may not be reported. This only occurs if the defect is set and clears in less then 50 ms.

CSCdz49700

ML-series cards do not appear in the Cisco Discovery Protocol (CDP) adjacencies and do not participate in the Spanning-Tree Protocol. All packets are counted as multicast.

The ML-series cards always forward Dynamic Trunking protocol (DTP) packets between connected devices. If DTP is enabled on connected devices (which might be the default), DTP might negotiate parameters, such as ISL, that are not supported by the ML-series cards. All packets on a link negotiated to use ISL are always counted as multicast packets by the ML-series card, and STP and CDP packets are bridged between connected devices using ISL without being processed. To avoid this issue, disable DTP and ISL on connected devices. This functionality is as designed.

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.

CSCdz69700

Issuing a shutdown/noshutdown 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.

CSCea01675

Packets without an 802.1q VLAN tag are classified as COS 0. This issue will not be resolved.

CSCea20962

No warning is displayed when applying OOS to ML drop ports on the circuit provisioning window. This issue is resolved in Release 5.0.

CSCin29274

When configuring the same static route over two or more interfaces, use the following command:

ip route a-prefix a-networkmaska.b.c.d

Where a.b.c.d is the address of the outgoing gateway, or, similarly, use the command:

ip route vrfvrf-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.

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.

CSCdy55437

The maximum MAC Address Learn Rate for the ML-Series cards is 1300 MAC addresses per second. This number varies based on the ML-Series control and forwarding plane loads. If the forwarding and control planes are heavily loaded, the maximum MAC Address Learn Rate could be as low as 100 MAC addresses per second. To correct a situation where an ML-Series card has stopped learning MAC addresses, reduce the load on these cards. This load limit is by design.

CSCdy47284

Oversize frames are not supported on ML100 Fast Ethernet ports. Oversize frames cause egress traffic to incur CRC, line, and fragment errors on these ports. To avoid this issue, do not send jumbo packets to ML far end ports. This is as designed.

Maintenance and Administration

Caution VxWorks is intended for qualified Cisco personnel only. Customer use of VxWorks is not recommended, nor is it supported by Cisco's Technical Assistance Center. Inappropriate use of VxWorks commands can have a negative and service affecting impact on your network. Please consult the troubleshooting guide for your release and platform for appropriate troubleshooting procedures. To exit without logging in, enter a Control-D (hold down the Control and D keys at the same time) at the Username prompt. To exit after logging in, type "logout" at the VxWorks shell prompt.

Note In previous releases you could independently set proxy server gateway settings; however, with Release 4.6.x, this is no longer the case. To retain the integrity of existing network configurations, settings made in a previous release are not changed on an upgrade to Release 4.6.x. Current settings are displayed in CTC (whether they were inherited from an upgrade, or they were set using the current GUI).

CSCee39968

The Timing Report in the Maintenance window of CTC fails to update the report of a new timing failure after a previous reference has failed. For example, if you inject LOS and then switch to injecting LOF, the Timing Report fails to display the LOF against the reference, or only displays the failure briefly, upon clearing. This issue is resolved in Release 5.0.

CSCed27389

Under certain conditions, you cannot unlock a cross-connect from CTC and TL1. If you lock a cross-connect, then quickly click the SWITCH button, the Clear is sent only to the protect XC side. This causes the Unlock command to fail. This issue is resolved in Release 5.0.

CSCec17281

When the "Status" field for a circuit in the circuit table shows "INCOMPLETE," this can be interpreted as an alarm or traffic-affecting condition on the circuit. On SNCP and MS-SPRing circuits, a circuit is shown as INCOMPLETE if either the working or protect path is missing a network span or connection, even if traffic is flowing without error on the other, redundant path. This can lead to confusion, since the meaning of "INCOMPLETE" is not well-defined. You can see this if you, for example, introduce LOS on a span in a MS-SPRing network such that traffic is switched to another path around the ring. Ignore the INCOMPLETE circuit status in such cases and instead look for any alarms in the network. The circuit Status is defined more clearly in Release 5.0.

CSCec21668

Do not create more than three VC3 or VC12 circuits in auto-range mode. The VC3 or VC12 circuits can be created in batches of three, or manually. When you create more than three VC3 or VC12 circuits in auto-range mode, CTC creates the first three circuits and then issues the error message:

"Exception: Source is not fully specified"

This can occur with an SDH node when you wish to create more than three VC3 or VC12 circuits in auto-range mode. This issue is resolved in Release 5.0.

CSCeb39359

When changing NE timing from extern/mix to Line timing, a Transient IEF alarm may be reported against the standby XC10G. This issue will not be resolved.

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 is resolved in Release 6.0.

CSCea78364

Simultaneous failure of working and protect cards in 1:N protection groups may not be alarmed as service affecting. This can occur when the working card of the protection group has been removed from the chassis, and the protect card of the protection group is subsequently issued a Manual Reset. Since the working and protect facilities are impaired, the Improper removal alarm should clear and be reissued as a Critical and service affecting condition. This issue is resolved in Release 5.0.

CSCdz62367

When replacing a failed working E1-42 card in a 1:1 or 1:N protection configuration with the protect card carrying the switched traffic, bit errors, less than 50ms in duration, are possible on the activated protection card. This issue will not be resolved.

CSCdy10030

CVs are not positively adjusted after exiting a UAS state. When a transition has been made from counting UAS, at least 10 seconds of non-SES must be counted to exit UAS. This issue will not be resolved.

CSCdx35561

CTC is unable to communicate with an ONS 15454 SDH that is connected via an Ethernet craft port. CTC does, however, communicate over an SDCC link with an ONS 15454 SDH that is Ethernet connected, yielding a slow connection. This situation occurs when multiple nodes are on a single Ethernet segment and the nodes have different values for any of the following features:

•Enable OSPF on the LAN

•Enable Firewall

•Craft Access Only

When any of these features are enabled, the proxy ARP service on the node is also disabled. The ONS 15454 SDH proxy ARP service assumes that all nodes are participating in the service.

This situation can also occur immediately after the aforementioned features are enabled. Other hosts on the Ethernet segment (for example, the subnet router) may retain incorrect ARP settings for the ONS 15454 SDHs.

To avoid this issue, all nodes on the same Ethernet segment must have the same values for Enable OSPF on the LAN, Enable Firewall, and Craft Access Only. If any of these values have changed recently, it may be necessary to allow connected hosts (such as the subnet router) to expire their ARP entries.

You can avoid waiting for the ARP entries to expire on their own by removing the SDCC links from the affected ONS 15454 SDH nodes. This will disconnect them for the purposes of the proxy ARP service and the nodes should become directly accessible over the Ethernet. Network settings on the nodes can then be provisioned as desired, after which the SDCC can be restored.

This issue will not be resolved.

CSCdy11012

When the topology host is connected to multiple OSPF areas, but CTC is launched on a node that is connected to fewer areas, the topology host appears in CTC, and all nodes appear in the network view, but some nodes remain disconnected. This can occur when the CTC host does not have routing information to connect to the disconnected nodes. (This can happen, for example, if automatic host detection was used to connect the CTC workstation to the initial node.)

CTC will be able to contact the topology host to learn about all the nodes in all the OSPF areas, but will be unable to contact any nodes that are not in the OSPF areas used by the launch node. Therefore, some nodes will remain disconnected in the CTC network view.

To work around this issue, if no firewall enabled, then the network configuration of the CTC host can be changed to allow CTC to see all nodes in the network. The launch node must be on its own subnet to prevent network partitioning, and craft access must not be enabled. The CTC host must be provisioned with an address on the same subnet as the initial node (but this address must not conflict with any other node in the network), and with the default gateway of the initial node. CTC will now be able to contact all nodes in the network.

If a firewall is enabled on any node in the network, then CTC will be unable to contact nodes outside of the initial OSPF areas. This issue will not be resolved.

CSCdy57891

An LOP-P alarm can be inadvertently cleared by an LOS that is raised and cleared. On STM-N cards, when an LOP condition and an LOS condition are both present on the input, an LOS will be raised. However, upon clearing the LOS with the LOP still present, the LOP alarm is not raised. An AIS-P condition will be visible. This issue will not be resolved.

CSCdw38283

If a node has one good BITS reference and is running in a normal state, and you configure a second BITS reference, then reconfigure the second reference within 30 seconds of applying the first configuration, the node will enter FAST START SYNC mode. To avoid this problem, wait a minute before configuring the second reference a second time. This issue is a hardware limitation, and there are no current plans to resolve it.

CSCdw23208

The following table summarizes B1, B2, and B3 error count reporting for SDH optical cards. Note that not all reporting is done according to ITU specifications. In particular, ITU specifies error counts for B1 and B3 as the number of blocks with errors (refer to ITU-T G.826 for paths and ITU-T G.829 for RS and MS).

Table 0-5 Error Count Reporting

B1

B2

B3

ITU Specification

block

bit

block

STM1

block

bit

block

STM4

bit

bit

bit

STM16 trunk

bit

bit

bit

STM16 AS

block

bit

bit

STM64

block

bit

bit

STM1-8

bit

bit

bit

STM4-4

bit

bit

bit

CSCdw82689

After creating 509 VLANs and provisioning many Ethernet circuits, Ethernet circuit provisioning can become very slow, or possibly fail. Ethernet traffic may also incur an outage of a few minutes. To avoid this problem, delete any VLANs that are created but not used, and do not recreate them. There is no resolution planned for this issue.

CSCdv10824: Netscape Plugins Directory

If you use CTC, JRE, and the Netscape browser with a Microsoft Windows platform, you must ensure that any new installation of Netscape uses the same Netscape directory as the previous installation did, if such an installation existed. If you install Netscape using a different path for the plugins directory, you will need to reinstall JRE so that it can detect the new directory.

"Are you sure" Prompts

Whenever a proposed change occurs, the "Are you sure" dialog box appears to warn the user that the action can change existing provisioning states or can cause traffic disruptions.

Alarms

CSCef63240

Rarely, an LP TIM alarm displays its severity as NR instead of MJ in CTC. This can occur when a VC3 circuit is created on Port 5 and IO has detected a VC4 PLM alarm. This issue will not be resolved.

CSCee29901

A CARLOSS alarm can take up to 3 minutes to be reported depend of the number of VLANs configured on a node. When the alarm does appear, if you clear this major alarm, the severity changes to minor, but then the alarm disappears. This alarm's severity change behavior is under investigation.

MS-SPRing Functionality

CSCec34856

When you create a circuit over MS-SPRing or DRI, the resource usage in the Maintenance > Cross-Connect > Resource Usage tab will display the incorrect VC# for the circuit you created. Use the Circuit Edit > Monitors window to view the correct VC#. This issue is resolved in Release 5.0.

CSCea81000

In a two-fiber or four-fiber MS-SPRing, MS-RFI is not reported for an LOS or LOF with a ring lockout in place on a different span. This issue is resolved in Release 5.0.

CSCeb09217

Circuit states are not updated after a span update. If you update a four node OC-12 two-fiber MS-SPRing to a four node OC-192 two-fiber BLSR, the previous PCA circuits should be shown as two-fiber MS-SPRing protected, but they are shown as "UNKNOWN" protected. If you relaunch CTC this situation is corrected. This issue is resolved in Release 5.0.

CSCdz66275

When creating a MS-SPRing from the network view, the node default values for reversion are not initially used. To see this, starting with no preferences file, log into a node with CTC, and set the node default values for MS-SPRing reversion. Now, in Network view, use the MS-SPRing wizard to create a MS-SPRing. The node level default values are initially ignored while the wizard is still in operation. If you encounter this issue, you may need to change values as appropriate for your network while you are still using the MS-SPRing wizard. Once the wizard is finished, these values are saved to a preferences file and will be used henceforth. This issue will not be resolved.

CSCdw53481

Two MS-Rs are not allowed to coexist. If you execute a manual ring switch command on one side of an MS-SPRing node and apply another manual ring switch command on other side of the node, the second manual ring switch command is rejected. This works as designed. The implementation complies with Telcordia GR-1230, R6-102.

CSCdx45851

On a four fiber MS-SPRing, restoring the database for all nodes at the same time could cause VC4-16c traffic to fail to switch. Do not restore the database for multiple nodes simultaneously. The proper procedure for restoring the database for multiple nodes is to restore one node at a time. This procedure is documented in the user documentation.

CSCdx19598

A rare hardware failure on an STM16AS card transmitter can trigger SEF on the receiving STM16AS card in a four fiber MS-SPRing (or BLSR) configuration. The BER calculations are suspended when SEF is detected, so SD or SF is never raised. Likewise SEF is not considered a signal failure condition like LOS or LOF, so a protection switch will not occur. If this occurs, use the CTC GUI to force a protection switch on the MS-SPRing (or BLSR). This issue will not be resolved.

CSCdv53427

In a two ring, two fiber MS-SPRing (or BLSR) configuration (or a two ring MS-SPRing or BLSR configuration with one two fiber and one four fiber ring) it is possible to provision a circuit that begins on one ring, crosses to a second ring, and returns to the original ring. Such a circuit can have protection vulnerabilities if one of the common nodes is isolated, or if a ring is segmented in such a way that two non-contiguous segments of the circuit on the same ring are each broken. There are two possible workarounds for this issue:

1. Manually route the circuit to avoid the "one circuit over two ring" routing scenario.

2. When routing the circuit automatically, select the Using Required Nodes/Spans option in the Circuit Routing Preference screen, then select the appropriate spans to avoid the "one circuit over two ring" routing scenario.

This issue will be resolved in a future release.

Database Restore on an MS-SPRing (or BLSR)

When restoring the database on an MS-SPRing (or BLSR), follow these steps:

Step 1 To isolate the failed node, issue a force switch toward the failure node from the adjacent east and west nodes.

Step 2 If more than one node has failed, restore the database one node at a time.

Step 3 After the TCCi has reset and booted up, release the force switch from each node.

SNCP Functionality

CSCee68239

Low order circuits cannot be created over Integrated SNCP DRI. Circuit creation fails with an xUpsrSelectorPayloadMismatch error. This issue is resolved in Release 5.0.

CSCeb37707

With a VT SNCP circuit, if you inject signals with a thru-mode test set into one path of the circuit in a particular order, you may not see the appropriate alarms. This can occur when you first inject LOP-P, then clear, then inject LOP-V. This issue will not be resolved.

Active Cross Connect or TCC2 Card Removal

As in MS-SPRing (or BLSR) and 1+1, you must perform a lockout on SNCP (or path protection) before removing an active cross connect or TCC2 card. The following rules apply to SNCP (or path protection).

Active cross connect cards should not be removed. If the active cross connect or TCC2 card must be removed, to minimize network interruption you can first perform an XC10G (or XCVXL) side switch and then remove the card once it is in standby, or you can perform a lockout on all circuits that originate from the node whose active cross connect or active TCC2 will be removed (performing a lockout on all spans will also accomplish the same goal).

SNMP

CSCec75857

There is no SNMP return value for dsx1TotalTable when you configure an ONS 15454 with DSX 1 day stats, then query the node. This issue is resolved in Release 5.0.

Performance Monitoring

CSCef72828

No TCA is generated for AISS E1 path. The default threshold in CTC is zero. This can be changed in the GUI, but is never used by the card. Thus threshold crossings on this PM do not generate a TCA. This issue is resolved Release 6.0, and in maintenance Releases 5.0.1 and 5.0.2.

TL1

DDTS # CSCsh41324

When running release 4.1.4, if a circuit is created within CTC and if that circuit is retrieved via TL1, all looks as expected. However, after the software is upgraded to release 6 and latter, the circuit retrive does not show the same value as was before. For example FAC-4-1 changes to FAC-4-0. Workaround is to delete and recreate the circuit within CTC.

Documentation

The following ML-series command documentation applies for Release 4.6.3. This command is not in the user documentation for the 4.6 general release. Users of Release 4.6.3 should refer to the release notes for this command.

[no] pos vcat resequence {enable | disable}

Enables or disables the SW-LCAS H4 byte sequence number re-sequence feature. If an ML-Series card running Software Release 4.6.2 or later is interoperating with an ML-Series card running Software Release 4.6.0 or 4.6.1, then the pos vcat resequence disable command must be added to the configuration of the ML-Series card running Software Release 4.6.2 or later.

Syntax Description

Parameter

Description

Enable

Enables the re-sequencing of the H4 byte sequence numbers when a member is added to the VCAT group or removed from the VCAT group. If both members are up, then member #0 will have sequence number of zero (0) and member #1 will have sequence number one (1). If only one member is up, then the sequence number of that member will be zero (0).

Disables

Disables the re-sequencing of the H4 byte sequence numbers when a member is added to the VCAT group or removed from the VCAT group. Member #0 will always have a sequence number of zero (0) and member #1 will always have a sequence number of one (1)

Defaults

The default setting is Enable.

Command Modes

Per POS port configuration

Usage Guidelines

The no form of the command will set the mode to the default.

Examples

The following example disables the re-sequencing of the H4 byte sequence numbers for POS port 0:

Router(config)#int pos 0

Router(config)#pos vcat resequence disable

Resolved Caveats for Release 4.6.6

The following items are resolved in Release 4.6.6

Hardware

CSCec33248

Pulling the active XCVXL card might result in a traffic outage lasting for greater than 2 seconds. It is possible to see this approximately 1 out of every 7 active XCVXL card pulls. Excessive traffic outage from this issue will not occur after a software-induced XCVXL side switch. In this case, you can expect a traffic hit of less than 60 ms, and traffic will resume normally. This issue is resolved in Release 4.6.3.

Line Cards

CSCec82450

When the Active TCC2's power supply fails (using a failure insertion test card) and the Standby TCC2 takes over; the circuits on the DS3I and E1-42 cards in that node might incur a traffic hit. This issue is resolved in Release 4.6.3.

CSCec30792

On a small percentage of active XCVXL card pulls, the E1-42 card can lose traffic for more than 2 seconds. To avoid this issue, do not pull active XCVXL card. First, switch to the protect XCVXL, wait for the switch, then, pull the XCVXL in question. This issue is resolved in Release 4.6.3.

CSCed27998

Rarely, a traffic hit can occur during the TCC2 switch that occurs as a part of the upgrade procedure. Traffic hits are only expected on E1-42 traffic; all other E3 & DS3 traffic should remain errorless during the upgrade's TCC2 switch portion. Hits to the E1-42 traffic occur 90% of the time during the upgrade if all 42 circuits are provisioned on the card. This issue is resolved in Release 4.6.3.

CSCee65098

Occasionally, E1-42 cards might incur multiple traffic hits during an upgrade to Release 4.6.2. Some working cards might switch to protect and require manual intervention to switch back. This issue is resolved in Release 4.6.3.

CSCec83712

Avoid pulling the active cross connect when the standby is locked out. If the standby cross connect card is locked out and the active cross connect card is pulled, the E1-42 card switches to protect. This switch should not occur. After the active cross connect card reboots and traffic is restored, the reverting E1-42 card takes a hit of +/- 1 second. This issue is resolved in Release 4.6.3.

CSCed06531

Malformed IP packets can potentially cause the XTC, TCC/TCC+/TCC2 and TCCi/TCC2 control cards to reset. Repeated transmission of these malformed packets could cause both the control cards to reset at the same time. This issue is resolved in Release 5.0, and maintenance Releases 4.1.4, 2.3.5, 4.0.3, and 4.6.2.

CSCed86946

Malformed ICMP packets can potentially cause the XTC, TCC/TCC+/TCC2 and TCCi/TCC2 control cards to reset. Repeated transmission of these malformed packets could cause both the control cards to reset at the same time. This issue is resolved in Release 5.0, and maintenance Releases 4.1.4, 2.3.5, 4.0.3, and 4.6.2.

CSCec88426, CSCec88508, CSCed85088

Malformed TCP packets can potentially cause the XTC, TCC/TCC+/TCC2, and TCCi/TCC2 control cards to reset. Repeated transmission of these malformed packets could cause both the control cards to reset at the same time. This issue is resolved in Release 5.0, and maintenance Releases 4.1.4, 2.3.5, 4.0.3, and 4.6.2.

CSCec59739, CSCed02439, CSCed22547

The XTC, TCC/TCC+/TCC2 and TCCi/TCC2 control cards are susceptible to a TCP-ACK Denial of Service (DoS) attack on open TCP ports. The controller card on the optical device will reset under such an attack.

A TCP-ACK DoS attack is conducted by withholding the required final ACK (acknowledgement) for a 3-way TCP handshake to complete, and instead sending an invalid response to move the connection to an invalid TCP state. This issue is resolved in maintenance Releases 4.1.4, 2.3.5, 4.0.3, and 4.6.2.

CSCec88402, CSCed31918, CSCed83309, CSCec85982

Malformed UDP packets can potentially cause the XTC, TCC/TCC+/TCC2, and TCCi/TCC2 control cards to reset. Repeated transmission of these malformed packets could cause both the control cards to reset at the same time. This issue is resolved in Release 5.0, and maintenance Releases 4.1.4, 2.3.5, 4.0.3, and 4.6.2.

CSCea16455, CSCea37089, CSCea37185

Malformed SNMP packets can potentially cause the XTC, TCC/TCC+/TCC2 and TCCi/TCC2 control cards to reset. Repeated transmission of these malformed packets could cause both the control cards to reset at the same time. This issue is resolved in Release 4.6, and maintenance Releases 4.0.1, 4.0.3, and 4.1.3.

CSCee27329

If an account has a blank password set, and an attempt is made to log into the device with a password greater than ten characters, the attempt will be successful. This vulnerability only affects the TL1 login interface. The CTC login interface is not vulnerable to this vulnerability. The CTC and TL1 user interfaces prevent the setting of a blank password as the password. Only the CISCO15 userid, during initial install process, has a blank password, which is to be changed as part of the initial install process. This issue is resolved in Releases 4.6.2 and 5.0.

CSCed30150

When the E1-42 card is fully loaded, J2 path trace cannot be retrieved on VC12 circuits. This issue is resolved in Release 4.6.2.

CSCed25636

Rarely, it can take approximately 20 seconds for a 1:N soft switch command to take effect on E1-42 after a software upgrade, and when several circuits are provisioned. Soft reset the card or reprovision all circuits if this occurs. This issue is resolved in Release 4.6.2.

CSCed41691

Rarely, high switch times for E1-42 protection switches can occur with a four node system, where spans are mixed, with 1+1, path protection, and two-fiber BLSR, where drops are E1-42 with 1:N protection. If you perform a 1:N protection switch on E1-42, traffic hits might be greater than 60 ms. This issue is resolved in Release 4.6.2.

CSCuk39201

The E1-42 J2 expected input field is longer than 15 characters. This issue is resolved in Release 4.6.2.

CSCed47356

For J2 path trace provisioned as AUTO mode, the expected path trace is not updated in CTC when the E1-42 port is greater than 21. Use "Manual" Mode to avoid this issue. This issue is resolved in Release 4.6.2.

CSCed47363

Received J2 is not shown on the Edit Pathtrace screen. This can be seen when the VC12 number is greater than 21. This issue is resolved in Release 4.6.2.

J1 and J2 Path Trace with E1-42 Cards

On E1-42 cards, do not enable J1 or J2 monitoring in Release 4.6.1. To do so can result in a loss of traffic. If you do have J1 or J2 path trace turned on, and you upgrade to Release 4.6.1, turn those features off prior to the upgrade in order to avoid possible traffic loss. This issue is resolved in Release 4.6.2.

CSCed25636

Occasionally, a 1:N soft switch command can take approximately 20 seconds to take effect on E1-42 after a software upgrade when several circuits are provisioned. If this occurs, soft reset the card, or reprovision all the circuits. This issue is resolved in Release 4.6.2.

CSCed31270

Rarely, E1-42 traffic might fail to recover after active XC boot up following a lockon and removal of the active XC. To work around this, induce the software to perform a "chipInitSequence." This issue is resolved in Release 4.6.2.

CSCed29086

Resetting both TCC2s occasionally causes the IO cards to send and/or receive corrupt K bytes. If this occurs, it might cause a ring to unswitch at the passthrough node. If you cause a force switch and then clear the force switch, traffic will recover. This issue is resolved in Release 4.6.2.

CSCed36598

When DHCP forwarding is turned on, and the forwarding to address is set to a cellbus address instead of a DHCP server address, you can lose connection to your nodes. Always set the forwarding address to a DHCP server. This issue is resolved in Release 4.6.2.

CSCed30150

When the E1-42 card is fully loaded, J2 path trace cannot be retrieved on VC12 circuits. This issue is resolved in Release 4.6.2.

CSCeb49210

A soft reset of the working or protect 2.5g multirate card in a Y-cable protection group clears an existing "Lockout of protection" request. This issue is resolved in Release 4.6.

CSCdy65482

On the AIC-i card, a volume adjustment on the receive value of a four-wire orderwire circuit will be displayed as the negative of its actual value. To work around this issue, enter the negative of the value you actually want for the receive value. For example, adjust the receive value on CTC to -2 dbm for a gain of 2 dbm. This issue is resolved in Release 4.6.

CSCeb43397 and CSCeb42187

Rarely, E1-42 cards may incur a greater than 60 ms traffic disruption during protection switches. This can occur when you pull the active working E1-42 card. This issue is resolved in Release 4.6.

CSCeb34655 and CSCeb39337

Very rarely, E1-42 takes greater than 2 second hits on an active XCVXL pull. To avoid this issue, side switch the XCVXL cards. This issue is resolved in Release 4.6.

CSCeb39337

Very rarely, DS3i can lose traffic on an active XC-VXL pull. To avoid this issue, side switch the XC-VXL cards. This issue is resolved in Release 4.6.

CSCea60715

In a 1+1 configuration, traffic may be lost upon reset of both working and protect STM64 cards. If you reset the protect card and then, before the protect card completes rebooting, reset the working card, the traffic does not switch to protect but remains on working. If the working card is removed during the time the protect is still coming up, the traffic does not switch to working and is lost. To avoid this issue, wait for the protect to fully come up before pulling the work card. This issue is resolved in Release 4.6.

CSCeb19055

On the subsequent 3 slots occupied by the protect FMEC, MEA is not set when a mismatched IO card is inserted. This issue is resolved in Release 4.6.

CSCec46228

Rarely, traffic on the DS3i-N-12 card might incur a hit when the active TCC2 is pulled. Removing the active TCC2 can cause timing hits and disrupt communication between cards, causing protection switches. To avoid this issue, instead of pulling the active TCC2, issue a manual switch, then pull the TCC2 once it has become standby. This issue is resolved in Release 4.6; however, you should still always switch traffic away from any TCC2 you intend to remove.

CSCec49231

In an LMSP 1+1 configuration, following an XCVXL reset, The HP-PLM alarm might become stuck. The following steps will reproduce this issue.

Step 1 Create a circuit from and to DS3i-N-12 cards through an STM16 LMSP (1+1) in a two-node configuration.

Step 2 Perform a LOCKOUT on the cross connect cards (XCVXL).

Step 3 Perform a hard reset on the active XCVXL cards.

Traffic goes down, then returns after the XCVXLs finish booting. The false HP-PLM alarms are now present on the STM16 span card. Once the false HP-PLM alarms are detected; to remove the false alarms, perform a TCC side switch. This issue is resolved in Release 4.6.

CSCed05846

In Releases 4.0, 4.0.1, and 4.1 the standby TCC+, TCC2, or XTC card might reset automatically. This can occur at any time, but only rarely. This issue is resolved in Release 4.6, and maintenance Releases 4.1.1 and 4.1.3.

CSCeb34326

Rarely, an E1-42 card can go into continual autoreset. This can occur after the E1-42 card is inserted, or following a node power cycle. Hard reset the E1-42 by removing and re-inserting it into the chassis to stop this cycle. This issue is resolved in a Release 4.6.

CSCec13638

Rarely, a greater than 2 second traffic hit can occur when the active XC is pulled, then you switch the IO from active (Working) to standby (protect). This issue is resolved in Release 4.6.

CSCeb42187

Occasionally, if you remove the active working E1-42 card, the card takes a greater than 60 ms hit. This issue is resolved in Release 4.6.

CSCeb41057

On an E1-42, the LOSS-L parameter appears as random values. For example, sometimes it appears as -269,488,145. This makes the count unavailable from the card. This issue is resolved in Releases 4.6 and 4.1.3.

CSCeb49051

If you configure 1:N or 1:1 protection for DS1, DS3, E1, or E3, then lock the XC and soft reset the active XC, after the XC finishes resetting, the protection for the electrical cards switches. This issue is resolved in Releases 4.1.3 and 4.6.

DWDM Cards

CSCed46374

You cannot manually switch a DWDM path protection span when a TXP card is configured with line termination mode and GCC OFF. You can individually force traffic away by editing individual circuits. This issue does not affect MSSP or LMSP. This issue is resolved in Release 4.6.2.

CSCeb49144

The Lamp Test feature does not display all the LED colors available on the 2.5G Transponder. This issue is resolved in Release 4.6.

CSCeb37346

Near end and far end PMs might increment simultaneously on TXPP-2.5G cards. This can occur when two nodes have TXPP-2.5G cards and two nodes have STM16 cards in a four node network, where both TXPP-2.5G cards have STM16 SFPs on them, and are in MS (Line Termination) mode. By default, the TXPP-2.5G cards are in Splitter protection: the first DWDM port is working and the second is protect. If you remove the receive fiber of the first DWDM port on one TXPP-2.5G card, both near and far end counts begin to increment. The far end counts should not increment in this case. This issue is seen only when the Txpd cards have G709 and FEC on. If the cards have G709 and FEC off, only the near end counts will increment, as expected. This issue is resolved in Release 4.6.

CSCeb39991

SCHED-PMREPT-CLNT does not generate the automatic report for TXPP cards. If you schedule PM reports on a Client or Trunk port of a TXPP, REPT^PM^EVT is never generated. However, the RTRV-PMSCHED-ALL count shows that the count is decreasing. This issue is resolved in Release 4.6.

CSCeb49210

A soft reset of the working or protect 2.5g multirate card in a Y-cable protection group clears an existing "Lockout of protection" request. This issue is resolved in Release 4.6.

ML Series

CSCef62420

On ML100t and ML1000, defects might not be detected and alarms not be reported on a POS port. This can occur when you provision a circuit to POS 0, provision another circuit to POS 1, and then delete the circuit on POS 1. To work around this issue, delete and reprovision the POS 0 circuit. This issue is resolved in Release 5.0 and maintenance Release after 4.6.6.

CSCin35960

POS ingress classification based on IP precedence does not match the packets when inbound policy map classifying based on IP precedence is applied to the POS interface, which is configured for HDLC or PPP encapsulation. To avoid this issue, use LEX encapsulation (default) or, at the Ethernet ingress point, mark the COS based on an IP precedence classification, then classify based on the COS during POS ingress. This issue is resolved in Release 4.6.

CSCea11742

When a circuit between two ML POS ports is provisioned OOS, one of the ports might erroneously report TPTFAIL. This issue exists for both ML100T-12 and ML1000-2 cards. If this occurs, open a console window to each ML card and configure the POS port to shutdown. This issue is resolved in Release 4.6.

CSCdy31775

Packets discarded due to output queue congestion are not included in any discard count. This occurs under either of the following conditions:

•Traffic on ML-series cards between Ethernet and SDH ports, with oversubscription of available circuit bandwidth configured, leading to output queue congestion.

•Traffic from SDH to Ethernet, with oversubscription of the available Ethernet bandwidth.

This issue is resolved in Release 4.6 by performance monitoring enhancements.

CSCeb11930

The POS shutdown command will raise PLM-P on the far end for a VC3 circuit in an SDH node. This occurs on all ML-series cards in nodes running Release 4.0 or 4.1. This issue is resolved in Release 4.6.

CSCeb56287

When an ML-series circuit's state is provisioned from In-Service (IS) to Out-of-Service (OOS), and then back to IS, data traffic does not recover. To avoid this issue, prior to changing the state from IS, set the POS port to shut down on the CLI. After the state is changed back to IS from OOS, set the POS port to "no shutdown." This issue is resolved in Release 4.6.

G Series Cards

CSCec05896

When a G-series card is used in transponder mode the severity of reported alarms is incorrect in some cases. When using transponder mode on G-series cards, if alarm severity is an issue, use the alarm profile editor to set the severity to the desired values. This issue is resolved in Release 4.6 and maintenance Release 4.1.3.

CSCeb80771

An Ethernet traffic hit of 500-600 ms may occur when upgrading to Release 4.1 from a prior release. This can occur if active traffic is running on a G1000-4, G1K-4 or G1000-2 card when upgrading the node to Release 4.1. The hit will occur only the first time that you upgrade to Release 4.1. On subsequent downgrades followed by upgrades there will be no traffic hit and the upgrade will be errorless. There is no workaround; however the issue will not occur when upgrading from Release 4.1 to a later release. This issue is resolved in Releases 4.1.3 and 4.6.

Maintenance and Administration

CSCef75019

In the CTC node view Provisioning > Security > Access tabs, the option to enable SSH access instead of telnet does not function. This issue is resolved in Release 4.6.3.

CSCed76192

If a host on the same Ethernet as a given NE sends ARP requests to the NE, with a source address that is in a restricted address range (see below), the NE might reboot and other cards in the shelf reset. The NE might become unmanageable under these circumstances. The NE will install an ARP entry for the illegal IP address, with the MAC supplied in the ARP request, thereby misrouting important addresses.

Restricted addresses are those in the loopback network, 127.0.0.0/8, in the multicast networks, 224.0.0.0/4, and in the cell bus network, 192.168.100.0/24.

The workaround is to ensure that no legitimate hosts have addresses in the illegal networks, and that no compromised hosts that might generate ARP attacks are on the Ethernet. This issue is resolved in Releases 4.0.3, 4.6.2, 4.1.5, and 5.0.

CSCed41574

The wrong Port level alarm severity is reported on a port when the port only has SNCP standby signals; in other words, when traffic is protected by another path. This issue is resolved in Release 4.6.2.

CSCed26988

An LOS alarm might fail to clear on a FAR-END node after a lockout command is issued on EAST and WEST spans and the card is pulled in a four node, two-fiber MS-SPRing configuration using STM-64 cards. This issue is resolved in maintenance Releases 4.1.3 and 4.6.2.

CSCea45923

If you preprovision an STM1E card and preprovision a VC4 circuit on that STM1E card, and then navigate to card level, Provisioning tab, in the resulting window, all tabs except the "C2 Byte" tab work fine on clicking them; however, if you click on the "C2 Byte" tab, CTC fails to repaint properly until you click another tab. To avoid this issue, use the "C2 Byte" tab only on inserted cards. This issue is resolved in Release 4.6.2.

CSCea21081

If you try to change the STM1E-12 NE default values for SES thresholds an Error message is displayed. To change the values for SES thresholds, go to the card's Thresholds tab and change them manually. This issue is resolved in Release 4.6.2.

CSCea21079

It is not possible to set STM1E-12 NE Default values for BEC thresholds in the CTC Node View, Provisioning > Defaults Editor. To change the values for BEC thresholds go to the card's Thresholds tab and change them manually. This issue is resolved in Release 4.6.2.

Transmission Control Protocol Specification

A vulnerability in the Transmission Control Protocol (TCP) specification (RFC793) has been discovered by an external researcher. The successful exploitation enables an adversary to reset any established TCP connection in a much shorter time than was previously discussed publicly. Depending on the application, the connection might be automatically reestablished. In other cases, a user must repeat the action (for example, open a new Telnet or SSH session). Depending on the attacked protocol, a successful attack might have consequences beyond terminated connection that also must be considered. This attack vector is only applicable to those sessions that terminate on a device (such as a router, switch, or computer) and not to those sessions that only pass through the device (for example, transit traffic that is being routed by a router). Also, this attack vector does not directly compromise data integrity or confidentiality.

All Cisco products that contain TCP stack are susceptible to this vulnerability.

This advisory is available at http://www.cisco.com/warp/public/707/cisco-sa-20040420-tcp-ios.shtml, and describes the vulnerability as it applies to Cisco products that run Cisco IOS® software.

A companion advisory that describes the vulnerability for products that do not run Cisco IOS software is available at http://www.cisco.com/warp/public/707/cisco-sa-20040420-tcp-nonios.shtml.

This issue is resolved in Releases 2.3.5, 4.1.4 and 4.6.2.

CSCec48979

With STM1_E12 E4 traffic, when you inject BPV errors at 10E-3 rate to the E4 traffic port, sometimes SF will not be reported. This issue is resolved in Release 4.6.2.

CSCed07126

If you provision a non-existent static route to a node's subnet and then delete it, the node will lose connectivity. If this occurs, remove and replace the Ethernet cable. This issue is resolved in Release 4.6.2.

CSCed58066

If a workstation running CTC has multiple NIC cards installed, and the primary NIC card is not used to connect to the node, and the node is unable to send IP packets to the IP address of the primary NIC card, or if the workstation running CTC is separated from the node by a router that performs NAT translation of the CTC workstation IP address, CTC repeatedly disconnects and reconnects (every two minutes). In either of these cases, CTC registers for alarms and provisioning updates using the IP address of the primary NIC, which the node cannot contact. When the node attempts to contact CTC, the connection fails. This causes the node to remove CTC from its list of registered clients. When CTC subsequently polls the node, CTC determines that it is not registered. CTC resets itself to ensure that it has current alarms and provisioning from the node, causing the disconnect and reconnect.

To avoid this issue, enable the proxy server on all LAN connected nodes with the Proxy-only configuration. This issue is resolved in Release 4.6.1.

CSCed60557

Connecting two nodes with the same IP address to the same LAN will result in a broadcast storm. If this occurs, disconnect one of the nodes with the duplicate IP address. This issue is resolved in Release 4.6.1.

CSCdz84149

If a user is logged into CTC as a superuser (or other higher level security type), and then another superuser changes the first user's security level to "retrieve" (or another lower level security type) without first logging the user out, the lower level user is then still able to perform some actions authorized only for the original login security level. For example, a "provisioning" level user demoted to "retrieve" level in this manner can still provision and edit MS-SPRings (BLSRs) while logged into the current session, though the same user may no longer provision DCCs. To ensure that a user's level is changed completely, the superuser must log the user out prior to changing the security level. This issue is resolved in Release 4.6.

CSCdz90753

In the Maintenance > Cross Connect Resource Pane, the VT matrix port detail is inconsistent with the general VT matrix data. This can occur when a 1+1 protection scheme is in place. To avoid confusion, note that the VT matrix data counts the VTs for both the working and protect card, while the detail data counts the VTs only for the working card. This issue is resolved in Release 4.6.

CSCdz90733

PCA traffic can remain down after restoring the incorrect database and then restoring the correct database to the node. To avoid this issue, exercise care in database restoration. If you accidentally restore the wrong database, first restore the correct database and check to see if all traffic has returned. If PCA traffic is still down, you may need to remove and reinsert a fiber or perform a cross connect card reset. This issue is resolved in Release 4.6.

CSCea13593

DRI configuration rules require limits on multiple drops. However, in an ONS 15454 SDH DRI topology, a unidirectional circuit can be created from one ring to another with two drops at the destination node. This issue is resolved in Release 4.6.

CSCeb20996

While using the orderwire capability of the AIC-I, you must not input a station number with less than 4 digits. If you enter, for example, 123, CTC will display 0123; however, you will not be able to ring the node by dialing either *123, or *0123. This issue is resolved in Release 4.6.

CSCea61887

Terminal loopback is provisionable even if the card is in transponder mode.

To see this, in the provisioning tab for a G1000 or G1K-4 card pick a pair of ports and set them to transpond with each other. The condition also holds true by picking one port and setting it to transpond with itself (one-port unidirectional). Once the transponder setting is provisioned, go to the Maintenance tab and attempt to provision terminal loopback on any of the ports that were previously provisioned for transponder functionality. CTC allows terminal loopback to be provisioned even though the setting has no effect due to the fact that the ports are performing transponder functions. If terminal loopback is truly intended, you should remove the transponder settings. A warning stating that terminal loopback has no effect if transponders are present is displayed in Release 4.6.

CSCea93638

Path level alarms are displayed on the CTC conditions pane for deleted circuits. This issue may occur on any circuit deletion case. The conditions may be cleared by a TCC side switch. This issue is resolved in Release 4.6.

CSCeb24771

A static route may be lost if SOCKS proxy server mode is turned on and then off on the node. If the workstation was communicating with the NE using static routing it will lose connectivity to the NE. If this happens, re-enter the static route. This issue is resolved in Release 4.6.

CSCeb09356

The CTC card level provisioning pane allows a different range of values for the PSC-W, PSC-S, and PSC-R thresholds from the range allowed in the defaults provisioning window. At the CTC card view for an OC-192 card, CTC will allow any values for the PSC-W, PSC-S, and PSC-R. When provisioning these same values using the CTC node view defaults pane, the range is restricted from 0 to 600. This issue is resolved in Release 4.6.

CSCeb35648

A circuit in the AINS state on STM1-8/OC3-8 may transition to IS state even when signals in both directions have alarms. This issue is resolved in Release 4.6.

CSCeb63327

The High Temperature Alarm is raised at 50 degrees Celsius. This is, however, not optimal on an Itemp rated system, which can tolerate up to 65 degrees Celsius. To work around this issue, the alarm can be downgraded or suppressed, but note that this will result in no temperature alarm provided at all. Alternatively, Cisco TAC provides a method of retrieving the temperature from the node, which can thus be monitored periodically for temperature-related problems. This issue is resolved in Release 4.6, and in maintenance Release 4.1.3.

CSCeb84342

Occasionally, after both power sources are removed and plugged in with one power source (Battery A), the node reboots but does not raise PWR-B alarms. To correct this, remove PWR-B and plug it back. This issue is resolved in Releases 4.6 and 4.1.3.

CSCec20521

After addition and deletion of a static route that overlaps with the internal IP addresses range, all cards in the shelf reboot. This can also happen after the node learns a similar route through OSPF or RIP updates. This issue is present in all releases through 4.1 and 4.5. To avoid this issue, do not provision static routes with a destination address in the subnet range 192.168.190.x, and avoid overlap between IP addresses in the network and the internal subnet range 192.168.190.x. If the issue does occur, reset your TCCs. This issue is resolved in Release 4.6 and in maintenance Release 4.1.3.

CSCec16812

UNEQ-V alarms are incorrectly raised prior to connecting a TAP to a TACC, and also after disconnecting the TAP from the TACC. This issue is resolved in Releases 4.1.3 and 4.6.

MS-SPRing Functionality

CSCdy56668 and CSCdy26822

Ethernet circuits may appear in the CTC circuit table with an INCOMPLETE status after an MS-SPRing span is upgraded. The circuits, when this occurs, are not truly incomplete. They are unaffected and continue to carry traffic. To see the circuit status correctly, restart CTC. This issue is resolved in Release 4.6.

CSCdy63060

In a 4 node, two-fiber MS-SPRing configuration, the E100 unstitched circuit state can become stuck at OOS-AINS-PARTIAL, even if there are no alarms and conditions raised.

This issue has been seen under the following conditions:

Step 1 Set up a 4 node, two-fiber MS-SPRing.

Step 2 Provision an E100 point to point circuit starting with the OOS-AINS state and the longer

Step 3 path as the working path. The working path should have at least one pass-through node.

Step 4 Ensure that Ethernet ports and STM-N ports are all in service, no alarms or conditions are raised, and traffic is running clear.

If the state does not change automatically, use the Circuit Edit Window to explicitly set the circuit state to IS. This issue is resolved in Release 4.6.

CSCdz35479

Rarely, CTC Network view can freeze following the deletion or addition of a node from or to a BLSR/MS-SPRing. This can result in the CTC Network view no longer updating correctly. If this occurs, restart CTC. This issue is resolved in Release 4.6.

CSCea02986

In MS-SPRing configurations multiple node deletions and additions on a ring in quick succession can cause PCA traffic to go down. If this occurs, apply a Force Ring switch on the effected nodes. This issue is resolved in Release 4.6.

CSCeb40296

IPPM counts for PCA (extra) traffic will not be displayed in CTC if the MS-SPRing switches back to working after a failure recovery. To see this issue, perform the following steps in a two-fiber or four-fiber MS-SPRing configuration.

Step 1 Create a PCA circuit.

Enable IPPM on all OCn cards for this PCA circuit.

Step 2 Issue a Forced Switch Ring (FS-R) in CTC on the add or drop node. The MS-SPRing switches.

Step 3 View the PCA path level counts shown in CTC.

Step 4 Clear the Forced Switch Ring in CTC. The MS-SPRing switches back to working; however, IPPM path level counts for PCA circuits are not shown.

To recover from this situation, lock out the ring by issuing the LockoutOfProtection (LK-S) command on both east and west for all nodes in the ring. Reboot the OCn card that is not showing PCA path level counts. This procedure needs to be performed whenever there is a switch in MS-SPRing configuration. This issue is resolved in Release 4.6.

SNCP Functionality

CSCea23732

If you try to manually create a VC4 circuit over a three node, STM4 SNCP using automatic routing and a required node, but there is no protected path from the source to the destination excluding the required node, automatic routing will fail to find a path and will raise a "ComputeRouteInMixedDomains: No Route Found" exception. To avoid this issue, you can avoid selecting required nodes, or use manual routing. This issue is resolved in Release 4.6.

CSCec04550

In a SNCP configuration, upon detecting a double-path failure with UNEQ-P, the UNEQ-P on the protect path is not reported. This issue is resolved in Release 4.6.

Performance Monitoring

CSCec63978

The clear button on the PM pane in CTC does not clear PJ detected seconds, PJ generated seconds, or PJ diff. Clearing PMs should result in the associated cell being marked yellow (INVALID) and zero; however, for PJ detected seconds, PJ generated seconds, and PJ diff, the cells remain unchanged.

There is no workaround for PJ seconds. These will continue to accumulate where they left off and not be marked invalid. PJ diff should be marked invalid, but is recalculated to the correct value, and is displayed as such. This issue is resolved in Release 4.6.2.

CSCea38791

In the CTC Performance > Statistics tab of the G1000-4 or G1000-2, there are no entries for Rx/Tx Multicast and Broadcast packets. This issue is resolved in Release 4.6.

New Features and Functionality

This section highlights new features and functionality for Release 4.6.x. For detailed documentation of each of these features, consult the user documentation.

New Hardware

FC_MR-4 Card

The FC_MR-4 (Fibre Channel 4-port) card uses pluggable Gigabit Interface Converters (GBICs) to transport non-SONET/SDH-framed, block-coded protocols over SONET/SDH in virtually concatenated or contiguously concatenated payloads. The FC_MR-4 can transport Fibre Channel over SONET/SDH using Fibre-Channel client interfaces and allows transport of one of the following at a time:

In Software Release 4.6.x, only two of the four ports can be active at one time.

For further specifications of this card, consult the Cisco ONS 15454 SDH Reference Guide, Release 4.6.

10-Gbps Multirate Transponder Card

The Cisco ONS 15454 SDH Multiservice Provisioning Platform (MSPP) support for a 10-Gbps multirate transponder card simplifies the integration and transport of 10 Gigabit Ethernet, OC-192, and STM-64 interfaces and services into enterprises or metropolitan and regional service provider networks. The 10-Gbps multirate transponder card can transport 10 Gigabit Ethernet, SONET OC-192, and SDH STM-64 services over a 100-GHz spaced, 50GHz stabilized, ITU-compliant wavelength. The transponder card is a plug-in module to the Cisco ONS 15454 SDH MSPP, enabling a cost-effective architecture for delivering high-rate 10-Gbps services as well as low-rate services down to 1.5 Mbps. The 10-Gbps transponder card architecture contains a single client interface that is mapped to a single line interface, without accessing the Cisco ONS 15454 SDH shelf cross-connect fabric.

The line interface provides one 10-Gbps, long-reach, ITU-compliant, 100-GHz-spaced optical interface using LC connectors supporting OC-192, STM-64, 10 Gigabit Ethernet LAN PHY, or 10 Gigabit Ethernet WAN PHY interfaces. The DWDM output line interface is tunable across two adjacent 100-GHz wavelengths, enabling support for 32 channel DWDM networks via 16 discrete card types. Using amplification and dispersion compensation, the 10-Gbps transponder card is capable of a 300-km reach. When operated within the outlined specifications each card will transport the 10-Gbps signal with a maximum bit error rate (BER) of 10E-15.

The 10-Gbps transponder card incorporates both a client and DWDM line interface on the same card. The 10-Gbps transponder cards are deployable in the 12 multiservice interface card slots of the Cisco ONS 15454 SDH platform, in systems with or without cross-connect cards. The addition of a cross-connect card enables the platform to support hybrid applications, containing transparent 10-Gbps services as well as aggregation of other services supported by the Cisco ONS 15454 SDH platform. The only required common card is the appropriate timing, communications, and control card.

Each client interface provides a 2.488-Mbps (OC-48/STM-16) SONET/SDH interface via a small-form-factor-pluggable (SFP) optics module with LC connectors, providing the flexibility to support several optical reaches, including short-reach/intra-office, intermediate-reach/short-haul, and long-reach/long-haul, with support for qualified DWDM and DWDM SFP modules. The muxponder card supports any mixture of SFP reach types and also supports in-service insertion or removal without affecting other active ports.

The DWDM line interface provides one 9.95328-Gbps (OC-192/STM-64) or 10.70923-Gbps (OC-192/STM-64 with G.709 digital wrapper enabled), long-reach/long-haul, ITU-compliant, 100-GHz spaced optical interface using LC connectors supporting OC-48/STM-64 interfaces. The DWDM output line interface is tunable across two adjacent 100-GHz wavelengths, reducing inventories for spares. Using amplification and dispersion compensation, the muxponder card is capable of a 300-km reach. When operated within the outlined specifications, each card will transport the 10-Gbps signal with a maximum bit error rate (BER) of 10E-15.

The muxponder card incorporates the four clients and one DWDM line interface on the same card. The muxponder cards are deployable in the 12 multiservice interface card slots of the Cisco ONS 15454 SDH platform, in systems with or without cross-connect cards. The addition of a cross-connect card enables the platform to support hybrid applications, containing transparent 2.5-Gbps services as well as aggregation of the other services supported by the Cisco ONS 15454 SDH platform. The only other common card required for operation is the timing, communications, and control (TCC2) card. The muxponder card provides many carrier-class features and capabilities necessary to deliver 2.5-Gbps services, including selectable protocol transparency, wavelength tunability, flexible protection mechanisms, flexible timing options, and management capabilities.

For further specifications of this card, consult the Cisco ONS 15454 SDH Reference Manual, Release 4.6.

New Software Features and Functionality

DWDM and TDM Hybrid Node Support

Hybrid Nodes Overview

A hybrid node running Release 4.6.x allows TDM cards and DWDM cards to be used in the same node, and is limited primarily by the slots available to the node. Hybrid functionality combines the abilities of nodes running software prior to Release 4.5 (in terms of tributary add/drop traffic including SONET, SDH, and Ethernet incorporated into linear, ring, and PPMN topologies) with the Release 4.5 DWDM functionality, supporting additional hybrid node types, in open ring, closed ring, and linear configurations.

DWDM and TDM Hybrid Node Types

The node type in a network configuration is determined by the type of card that is installed in an ONS 15454 SDH hybrid node. The ONS 15454 SDH supports the following hybrid DWDM and TDM node types.

1+1 Protected Flexible Terminal Node

The 1+1 protected flexible terminal node is a single ONS 15454 SDH node equipped with a series of OADM cards acting as a hub node configuration. This configuration uses a single hub or OADM node connected directly to the far-end hub or OADM node through four fiber links. This node type is used in a ring configured with two point-to-point links. The advantage of the 1+1 protected flexible terminal node configuration is that it provides path redundancy for 1+1 protected TDM networks (two transmit paths and two receive paths) using half of the DWDM equipment that is usually required.

Scalable Terminal Node

The scalable terminal node is a single ONS 15454 SDH node equipped with a series of OADM cards and amplifier cards. This node type is more cost effective if a maximum of 16 channels are used. This node type does not support a terminal configuration exceeding 16 channels because the 32-channel terminal site is more cost effective for 17 channels and beyond.

The OADM cards that can be used in this type of node are: AD-1C-xx.x, AD-2C-xx.x, AD-4C-xx.x, and AD-1B-xx.x. You can also use AD-4B-xx.x and up to four 4MD-xx.x cards. The OPT-PRE and/or OPT-BST amplifiers can be used. The OPT-PRE or OPT-BST configuration depends on the node loss and the span loss. When the OPT-BST is not installed, the OSC-CSM must be used instead of the OSCM card.

Hybrid Terminal Node

A hybrid terminal node is a single ONS 15454 SDH node equipped with at least one 32 MUX-O card, one 32 DMX-O card, two TCC2 cards, and TDM cards. If the node is equipped with OPT-PRE or OPT-BST amplifiers, it is considered an amplified terminal node. The node becomes passive if the amplifiers are removed. The hybrid terminal node type is based on the DWDM terminal node type (see the Cisco ONS 15454 SDH Reference Manual, R4.6).

Hybrid OADM Node

A hybrid OADM node is a single ONS 15454 SDH node equipped with at least one AD-xC-xx.x card or one AD-xB-xx.x card, and two TCC2 cards. The hybrid OADM node type is based on the DWDM OADM node type (see the Cisco ONS 15454 SDH Reference Manual, R4.6). TDM cards can be installed in any available slot.

Hybrid Line Amplifier Node

A hybrid line amplifier node is a single ONS 15454 SDH node with open slots for both TDM and DWDM cards.

The client cards that can be used in an amplified TDM node are: TXP_MR_10G, MXP_2.5G_10G, TXP_MR_2.5G, TXPP_MR_2.5G,

OC-192 LR/STM 64 ITU 15xx.xx, and OC-48 ELR/STM 16 EH 100 GHz.

Support for Hybrid Networks

The hybrid network configuration is determined by the type of node that is used in an ONS 15454 SDH network. Along with TDM nodes, the ONS 15454 SDH supports the following hybrid node types: 1+1 protected flexible terminal, scalable terminal, hybrid terminal, hybrid OADM, hybrid line amplifier, and amplified TDM. For examples and details of hybrid network types, see the Cisco ONS 15454 SDH Reference Manual, R4.6.

FC_MR-4 Fiber Channel Card Support

The FC_MR-4 card reliably transports carrier-class, private-line Fibre Channel/FICON transport service. Each FC_MR-4 card can support up to two 1-Gbps circuits or a single 2-Gbps circuit. A 1-Gbps circuit is mapped to an STS-24c/VC4-8c (STS-3c-8v) and 2-Gbps circuits are mapped to an STS-48c/VC4-24c. The FC_MR-4 card incorporates features optimized for carrier-class applications such as:

The FC_MR-4 payloads can be transported over the following protected circuit types, in addition to unprotected circuits:

•SNCP (CCAT circuits only)

•Path-protected mesh network (PPMN)

•MS-SPRing

•Protection channel access (PCA)

The FC_MR-4 card supports high-order virtual concatenation (VCAT).

The FC_MR-4 uses pluggable GBICs for client interfaces and is compatible with the following GBIC types:

•ONS-GX-2FC-SML= (2Gb FC 1310nm Single mode with SC connectors)

•ONS-GX-2FC-MMI= (2Gb FC 850nm Multi mode with SC connectors)

Security Enhancements

The following security enhancements are added or updated in Release 4.6.x. For specific details on these enhancements, consult the Cisco ONS 15454 SDH Reference Manual, Release 4.6.

•Prevent password toggling

•Prevent account changes to logged in user

•Forced password change on next login

•Forced password change on first login

•Password aging

•Prevent password flipping

•LAN access security

•Disable inactive user

New Default Superuser Password

As of Release 4.6 the default password for a superuser when you first log onto a new node is changed. The new default is "otbu+1" consistently across all ONS 15454, ONS 15454 SDH, ONS 15600, and ONS 15327 platforms. This change does not affect users upgrading from a previous release, who will continue to use the password they have selected that is stored in their previous release's database.

GNE Load Balancing

Automatic Laser Shutdown

Automatic Laser Shutdown (ALS) is a technique used to automatically shut down the output power of the transmitter in case of fiber break according to ITU-T G.664. If ALS is enabled, after at least 500 ms of continuous presence of an LOS defect, the transmitter is shut down. Once the ALS is engaged, a laser pulse is sent from the transmitter periodically in case of auto mode; or a single pulse is sent in case of manual mode for recovering from the fiber break.

Optical interfaces of ONS 15454 and ONS 15454 SDH support ALS, but due to hardware limitations of current optical cards, only OC192/STM64, OC48/STM16-ELR, and OC3/STM1-8 support the ALS feature.

The pulse recovery interval time for automatic restart is configurable within 60s and 300s. The default is 100s. The laser pulse recovery width is within 2s and 10s. This is to ensure proper operation of the ALS when connecting into long haul WDM systems. In some cases a pulse width of 2s is insufficient to consistently turn on all of the lasers in a given transmission path. In case of "manual restart for test" the pulse recovery width is 100s.

ALS is disabled by default in both the SONET and SDH implementations. The ALS can be disabled on each optical interface individually.

Configuration Management for Automatic Laser Shutdown

Release 4.6.x allows you to configure the following options on ALS for optical cards on a per port basis.

•Disabled

•Auto restart

•Manual restart

•Manual restart for test

Release 4.6.x allows you to configure the pulse recovery width between 2s and 10s, and the pulse recovery interval between 60s and 300s. The default values are set to 2s and 100s correspondingly on a per port basis.

Release 4.6.x allows you to send a restart command when manual restart or manual restart for test is chosen and ALS is engaged on a per optical card port basis.

DCC Capacity, Management, and Tunneling

With Release 4.6.x the TCC2 supports up to 68 SDCC or 28 LDCC terminations. The TCC2 supports mapping of any available SDCC to a GCC, up to the maximum SDCC count supported by the NE.

Note In practice, the maximum number of GCCs supported by the TCC2 is limited by the port density of G.709 cards.

Any optical port can be provisioned to use either SDCC or LDCC termination, with the exception of 4-port OC-3, which only supports SDCC.

SDCC and LDCC termination can coexist on the same fiber, in which case there is only one link created in the topology.

The TCC2 supports provisioning of two types of DCC tunnel, hardware transparent and IP encapsulated. IP encapsulated is only supported for SDCC tunnel.

The TCC2 supports up to 68 DCC tunnels to carry foreign DCC traffic.

The TCC2 supports up to 10 IP encapsulated SDCC tunnels.

If an ONS node is acting as a hub node that interconnects with third party nodes in a path protection, and two tunnels are provisioned on the two path protection links, one ONS node can have 10/2 = 5 path protection rings.

Cisco recommends the total number of IP encapsulated tunnels in a DCC network be 64; however, this recommendation is not enforced by the NMS.

The number of path protections supported is the maximum supported DCC terminations, divided by 2.

CTC Support

CTC supports provisioning of up to 68 SDCC terminations and 28 LDCC terminations per node.

CTC defaults the OSPF metric of an SDCC termination link to 100, and LDCC to 33.

CTC allows HDLC CRC provisioning for SDCC/LDCC termination to either 16-bit or 32-bit. For SDCC, the default is 32-bit; for LDCC, the default is 16-bit.

CTC issues a warning if both SDCC and LDCC are provisioned on the same port.

CTC supports provisioning of up to 68 DCC tunnels and 10 IP encapsulated tunnels per node.

CTC supports both transparent and IP encapsulated DCC tunnels. When creating a new tunnel you have the option of selecting whether to create a traditional (transparent) or IP encapsulated tunnel. You are prompted to pick the two end points and then the provisioning will be done on each end point node, and nodes along the path for the transparent tunnel. For the IP encapsulated tunnel, CTC supports provisioning of the throttling threshold, with 100% as the default. It is also possible to provision the maximum bandwidth of the IP encapsulated tunnel.

If you have an SDCC tunnel between Node A and Node B, CTC allows you to select the tunnel and select to upgrade from transparent to IP encapsulated. CTC deletes the existing tunnel and create the terminations at the two end points for the IP encapsulated tunnel. Only tunnels that are in ACTIVE state are upgraded in this way. INCOMPLETE tunnels have the upgrade option disabled. You can also choose to manually delete the existing tunnel and then create an IP-encapsulated tunnel.

Alarms

With Release 4.6.x an LDCC failure alarm is raised when an LDCC termination fails.

Legacy DCC Tunneling Support

With Release 4.6.x you can select either Legacy DCC Tunneling or Encapsulated Tunneling as currently supported by your ONS system.

Go-and-Return SNCP Routing

The go-and-return SNCP routing option allows you to route the SNCP working path on one fiber pair and the protect path on a separate fiber pair. The working path will always be the shortest path. If a fault occurs, neither the working nor the protection fibers are affected. This feature only applies to bidirectional SNCP circuits. The go-and-return option appears on the Circuit Attributes panel of the Circuit Creation wizard.

MS-SPRing Enhancements

MS-SPRing Maximum Ring Support

Release 4.6.x MS-SPRing supports a maximum of five rings per node, with maximums of five two-fiber, and one four-fiber ring per node.

MS-SPRing 6 Character Ring ID

The name can be from 1 to 6 characters in length. Any alphanumeric string is permissible, and upper and lower case letters can be combined. Do not use the character string "All" in either upper or lower case letters, this is a TL1 keyword and will be rejected. Do not choose a name that is already assigned to another MS-SPRing.

The statistics window lists parameters at the line level. The Statistics window provides buttons to change the statistical values shown. The Baseline button resets the displayed statistics values to zero. The Refresh button manually refreshes statistics. Auto-Refresh sets a time interval at which automatic refresh occurs. The Statistics window also has a Clear button. The Clear button sets the values on the card to zero. All counters on the card are cleared. For specific parameters see the Cisco ONS 15454 SDH Reference Manual, R4.6.

FC_MR-4 Utilization Window

The Utilization window shows the percentage of Tx and Rx line bandwidth used by the ports during consecutive time segments. The Utilization window provides an Interval menu that enables you to set time intervals of 1 minute, 15 minutes, 1 hour, and 1 day.

FC_MR-4 History Window

The History window lists past FC_MR-4 statistics for the previous time intervals. Depending on the selected time interval, the History window displays the statistics for each port for the number of previous time intervals.

Alarms Window

Path Width Column

In alarm windows, the display now includes a column called "Path Width"

that indicates how many STSs are contained in the alarmed path.

CTC Enhanced Alarm Severity Profiles

Card and Node View

With Release 4.6.x the profile name is more detailed for inherited profiles. Instead of "Inherited," the name now offers descriptive information that gives you a better idea of where the severity values are derived from. For example, the name might say "Inherited from Node profile."

Alarm Profile Editor in Card and Node Views

The "Alarm Profile Editor" tab has been added. You can create, download, clone, or delete alarm severity profiles now from the card view or node view in addition to the traditionally available network view capability.

Alarm Profile Editor, All Levels

The term "UNSET" has been replaced with "Use Default" to clarify where the severity value comes from.

If there is only one profile loaded, the store button is available and will autoselect that profile even if it is not selected.

Buttons have a horizontal layout.

There is a new check box option, "Only Show service-affecting severities." If checked this box does as the description says. If unchecked, each cell shows the service-affecting/non-service-affecting severities, if applicable. For example, if a cell contains a Major severity, checking the box will show "MJ," and unchecking the box will show "MJ/MN."

Permanent profiles (for example, "Default" and "Inherited") are not editable until the name is changed to a non-permanent-profile name.

Spanning Tree EtherBridge Circuits Window

Release 4.6.x allows you to manage spanning tree information more easily by providing the EtherBridge Circuits window. To see the window, in node view, click the Maintenance > EtherBridge > Circuits tabs.

In the EtherBridge Circuits window you can view the following information:

•Type—Identifies the type of Ethernet circuit mapped to the spanning tree, such as EtherSwitch point-to-point.

•Circuit Name/Port—Identifies the circuit name for the circuit in the spanning tree. This column also lists the Ethernet slots and ports mapped to the spanning tree for the node.

•STP ID—Shows the spanning tree protocol ID number.

•VLANS—Lists the VLANs associated with the circuit or port.

Context-Sensitive Help

With Release 4.6.x you can access context-sensitive help from any CTC window, dialog box, or wizard, affording you "What's this?" level information about CTC fields and table columns at the network, node, and card views.

Configurable Superuser Clear PM

On a configurable basis, where the current system behavior is the default, a superuser can configure the security level required to clear PMs. The ability to baseline PM remains unchanged. You can configure this feature in NE defaults.

PID/VID Visibility

With Release 4.6.x CTC, TL1, SNMP, and the interface to CTM display the PID/VID information programmed into all components with PID/VIDs.

This applies to all platforms where PID/VID is stored on the components.

Release 4.6.x supports setting the PID/VID in the factory.

Proxy ARP Enhancement

Release 4.6.x enhances the ARP proxy function to perform proxy ARP for all target addresses in the system's routing table (not just for the DCC connected devices).

SNMP GNE Proxy

With Release 4.6.x the TCC2 adds SNMP proxy capability for SNMP GET/SET commands and the responses to/from the ENE. The SNMP manager specifies the ENE address in the SNMP PDU, similar to the addressing for a shelf slot (for example, <GNE-community-string>{ENE-Address, ENE-community-string}).

K2 Bits Alarm Notification on 1+1 APS

With Release 4.6.x, K2 bits alarm notification on 1+1 APS supports uniform APS settings across your network. In the case, for example, where one ONS 15454/ONS 15454 SDH node is configured to have 1+1 APS protection on the OC-12 cards in Slots 1 and 2, and Slot 1 is connected to Slot 1 of another node that does not have APS 1+1 configured, an alarm will be raised to alert you to the incomplete provisioning.

Alarming on Duplicate Node IDs

A minor, non-service affecting (MN, NSA) alarm is raised if duplicate node names are detected when two nodes are in the same DCC area. The alarm clears when the duplicate node name is changed or the DCC link is broken.

Alarm on Firewall Turned Off

Release 4.6.x raises a transient condition when the firewall feature (proxy) is disabled after having been enabled.

Rear Panel Ethernet Connection Detach Alarm

The rear panel Ethernet connection detach alarm, when raised, indicates that the backplane LAN connection has been disconnected from a GNE. This allows detection of anyone trying to use the connection to access a corporate DCN.

•The alarm clears under the following conditions:

•The backplane LAN connection is connected or reconnected.

•The node is set to be an ENE

Note This has impacts on proxy/firewall, as well.

•The NE default parameter for this option is set to "off" (by a superuser only).

Port Status via Front Panel LCD

Release 4.6.x introduces an enhancement to the fan tray LCD display/controls to increase visibility to the status of various ports on the NE. Prior to Release 4.6, a craft person local to the node could not determine which tributary OC-x port card was carrying traffic in a protection group. This enhancement will now allow a craft person determine which OC-x port cards are carrying traffic without having to log into CTC.

With Release 4.6.x, using the fan tray LCD buttons, you can drill down to specific slots and ports to display:

•The working/protect provisioned status of the OC-x port in a 1+1 or a 2F/4F MS-SPRing configuration.

•The current active/standby line status of the OC-x port in a 1+1 or a 2F/4F MS-SPRing configuration.

IP Tunnel Throttle Capability

An IP tunnel that will tunnel traffic from foreign nodes in the form of UDP-i packets can flood the network. With Release 4.6.x you can throttle these tunnels. You can set the throttle bandwidth percentage in a text field labeled Max Bandwidth when you create an IP tunnel using the wizard. Once an IP Tunnel is created you can also edit the tunnel and set the throttle bandwidth. Alternatively, when you are changing an IP Tunnel from SDCC (traditional) to IP Encapsulated, you can set the throttle bandwidth at that time.

ML-Series

VCAT

VCAT significantly improves the efficiency of data transport by grouping the synchronous payload envelopes (SPEs) of SONET/SDH frames in a nonconsecutive manner into VCAT groups. VCAT group circuit bandwidth is divided into smaller circuits called VCAT members. The individual members act as independent circuits. Intermediate nodes treat the VCAT members as normal circuits that are independently routed and protected by the SONET/SDH network. At the terminating nodes, these member circuits are multiplexed into a contiguous stream of data. VCAT avoids the SONET/SDH bandwidth fragmentation problem and allows finer granularity for provisioning of bandwidth services.

Note ML-Series cards purchased prior to Software Release 4.6 need to have the FPGA image upgraded to support the 4.6.x VCAT circuit feature. If a non-upgraded ML-Series card is used with Software Release 4.6.x, non-VCAT features will function normally, but a message will appear in the Cisco IOS CLI warning the user that the VCAT feature will not function with the current FPGA image. An upgraded FPGA image is compatible with all earlier versions of ML-Series card IOS software. Customers should contact TAC for instructions on performing the FPGA image upgrade.

SW-LCAS

LCAS increases VCAT flexibility by allowing the dynamic reconfiguration of VCAT groups without interrupting the operation of non-involved members. SW-LCAS is the software implementation of a LCAS-type feature. SW-LCAS differs from LCAS because it is not errorless and uses a different handshaking mechanism. SW-LCAS on the ML-Series card allows the automatic addition or removal of a VCAT group member in the event of a failure or recovery on two-fiber MS-SPRing. The protection mechanism software operates based on ML-Series card link events. SW-LCAS allows service providers to configure VCAT member circuits on the ML-Series as protection channel access (PCA). This PCA traffic is dropped in the event of a protection switch, but is suitable for excess or noncommitted traffic and can double total available bandwidth on the circuit.

Microcode Image Enhancements

With Release 4.6.x you can choose from three microcode images for the ML-Series card. The default basic image has the same ML-Series base functionality as the Software Release 4.1 IOS image, Cisco IOS Release 12.1(19)EO, plus some additional non-microcode dependant R4.6.x features, such as the ML-Series virtual concatenation (VCAT) circuits. The basic image also allows users to upgrade from Software R4.0 or R4.1 to Software R4.6.x without changing the existing configurations on ML-Series cards.

Enhanced Performance Monitoring

Enhanced performance monitoring displays per-CoS packet statistics on the ML-Series card interfaces when CoS accounting is enabled. Per-CoS packet statistics are only supported for bridged services, not IP routing or MPLS. CoS-based traffic utilization is displayed at the FastEthernet or GigabitEthernet interface or subinterface (VLAN) level or the POS interface level but not at the POS subinterface level. RPR statistics are not available at the SPR interface level, but statistics are available for the individual POS ports that make up the SPR interface. EtherChannel (port-channel) and BVI statistics are available only at the member port level.

Combination VLAN-transparent Services and One or More VLAN-specific Services

In Software Release 4.6 and later, the ML-Series card supports combining VLAN-transparent services and one or more VLAN-specific services on the same port. All of these VLAN-transparent and VLAN-specific services can be point-to-point or multipoint-to-multipoint. This allows a service provider to combine a VLAN-transparent service, such as IEE 802.1Q tunneling (QinQ), with VLAN-specific services, such as bridging specific VLANs, on the same customer port. For example, one customer VLAN can connect to Internet access and the other customer VLANs can be tunneled over a single provider VLAN to another customer site, all over a single port at each site. VLAN-transparent service is also referred to as Ethernet Wire Service (EWS). VLAN-specific service is also referred to as Ethernet Relay Multipoint Service (ERMS).

Ethernet-over-MPLS (EoMPLS) Tunneling

EoMPLS provides Ethernet services across the MPLS backbone and core network. The ML series EoMPLS microcode image supports both VLAN and Port based point to point Ethernet tunnels across the MPLS network. The ML series EoMPLS feature enables Ethernet service delivery on the access SONET/SDH network over the RPR and transport that service across the core MPLS network without the need to create a separate bridged access network.

MST Protocol Tunneling

Release 4.6.x MST Protocol Tunneling allows Multi-Spanning-Tree on an external bridge to be used to enable a redundant pair of ML-series cards without requiring a spanning-tree instance per VLAN.

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.

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.

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 We encourage you to use Pretty Good Privacy (PGP) or a compatible product to encrypt any sensitive information that you send to Cisco. PSIRT can work from encrypted information that is compatible with PGP versions 2.x through 8.x.

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:

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:

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:

Note Use the Cisco Product Identification (CPI) tool to locate your product serial number before submitting a web or phone request for service. You can access the CPI tool from the Cisco Technical Support Website by clicking the Tools & Resources link under Documentation & Tools.Choose Cisco Product Identification Tool from the Alphabetical Index drop-down list, or click the Cisco Product Identification Tool link under Alerts & RMAs. The CPI tool offers three search options: by product ID or model name; by tree view; or for certain products, by copying and pasting show command output. Search results show an illustration of your product with the serial number label location highlighted. Locate the serial number label on your product and record the information before placing a service call.

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:

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:

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.

•Cisco Marketplace provides a variety of Cisco books, reference guides, and logo merchandise. Visit Cisco Marketplace, the company store, at this URL:

•Cisco Press publishes a wide range of general networking, training and certification titles. Both new and experienced users will benefit from these publications. For current Cisco Press titles and other information, go to Cisco Press at this URL:

•Packet magazine is the Cisco Systems technical user magazine for maximizing Internet and networking investments. Each quarter, Packet delivers coverage of the latest industry trends, technology breakthroughs, and Cisco products and solutions, as well as network deployment and troubleshooting tips, configuration examples, customer case studies, certification and training information, and links to scores of in-depth online resources. You can access Packet magazine at this URL:

•iQ Magazine is the quarterly publication from Cisco Systems designed to help growing companies learn how they can use technology to increase revenue, streamline their business, and expand services. The publication identifies the challenges facing these companies and the technologies to help solve them, using real-world case studies and business strategies to help readers make sound technology investment decisions. You can access iQ Magazine at this URL:

•Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private internets and intranets. You can access the Internet Protocol Journal at this URL: