 Feedback
|
Table Of Contents
Release Notes for Cisco ONS 15327
Release 5.0.6Maintenance and Administration
Resolved Software Caveats for Release 5.0.6
Maintenance and Administration
Common Control and Cross Connect Cards
New Features and Functionality
New Software Features and Functionality
Additional Support for In Service Topology Upgrades
State Verification Scan Before Activation
Linear Port-Mapped Ethernet Mode (8-port 10/100 Ethernet Linear Mapper)
High Level Functional Differences
Obtaining Technical Assistance
Contacting TAC by Using the Cisco TAC Website
Release Notes for Cisco ONS 15327
Release 5.0.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 15327 SONET. For detailed information regarding features, capabilities, hardware, and software introduced with this release, refer to Release 5.0 of the Cisco ONS 15327 Procedure Guide, Cisco ONS 15327 Reference Manual, Cisco ONS SONET TL1 Command Guide, and Cisco ONS 15327 Troubleshooting Guide. For the most current version of the Release Notes for Cisco ONS 15327 Release 5.0.6, visit the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/ong/15327/rnotes/index.htm
Cisco also provides Bug Toolkit, a web resource for tracking defects. To access Bug Toolkit, visit the following URL:
http://www.cisco.com/cgi-bin/Support/Bugtool/launch_bugtool.pl
Contents
Resolved Software Caveats for Release 5.0.6
New Features and Functionality
Obtaining Technical Assistance
Changes to the Release Notes
This section documents supplemental changes that have been added to the Release Notes for Cisco ONS 15327 Release 5.0.6 since the production of the Cisco ONS 15327 System Software CD for Release 5.0.6.
No changes have been added to the release notes for Release 5.0.6.
Caveats
Review the notes listed below before deploying the ONS 15327. 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.
Maintenance and Administration
Caution
Note
DDTS # CSCed24448
After a static route is provisioned to 0.0.0.0 and then deleted, the default route disappears. If this occurs, reprovision the default gateway. This issue will be resolved in a future release.
DDTS # CSCee65731
An ONS 15327 that does not have an SNTP server reference resets the time to Jan. 1, 1970 during a software activation. A routine common control switchover does not cause the node to lose the time setting. To avoid this issue provision a SNTP server reference. This issue cannot be resolved.
DDTS # CSCdy10030
CVs are not positively adjusted after exiting a UAS state. When a transition has been made from counting UAS, at least 10 seconds of non-SES must be counted to exit UAS. When this event occurs, Telcordia GR-253 specifies that CVs that occurred during this time be counted, but they are not. There are no plans to resolve this issue at this time.
DDTS # CSCdy49608
A node connection might fail during bulk circuit creation, causing the circuit creation to also fail. For example, this has been seen while creating 224 VT 1.5 protected circuits, on a path protection consisting of eight ONS 15327 nodes. If you experience a bulk circuit creation failure of this type, cancel the circuit creation batch, then delete any incomplete circuits. Restart the batch from the last successful circuit. This issue will not be resolved.
DDTS # CSCdx35561
CTC is unable to communicate with an ONS 15327 that is connected via an Ethernet craft port. CTC does, however, communicate over an SDCC link with an ONS 15327 that is Ethernet connected, yielding a slow connection. This situation occurs when multiple ONS 15327s are on a single Ethernet segment and the nodes have different values for any of the following features:
•
•
•
When any of these features are enabled, the proxy ARP service on the node is also disabled. The ONS 15327 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 15327s.
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 15327 nodes. This will disconnect them for the purposes of the proxy ARP service and the nodes should become directly accessible over the Ethernet. Network settings on the nodes can then be provisioned as desired, after which the SDCC can be restored.
This issue will not be resolved.
DDTS # CSCdy11012
When the topology host is connected to multiple OSPF areas, but CTC is launched on a node that is connected to fewer areas, the topology host appears in CTC, and all nodes appear in the network view, but some nodes remain disconnected. This can occur when the CTC host does not have routing information to connect to the disconnected nodes. (This can happen, for example, if automatic host detection was used to connect the CTC workstation to the initial node.)
CTC will be able to contact the topology host to learn about all the nodes in all the OSPF areas, but will be unable to contact any nodes that are not in the OSPF areas used by the launch node. Therefore, some nodes will remain disconnected in the CTC network view.
To work around this issue, if no firewall enabled, then the network configuration of the CTC host can be changed to allow CTC to see all nodes in the network. The launch node must be on its own subnet to prevent network partitioning, and craft access must not be enabled. The CTC host must be provisioned with an address on the same subnet as the initial node (but this address must not conflict with any other node in the network), and with the default gateway of the initial node. CTC will now be able to contact all nodes in the network.
If a firewall is enabled on any node in the network, then CTC will be unable to contact nodes outside of the initial OSPF areas. This issue will not be resolved.
DDTS # CSCdy37198
On Cisco ONS 15327 platforms equipped with XTC cross-connect cards, Ethernet traffic may be lost during a BLSR protection switch, with no accompanying alarm or condition raised. Possible affected circuits will be between Ethernet cards (E100T-4) built over Protection Channel Access (PCA) bandwidth on BLSR spans. When BLSR issues the switch, the PCA bandwidth is preempted. Since there is no longer a connection between the ends of the Ethernet circuit, traffic is lost. Further, in nodes equipped with XTC cards, the E100T-4 cards do not raise an alarm or condition in CTC. This issue will not be resolved.
DDTS # CSCds23552
You cannot delete the standby XTC once it is removed. If you have two XTC cards and then decide to operate with only one, you will get a standing minor alarm. The alarm cannot be removed by CTC. The XTC is a combo card, combining the functionality of the ONS 15454 TCC2, cross connect, DS1 and DS3 cards, with a protection group automatically provisioned. On the ONS 15454, similar behavior occurs for the TCC2 card. The cross connect card for the ONS 15454 can only be deleted if there are no circuits provisioned. DS1 and DS3 cards can only be deleted if they are not in a protection group. User-defined alarm profiles in Release 5.0.x allow you to mask the improper removal alarm from the standby XTC slot without masking any other items if desired, thus avoiding this issue. This issue will not be resolved.
Data IO Cards
DDTS # CSCdy41135
When using a G1000-2 card, TIM-P can be mistakenly raised on a PCA circuit after a protection switch. This occurs when path trace is enabled on a PCA circuit that is no longer in use after a protection switch. To work around this issue, either disable path trace or use alarm profiling to filter out the unwanted alarm. This issue will not be resolved.
DDTS # CSCdy13035
Excessive Ethernet traffic loss (greater than 60 ms) may occur when the active XTC is removed from the chassis while using the G1000-2. On rare occasions, permanent loss of traffic may occur. Do not remove the active XTC from the chassis to force a protection switch. Instead, perform a soft reset of the active XTC through the network management interface. Once the XTC is in standby mode, it can be removed from the chassis without inducing excessive traffic loss. This issue is resolved by ECO# E074040, which incorporates improved hardware PLL circuitry on the G1000-2 line card to allow an active XTC removal without causing excessive traffic loss. The caveat herein is for the previous hardware version.
Path Protection Functionality
DDTS # CSCee53579
Traffic hits can occur in an unprotected to path protection topology upgrade in unidirectional routing. If you create an unprotected circuit, then upgrade the unprotected circuit to a path protection circuit using Unprotected to UPSR wizard, selecting unidirectional routing in the wizard, the circuit will be upgraded to a path protection circuit. However, during the conversion, traffic hits on the order of 300 ms should be expected. This issue will be resolved in a future release.
DDTS # CSCec15064
A path protection/SNCP circuit with a defect signal present (for example, AIS-P or AIS-V) on the protect path will produce RDI-P or RDI-V upstream of the detection point, but these signals will not be detected or indicated. This issue will be resolved in a future release.
DDTS # CSCeb37707
With a VT path protection 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.
Performance Monitoring
DDTS # CSCdt10886
The far-end STS PM counts do not accumulate on an OC-48 linear 1+1 circuit even though the near-end STS PM counts on the other end are increasing. To see this issue, connect two nodes with an OC-12 or OC-48 linear 1+1 protected span. Place a piece of test equipment in the middle of the span and inject B3 errors. The near-end STS PM counts accumulate, but the far-end STS PM counts do not accumulate. To work around this issue, Use the near-end STS PM count from the adjacent node to see the far-end STS PM count for the current node. This issue will be resolved in a future release.
TL1
Note
Resolved Software Caveats for Release 5.0.6
The following items are resolved in Release 5.0.x.
Maintenance and Administration
DDTS # CSCdy71653
A change of the alarm profile while alarms are present on a DS3 card is not correctly applied. The behavior is specific to DS3 ports on an ONS 15327 node. This issue is resolved in Release 5.0.
DDTS # CSCed13967
If you toggle CTC shell access mode from telnet to ssh while a telnet session is active, then attempt to login via ssh, the XTC locks up and eventually reboots. To avoid this issue, do not toggle shell access when the shell is already engaged. This issue is resolved in Release 5.0.
DDTS # CSCec17281
When the "Status" field for a circuit in the circuit table shows "INCOMPLETE," this can be interpreted as an alarm or traffic-affecting condition on the circuit. On path protection and BLSR 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 BLSR 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. This issue is resolved in Release 5.0. The circuit Status is defined clearly in the Release 5.0 user documentation.
DDTS # 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.
Common Control and Cross Connect Cards
DDTS # CSCei01183
If near line rate traffic is addressed at a TCC+ or XTC shelf controller, so much CPU will be devoted to reading packets off the line that the card will intentionally reset itself. The time to reset will vary from minutes to hours depending on the Ethernet bus traffic load. If this issue occurs, you will see the node in CTC go gray, and the TCC+ or XTC reset. This failure has been reproduced by connecting an Ethernet switch to the working and protect shelf controllers and turning spanning tree off on the switch. Any broadcast traffic received in such a configuration will loop infinitely. This issue is resolved in maintenance Releases 4.0.4, 5.0.4 and later.
DDTS # CSCei16460
A common control card reset can occur under the following three conditions.
1.
2.
3.
This issue has been only seen in Release 5.0.2. To avoid this issue, disable OSPF on the LAN. This issue is resolved in Releases 5.0.4 and 5.0.5.
Data IO Cards
DDTS # CSCdy47038
G1000-2 path alarm profiles applied on port 2 are not updated to reflect the correct alarm severities. This issue is resolved in Release 5.0.
BLSR Functionality
DDTS # CSCdw66416
Traffic along a running ring segment cannot be restored while a participating node is rebooting. To see this problem, in a two fiber BLSR with circuits created along a given ring segment, you must isolate that ring segment by powering down two or more nodes where one of the nodes powered down is at the edge of the segment and the others are outside of the segment. Then power up and reboot the node at the edge of the segment. The circuits along this segment will not be restored even though the nodes on the segment are both up and running. You must restore power to all nodes before the traffic is restored. This issue is resolved in Release 5.0.
Performance Monitoring
DDTS # CSCeg62711
On DS1/E1 cards, PM TCAs fail to appear, or appear against a lower port number than expected. This issue is resolved in Release 5.0.2.
TL1 Functionality
DDTS # CSCeg87471
Do not set the TID for an ENE to more than 19 characters. Setting the TID for an ENE to 20 characters or more and then issuing a TL1 command on the GNE to execute on the ENE will result in TL1 agent connectivity issues on the ENE. Specifically, if you set the TID on the ENE to 20 characters, reboot the TCC, then try to connect to that ENE from a GNE this will result in a loss of TL1 connectivity to the GNE. This issue is resolved in Release 5.0.2.
DDTS # CSCec54538
The TL1 INIT-REG-OCn command doesn't work with OC48-IR cards. To work around this you can use OC-48 cards or use the Clear command. This issue is resolved in Release 5.0.
DDTS # CSCdz26071
The TL1 COPY-RFILE command, used for SW download, database backup, and database restore, currently does not allow a user-selected port parameter to make connections to the host. The command expects the default parameter of Port 21 and will only allow that number. This issue is resolved in Release 5.0
New Features and Functionality
This section highlights new features and functionality for Release 5.0.x. For detailed documentation of each of these features, consult the user documentation.
New Software Features and Functionality
In-Service Topology Upgrades
In Release 5.0.x in-service topology upgrades are supported for unprotected to path protection, terminal to linear (add a node to a 1+1), and path protection to 2F-BLSR. Release 5.0.x provides both manual methods and CTC wizards for completing these upgrades.
Note
CTC Topology Upgrade Wizards
The following CTC topology upgrade wizards have been added for Release 5.0.x to support in service topology upgrades.
Unprotected to Path Protection
With this feature you can convert an unprotected circuit to path protection, or you can convert unprotected segments of a partially protected circuit to path protection.
Path Protection to Two Fiber BLSR
This feature creates a two fiber BLSR and converts all path protection circuits on the selected ring to BLSR circuits.
Terminal to Linear—Add a Node to 1+1
The wizard for this feature is invoked by right-clicking on a 1+1 link and then selecting the "terminal to linear" option. The option adds a node between a two nodes connected by a 1+1.
Additional Support for In Service Topology Upgrades
Circuit Routing
With Release 5.0.x you can choose between manually or automatically routing path protection circuits for a topology upgrade.
The following circuit types are supported for topology upgrades.
•
•
•
•
•
•
Circuit Merge and Reconfigure
The circuit merge and reconfigure features enable you to merge selected CTC or TL1 circuits into one or more discovered CTC circuits based on the alignment of the circuit cross-connects, rather than the circuit ID.
Circuit Merge merges m circuits into one circuit. This feature takes one master circuit and merges aligned circuits with the master.
Circuit Reconfigure merges m circuits into n circuits. This feature takes m circuits and reconfigures them based on cross-connect alignment. To merge circuits choose the Merge subtab of the Edit Circuits tab in CTC. To merge circuits choose the Merge subtab of the Edit Circuits tab in CTC. To reconfigure circuits, choose the CTC Tools > Circuits tab, and select "Reconfigure Circuits..."
Dual-ring Interconnect
Dual-ring interconnect (DRI) topology provides an extra level of path protection for circuits on interconnected rings. DRI allows users to interconnect BLSRs, path protection configurations, or a path protection with a BLSR, with additional protection provided at the transition nodes. In a DRI topology, ring interconnections occur at two or four nodes.
DRI Features
The following list provides supported BLSR DRI features at a glance.
•
•
•
•
•
•
•
•
•
•
•
•
Note
Note
BLSR DRI
Unlike BLSR automatic protection switching (APS) protocol, BLSR DRI is a path-level protection protocol at the circuit level. Drop-and-continue BLSR-DRI requires a service selector in the primary node for each circuit routing to the other ring. Service selectors monitor signal conditions from dual feed sources and select the one that has the best signal quality. Same-side routing drops the traffic at primary nodes set up on the same side of the connected rings, and opposite-side routing drops the traffic at primary nodes set up on the opposite sides of the connected rings. For BLSR DRI, primary and secondary nodes cannot be the circuit source or destination.
A DRI circuit cannot be created if an intermediate node exists on the interconnecting link. However, an intermediate node can be added on the interconnecting link after the DRI circuit is created.
DRI protection circuits act as protection channel access (PCA) circuits. In CTC, you set up DRI protection circuits by selecting the PCA option when setting up primary and secondary nodes during DRI circuit creation.
Path Protection to BLSR DRI Handoff Configurations
Path protection configurations and BLSRs can also be interconnected. In path protection to BLSR DRI handoff configurations, primary and secondary nodes can be the circuit source or destination, which is useful when non-DCC optical interconnecting links are present.
Open GNE
Release 5.0.x supports open GNE configurations, through which the ONS 15327 can communicate with non-ONS nodes that do not support point-to-point protocol (PPP) vendor extensions or OSPF type 10 opaque link-state advertisements (LSA), both of which are necessary for automatic node and link discovery. An open GNE configuration allows the DCC-based network to function as an IP network for non-ONS nodes. To support open GNE Release 5.0.x provides provisionable foreign DCC terminations, provisionable proxy server tunnels, and provisionable firewall tunnels.
Foreign DCC termination
To configure an open GNE network, you can provision SDCC, LDCC, and GCC terminations to include a far-end, non-ONS node using either the default IP address of 0.0.0.0 or a specified IP address. You provision a far-end, non-ONS node by checking the "Far End is Foreign" check box during SDCC, LDCC, and GCC creation. The default 0.0.0.0 IP address allows the far-end, non-ONS node to provide the IP address; if you set an IP address other than 0.0.0.0, a link is established only if the far-end node identifies itself with that IP address, providing an extra level of security.
Proxy Server Tunnels and Firewall Tunnels
By default, the SOCKS proxy server only allows connections to discovered ONS peers, and the firewall blocks all IP traffic between the DCC network and LAN. You can, however, provision proxy tunnels to allow up to 12 additional destinations for SOCKS version 5 connections to non-ONS nodes. You can also provision firewall tunnels to allow up to 12 additional destinations for direct IP connectivity between the DCC network and LAN. Proxy and firewall tunnels include both a source and destination subnet. The connection must originate within the source subnet and terminate within the destination subnet before either the SOCKS connection or IP packet flow is allowed.
To set up proxy and firewall subnets in CTC, use the Provisioning > Network > Proxy and Firewalls subtabs. The availability of proxy and/or firewall tunnels depends on the network access settings of the node. See the user documentation for further details.
1+1 VT Protection Support
With Release 5.0.x support for VT 1+1 protection increases from 224 to 336 VTs. The CTC Resource Allocation Usage screen is updated to display the working and protect allocation.
State Verification Scan Before Activation
Before allowing a software activation or reversion to proceed, Release 5.0.x nodes verify that their current state meets required activation criteria. Activation criteria must be met in order to avoid traffic hits. For ONS 15454, ONS 15454 SDH, ONS 15327, and ONS 15310 nodes, all BLSR spans on the node must be locked-out, and no 1:1, 1:N, 1+1 or Y-Cable protection switches can be in progress. For ONS 15600 nodes, all BLSR spans on the node must be locked-out.
Admin SSM
Synchronization status messaging (SSM) is a protocol that communicates information about the quality of the timing source. SSM messages enable nodes to automatically select the highest quality timing reference and to avoid timing loops. With Release 5.0.x you can configure an SSM value for a timing source (either BITS-IN or Optical Line) by selecting from the "ADMIN. SSM" selection box in the BITS Facilities subtab of the node view, Provisioning > Timing tabs. This feature is useful when the selected external timing source has no SSM information. When you select the Admin SSM value, all switching decisions are subsequently made based on your selection. The same SSM value is transmitted out of the interface configured for BITS Out, and in transmit Optical S1. The DS1 BITS type with framing type SF(D4) only supports Admin SSM. The 64KHz+8KHz clock (ONS 15454 SONET) also only supports Admin SSM. ESF Framing must have Sync Messaging turned off (uncheck the check box) in order to enable Admin SSM selection. SONET nodes use the SSM Generation II message set, as defined in Table 4 of ANSI T1.101-1999. SDH nodes support SDH generation 1 SSM and STU. SONET nodes support only SONET SSM (GR-253).
Linear Port-Mapped Ethernet Mode (8-port 10/100 Ethernet Linear Mapper)
Port-mapped mode, also referred to as linear mapper, configures the E-Series card to map a specific E-Series Ethernet port to one of the card's specific STS/VC circuits. Port-mapped mode ensures that Layer 1 transport has low latency for unicast, multicast, and mixed traffic. Ethernet and Fast Ethernet on the E100T-G or E10/100-4 card operate at line-rate speed. Gigabit Ethernet transport is limited to a maximum of 600 Mbps because the E1000-2-G card has a maximum bandwidth of STS-12c/VC4-4c. Ethernet frame sizes up to 1522 bytes are also supported, which allow transport of IEEE 802.1Q tagged frames. The larger maximum frame size of Q-in-Q frames (IEEE 802.1Q in IEEE 802.1Q wrapped frames) is not supported.
E-Series Mapping Ethernet Ports to STS/VC Circuits
Port-mapped mode disables Layer 2 functions supported by the E-Series in single-card and multicard mode, including STP, VLANs, and MAC address learning. It significantly reduces the service-affecting time for cross-connect and TCC2/TCC2P/XTC card switches.
Port-mapped mode does not support VLANs in the same manner as multicard and single-card mode. The ports of E-Series cards in multicard and single-card mode can join specific VLANs. E-Series cards in port-mapped mode do not have this Layer 2 capability and only transparently transport external VLANs over the mapped connection between ports. An E-Series card in port-mapped mode does not inspect the tag of the transported VLAN, so a VLAN range of 1 through 4096 can be transported in port-mapped mode.
Port-mapped mode does not perform any inspection or validation of the Ethernet frame header. The Ethernet CRC is validated, and any frame with an invalid Ethernet CRC is discarded.
Port-mapped mode also allows the creation of STS/VC circuits between any two E-Series cards, including the E100T-G, E1000-2-G, and the E10/100-4 (the ONS 15327 E-Series card). Port-mapped mode does not allow ONS 15454 E-Series cards to connect to the ML-Series or G-Series cards, but does allow an ONS 15327 E10/100-4 card provisioned with LEX encapsulation to connect to the ML-Series or G-Series cards.
SNMP
High Capacity RMON
Remote Network Monitoring (RMON) is a feature commonly used to monitor the health of a network. The Internet Engineering Task Force (IETF) specifies a standard MIB, RFC 2819 [1], to be deployed for this purpose. Release 5.0.x adds enhancements to the SNMP agent on the ONS 15454, ONS 15454 SDH, and ONS 15327 platforms to supplement existing RMON SNMP support. This enhancement includes support for the HC-RMON-MIB. High Capacity RMON (HC-RMON) is an extension of RMON. RMON counters are 32-bit while HC-RMON counters are 32-bit and 64-bit as defined in the MIB. Release 5.0.x supports the following HC-RMON tables.
•
•
•
The MIB variable hcRMONCapabilities is supported along with these tables.
STS Around Ring
Release 5.0.x supports manual provisioning of contiguous concatenation (CCAT) STS circuits around the ring (traffic travels around the ring, starting and ending at the same node). In previous releases, if you selected the circuit source and destination as starting and ending on different I/O ports of the same node, the result would be an intra-node circuit only. With Release 5.0.x, you can manually route this type of circuit all the way around the ring. STS around the ring is supported for an unprotected path, in an unprotected ring, unless the underlying topology is line protected, in which case the around the ring circuit will also be line protected. STS around the ring is supported for all circuit sizes, starting with STS1 (SONET), or STM1 (SDH), and for all supported management interfaces.
Provisionable Patchcords
A provisionable patchcord is a user-provisioned link that is advertised by OSPF throughout the network. Provisionable patchcords, also called virtual links, are needed if an ONS 15327 optical port is connected to an ONS 15454 transponder or muxponder client port provisioned in transparent mode. Provisionable patchcords are required on both ends of a physical link. The provisioning at each end includes a local patchcord ID, slot and port information, remote IP address, and remote patchcord ID. Patchcords appear as dashed lines in CTC network view.
For supported combinations for ONS 15327 optical cards and the ONS 15454 transponder/muxponder cards used in a provisionable patchcord, refer to the Cisco ONS 15327 Reference Manual. For more information about the ONS 15454 transponder and muxponder cards, refer to the Cisco ONS 15454 Reference Manual.
Optical ports have the following requirements when used in a provisionable patchcord:
•
•
•
Enhanced State Model
Release 5.0.x introduces new administrative and service states for Cisco ONS 15327 cards, ports, and cross-connects. Administrative and service states are based on the generic state model defined in Telcordia GR-1093 Core, Issue 2 and ITU-T X.731 and are available for all support management interfaces. The following state types and state transition types are defined for Release 5.0.x. Consult the Cisco ONS 15327 Reference Manual for specific states and their applications.
Service States
Service states include a Primary State (PST), a Primary State Qualifier (PSTQ), and one or more Secondary States (SST).
Administrative States
Administrative states are used to manage service states. Administrative states consist of a PST and an SST. A change in the administrative state of an entity does not change the service state of supporting or supported entities.
Service State Transitions
The possible transitions from one service state to the next state for cards, ports, and cross-connects. A service state transition is based on the action performed on the entity and any autonomous activity.
Card Service State Transitions
The service state transitions for cards.
Port and Cross-Connect Service State Transitions
Port states do not impact cross-connect states with one exception. A cross-connect in the OOS-AU,AINS service state cannot transition autonomously into the IS-NR service state until the parent port is IS-NR.
Circuit State Model
Release 5.0.x adds support for circuit service and administrative states in CTC. For more information consult the user documentation.
CTC Enhancements
CTC Circuits State Default
The Release 5.0.x circuit creation wizard uses the new node default value, Node.circuits.State, as the default circuit state when creating a circuit. This default can be set in the NE Defaults window, and will not be overridden by the "user preferences" command feature, which caused the default value to be abandoned when using the wizard in previous releases.
Shell Login Challenge
Release 5.0.x supports the requirement of a specific shell password, set initially by the first shell user and then required of subsequent shell users at login. When this feature is enabled, the password is required of all shell users (rather than each user having a separate account) from the time it is set or changed. In the CTC node view, Provisioning > Security> Access tabs, check the "Enable Shell Password" check box to enable the shell password feature. The password can then be set or changed in a telnet or SSH shell session using the "passwd" command.
Note
Date Format Selection
Release 5.0.x adds a date format option to CTC, enabling you to choose between U.S. (MM/DD/YY) and European (DD/MM/YY) date formats. To choose the date format, click the Edit menu and choose Preferences. Select the desired date format (the default is MM/DD/YY) and click OK. The name/value pair ("ctc.dateFormat=DD/MM/YY" or "ctc.dateFormat=MM/DD/YY") will be updated in the ctc.ini (Windows), or .ctcrc (UNIX) file, where preferences are stored. Subsequently, the date format used in all tables, dialogs, and tabs will be changed to the format you selected in the Preferences dialog.
Provisionable Patchcord Tab
Provisionable patchcords, also called virtual links, are needed if an ONS 15327 optical port is connected to an ONS 15454 transponder or muxponder client port provisioned in transparent mode. Release 5.0.x features a Provisionable Patchcord subtab in CTC that displays physical links and their associated protection types, so that, when a control channel cannot be terminated on either end of a physical link, and as a result, the physical link cannot be automatically discovered by OSPF, you can still view the physical link and its protection type in the management software interface. You can view the physical links and their terminations from the CTC network view > Provisioning > Provisionable Patchcords tabs; or from the CTC node view > Provisioning > Comm Channels > Provisionable Patchcords tabs. To provision the patchcord, you select the Node Name, Slot, Port, and ID for both ends of the physical link. The ID is a unique 16-bit number used to identify a virtual link on a node. IDs are only unique for the particular node.
TL1-CTC Circuit Unification
In Release 5.0.x CTC fully supports TL1-created circuits and TL1 fully supports CTC-created circuits. Release 5.0.x circuit behavior and appearance is unified across both management interfaces, and you can easily alternate between the two. It is also no longer necessary to upgrade a TL1 circuit for CTC, or to downgrade a CTC circuit for TL1. The following circuit unification enhancements are supported with Release 5.0.x.
•
•
•
•
•
•
•
•
•
•
•
•
•
TL1
High Level Functional Differences
The following high level support is added for Release 5.0.x.
Enhanced State Model Support
In Release 5.0.x, equipment, ports and circuits support additional Primary and Secondary states. Messages of the form REPT^DBCHG^MSG contain new Enhanced State Model (ESM) states in Release 5.0.x. The following are the new SONET states in ESM, as defined for TL1.
PST-PSTQ
Table 1 describes each service state of the entity described by the Primary State (PST) and a Primary State Qualifier (PSTQ).
Table 1 Primary States
IS-NR
In Service - Normal
OOS-AU
Out of Service - Autonomous
OOS-AUMA
Out of Service - Autonomous and Management
OOS-MA
Out of Service - Management
SST
Table 2 describes the Secondary States (SST). This parameter provides additional information pertaining to PST and PSTQ.
Remote Monitoring
TL1 support for Remote Monitoring (RMON) is added in Release 5.0.x. All the "8B10B" related SONET PMs (VPC, IPC, CGV, IOS, NIOS, DCG) in Release 4.6.x have been changed and are supported by RMON-managed PMs in Release 5.0.x.
Additional Functional Support
The following additional high level features add functional support in Release 5.0.x TL1.
•
•
•
•
•
•
•
•
•
•
•
•
TL1 Command Changes
New Commands
The following commands are added in Release 5.0.x.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Commands No Longer Supported
The following commands are no longer supported in Release 5.0.x.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Command Syntax Changes
The syntax of the following commands is changed in Release 5.0.x.
ALW-MSG-ALL syntax:
ALW-MSG-ALL:[<TID>]::<CTAG>[::,,];
Is changed to:
ALW-MSG-ALL:[<TID>]:[<aid>]:<CTAG>[::,,];
DLT-WLEN syntax:
DLT-WLEN:[<TID>]:<aid>:<CTAG>:::[CMDMDE=<cmdmde>];
Is changed to:
DLT-WLEN:[<TID>]:<aid>:<CTAG>:::[CMDMDE=<cmdmde>,][CKTID=<cktId>];
ED-BITS syntax:
ED-BITS:[<TID>]:<aid>:<CTAG>:::[LINECDE=<linecde>,][FMT=<fmt>,][SABIT=<sabit>,][IMPEDANCE=<impedance>,][LBO=<lbo>,][SYNCMSG=<syncmsg>,][AISTHRSHLD=<aisthrshld>][:<pst>];
Is changed to:
ED-BITS:[<TID>]:<aid>:<CTAG>:::[LINECDE=<linecde>,][FMT=<fmt>,][SABIT=<sabit>,][IMPEDANCE=<impedance>,][LBO=<lbo>,][SYNCMSG=<syncmsg>,][AISTHRSHLD=<aisthrshld>,][BITSFAC=<bitsfac>,][ADMSSM=<admssm>][:<pst>];
ED-CRS-STS-PATH syntax:
ED-CRS-STS-PATH:[<TID>]:<src>,<dst>:<CTAG>::[<cct>]:[ADD=<add>],[REMOVE=<remove>]:[<pst>],[<sst>];
Is changed to:
ED-CRS-STS-PATH:[<TID>]:<src>,<dst>:<CTAG>::[<cct>]:[ADD=<add>,][REMOVE=<remove>,][CKTID=<cktid>,][CMDMDE=<cmdmde>]:[<pst>],[<sst>];
ED-CRS-VT-PATH syntax:
ED-CRS-VT-PATH:[<TID>]:<src>,<dst>:<CTAG>:::[ADD=<add>],[REMOVE=<remove>]:<pst>,[<sst>];
Is changed to:
ED-CRS-VT-PATH:[<TID>]:<src>,<dst>:<CTAG>:::[ADD=<add>,][REMOVE=<remove>,][CKTID=<cktid>,][CMDMDE=<cmdmde>]:<pst>,[<sst>];
ED-DS1 syntax:
ED-DS1:[<TID>]:<aid>:<CTAG>:::[TACC=<tacc>,][TAPTYPE=<taptype>];
Is changed to:
ED-DS1:[<TID>]:<aid>:<CTAG>:::[TACC=<tacc>,][TAPTYPE=<taptype>,][MODE=<mode>,][FMT=<fmt>];
ED-DS3I syntax:
ED-DS3I:[<TID>]:<aid>:<CTAG>:::[FMT=<fmt>,][LINECDE=<linecde>,][LBO=<lbo>,][INHFELPBK=<inhfelpbk>,][TACC=<tacc>,][TAPTYPE=<taptype>,][SFBER=<sfber>,][SDBER=<sdber>,][SOAK=<soak>]:[<pst>],[<sst>];
Is changed to:
ED-DS3I:[<TID>]:<aid>:<CTAG>:::[FMT=<fmt>,][LINECDE=<linecde>,][LBO=<lbo>,][INHFELPBK=<inhfelpbk>,][TACC=<tacc>,][TAPTYPE=<taptype>,][SFBER=<sfber>,][SDBER=<sdber>,][SOAK=<soak>,][NAME=<name>,][CMDMDE=<cmdmde>]:[<pst>],[<sst>];
ED-E1 syntax:
ED-E1:[<TID>]:<aid>:<CTAG>:::[LINECDE=<linecde>,][FMT=<fmt>,][TACC=<tacc>,][TAPTYPE=<taptype>,][SFBER=<sfber>,][SDBER=<sdber>,][SOAK=<soak>]:[<pst>],[<sst>];
Is changed to:
ED-E1:[TID]:<aid>:[CTAG]:::[LINECDE=<linecde>,][FMT=<fmt>,][TACC=<tacc>,][TAPTYPE=<taptype>,][SFBER=<sfber>,][SDBER=<sdber>,][SOAK=<soak>,][NAME=<name>,][CMDMDE=<cmdmde>]:[<pst>],[<sst>];
ED-E3 syntax:
ED-E3:[<TID>]:<aid>:<CTAG>:::[TACC=<tacc>,][TAPTYPE=<taptype>,][SFBER=<sfber>,][SDBER=<sdber>,][SOAK=<soak>]:[<pst>,][<sst>];
Is changed to:
ED-E3:[TID]:<aid>:[CTAG]:::[TACC=<tacc>,][TAPTYPE=<taptype>,][SFBER=<sfber>,][SDBER=<sdber>,][SOAK=<soak>,][NAME=<name>,][CMDMDE=<cmdmde>]:[<pst>,][<sst>];
ED-E4 syntax:
ED-E4:[<TID>]:<src>:<CTAG>:::[SFBER=<sfber>],[SDBER=<sdber>],[SOAK=<soak>]:[<pst>],[<sst>];
Is changed to:
ED-E4:[TID]:<src>:[CTAG]:::[SFBER=<sfber>],[SDBER=<sdber>],[SOAK=<soak>,][NAME=<name>,][CMDMDE=<cmdmde>]:[<pst>],[<sst>];
ED-EC1 syntax:
ED-EC1:[<TID>]:<aid>:<CTAG>:::[PJMON=<pjmon>,][LBO=<lbo>,][SOAK=<soak>,][SFBER=<sfber>,][SDBER=<sdber>]:[<pst>],[<sst>];
Is changed to:
ED-EC1:[<TID>]:<aid>:<CTAG>:::[PJMON=<pjmon>,][LBO=<lbo>,][SOAK=<soak>,][SFBER=<sfber>,][SDBER=<sdber>,][NAME=<name>,][CMDMDE=<cmdmde>]:[<pst>],[<sst>];
ED-EQPT syntax:
ED-EQPT:[<TID>]:<aid>:<CTAG>:::[PROTID=<protid>,][PRTYPE=<prtype>,][RVRTV=<rvrtv>,][RVTM=<rvtm>,][CMDMDE=<cmdmde>][:];
Is changed to:
ED-EQPT:[<TID>]:<aid>:<CTAG>:::[PROTID=<protid>,][PRTYPE=<prtype>,][RVRTV=<rvrtv>,][RVTM=<rvtm>,][CARDMODE=<cardmode>,][PEERID=<protid>,][REGENNAME=<regenname>,][PWL=<pwl>,][CMDMDE=<cmdmde>]:[<pst>],[<sst>];
ED-G1000 syntax:
ED-G1000:[<TID>]:<aid>:<CTAG>:::[MFS=<mfs>,][FLOW=<flow>,][LOWMRK=<int>,][HIWMRK=<int>,]:[<pst>],[<sst>];
Is changed to:
ED-G1000:[<TID>]:<aid>:<CTAG>:::[MFS=<mfs>,][FLOW=<flow>,][LOWMRK=<int>,][HIWMRK=<int>,][NAME=<name>,][CMDMDE=<cmdmde>]:[<pst>],[<sst>];
ED-OCH syntax:
ED-OCH:[<TID>]:<aid>:<CTAG>:::[RDIRN=<rdirn>,][EXPWLEN=<expwlen>,][VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][CALOPWR=<calopwr>,][CHPOWER=<chpower>,][NAME=<portname>,][SFBER=<sfber>,][SDBER=<sdber>,][OSDBER=<sdber>,][ALSMODE=<alsmode>,][ALSRCINT=<alsrcint>,][ALSRCPW=<alsrcpw>,][COMM=<comm>,][GCCRATE=<gccrate>,][DWRAP=<drwap>,][FEC=<fec>,][MACADDR=<macaddr>,][SYNCMSG=<syncmsg>,][SENDDUS=<senddus>,][RLASER=<rlaser>,][SOAK=<soak>,][OSPF=<ospf>]:[<pst>],[<sst>];
Is changed to:
ED-OCH:[<TID>]:<aid>:<CTAG>:::[RDIRN=<rdirn>,][EXPWLEN=<expwlen>,][VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][CALOPWR=<calopwr>,][CHPOWER=<chpower>,][NAME=<portname>,][SFBER=<sfber>,][SDBER=<sdber>,][OSDBER=<sdber>,][COMM=<comm>,][GCCRATE=<gccrate>,][DWRAP=<drwap>,][FEC=<fec>,][PAYLOADMAP=<payloadmap>,][MACADDR=<macaddr>,][SYNCMSG=<syncmsg>,][SENDDUS=<senddus>,][SOAK=<soak>,][OSPF=<ospf>,][CMDMDE=<cmdmde>]:[<pst>],[<sst>];
ED-OMS syntax:
ED-OMS:[<TID>]:<aid>:<CTAG>:::[RDIRN=<rdirn>,][EXPBAND=<expband>,][VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][CALOPWR=<calopwr>,][CHPOWER=<chpower>]:[<pst>],[<sst>];
Is changed to:
ED-OMS:[<TID>]:<aid>:<CTAG>:::[RDIRN=<rdirn>,][EXPBAND=<expband>,][VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][CALOPWR=<calopwr>,][CHPOWER=<chpower>,][NAME=<name>,][SOAK=<soak>,][CMDMDE=<cmdmde>]:[<pst>],[<sst>];
ED-OTS syntax:
ED-OTS:[<TID>]:<aid>:<CTAG>:::[RDIRN=<rdirn>,][VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][CALOPWR=<calopwr>,][CALTILT=<caltilt>,][OSRI=<osri>,][ALSMODE=<alsmode>,][ALSRCINT=<alsrcint>,][ALSRCPW=<alsrcpw>,][EXPGAIN=<gain>]:[<pst>],[<sst>];
Is changed to:
ED-OTS:[<TID>]:<aid>:<CTAG>:::[RDIRN=<rdirn>,][VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][OFFSET=<offset>,][CALTILT=<caltilt>,][OSRI=<osri>,][AMPLMODE=<amplmode>,][CHPOWER=<chpower>,][EXPGAIN=<expgain>,][NAME=<name>,][SOAK=<soak>,][CMDMDE=<cmdmde>]:[<pst>],[<sst>];
ED-STM1E syntax:
ED-STM1E:[<TID>]:<src>:<CTAG>:::[SYNCMSG=<syncmsg>],[SENDDUS=<senddus>],[SFBER=<sfber>],[SDBER=<sdber>],[SOAK=<soak>]:[<pst>],[<sst>];
Is changed to:
ED-STM1E:[<TID>]:<src>:<CTAG>:::[SYNCMSG=<syncmsg>],[SENDDUS=<senddus>],[SFBER=<sfber>],[SDBER=<sdber>],[SOAK=<soak>,][NAME=<name>,][CMDMDE=<cmdmde>]:[<pst>],[<sst>];
ED-T1 syntax:
ED-T1:[<TID>]:<aid>:<CTAG>:::[LINECDE=<linecde>,][FMT=<fmt>,][LBO=<lbo>,][TACC=<tacc>,][TAPTYPE=<taptype>,][SOAK=<soak>,][SFBER=<sfber>,][SDBER=<sdber>]:[<pst>],[<sst>];
Is changed to:
ED-T1:[<TID>]:<aid>:<CTAG>:::[LINECDE=<linecde>,][FMT=<fmt>,][LBO=<lbo>,][TACC=<tacc>,][TAPTYPE=<taptype>,][SOAK=<soak>,][SFBER=<sfber>,][SDBER=<sdber>,][NAME=<name>,][CMDMDE=<cmdmde>]:[<pst>],[<sst>];
ED-T3 syntax:
ED-T3:[<TID>]:<aid>:<CTAG>:::[FMT=<fmt>,][LINECDE=<linecde>,][LBO=<lbo>,][INHFELPBK=<inhfelpbk>,][TACC=<tacc>,][TAPTYPE=<taptype>,][SOAK=<soak>,][SFBER=<sfber>,][SDBER=<sdber>]:[<pst>],[<sst>];
Is changed to:
ED-T3:[<TID>]:<aid>:<CTAG>:::[FMT=<fmt>,][LINECDE=<linecde>,][LBO=<lbo>,][INHFELPBK=<inhfelpbk>,][TACC=<tacc>,][TAPTYPE=<taptype>,][SOAK=<soak>,][SFBER=<sfber>,][SDBER=<sdber>,][NAME=<name>,][CMDMDE=<cmdmde>]:[<pst>],[<sst>];
ED-VC3 syntax:
ED-VC3:[<TID>]:<src>:<CTAG>:::[RVRTV=<rvrtv>],[RVTM=<rvtm>],[HOLDOFFTIMER=<holdofftimer>],[TACC=<tacc>,][TAPTYPE=<taptype>]:[<pst>],[<sst>];
Is changed to:
ED-VC3:[<TID>]:<src>:<CTAG>:::[RVRTV=<rvrtv>,][RVTM=<rvtm>,][HOLDOFFTIMER=<holdofftimer>,][TACC=<tacc>,][TAPTYPE=<taptype>,][CMDMDE=<cmdmde>,][EXPTRC=<exptrc>,][TRC=<trc>,][TRCMODE=<trcmode>]:[<pst>],[<sst>];
ED-VT1 syntax:
ED-VT1:[<TID>]:<aid>:<CTAG>:::[RVRTV=<rvrtv>,][RVTM=<rvtm>,][HOLDOFFTIMER=<holdofftimer>,][TACC=<tacc>,][TAPTYPE=<taptype>]:[<pst>],[<sst>];
Is changed to:
ED-VT1:[<TID>]:<aid>:<CTAG>:::[RVRTV=<rvrtv>,][RVTM=<rvtm>,][HOLDOFFTIMER=<holdofftimer>,][TACC=<tacc>,][TAPTYPE=<taptype>,][CMDMDE=<cmdmde>,][EXPTRC=<exptrc>,][TRC=<trc>,][TRCMODE=<trcmode>]:[<pst>],[<sst>];
ED-WDMANS syntax:
ED-WDMANS:[<TID>]:<aid>:<CTAG>:::[POWER-IN=<powerIn>,][POWER-OUT=<powerOut>,][POWER-EXP=<powerExp>,][POWER-DROP=<powerDrop>,][SYS-TYPE=<sysType>,][NTW-TYPE=<ringType>];
Is changed to:
ED-WDMANS:[<TID>]:<aid>:<CTAG>:::[POWERIN=<powerIn>,][POWEROUT=<powerOut>,][POWEREXP=<powerExp>,][NTWTYPE=<ringType>];
ED-WLEN syntax:
ED-WLEN:[<TID>]:<aid>:<CTAG>:::[SIZE=<size>]:[<pst>],[<sst>];
Is changed to:
ED-WLEN:[<TID>]:<aid>:<CTAG>:::[SIZE=<size>,][CKTID=<cktId>,][CMDMDE=<cmdmde>]:[<pst>],[<sst>];
ENT-EQPT syntax:
ENT-EQPT:[<TID>]:<aid>:<CTAG>::<aidtype>:[PROTID=<protid>,][PRTYPE=<prtype>,][RVRTV=<rvrtv>,][RVTM=<rvtm>,][CMDMDE=<cmdmde>][:];
Is changed to:
ENT-EQPT:[<TID>]:<aid>:<CTAG>::<aidtype>:[PROTID=<protid>,][PRTYPE=<prtype>,][RVRTV=<rvrtv>,][RVTM=<rvtm>,][CARDMODE=<cardmode>,][PEERID=<protid>,][REGENNAME=<regenname>,][PWL=<pwl>,][CMDMDE=<cmdmde>][:];
ENT-VCG syntax:
ENT-VCG:[<TID>]:<src>:<CTAG>:::TYPE=<type>,TXCOUNT=<txcount>,[CCT=<cct>],[LCAS=<lcas>]:;
Is changed to:
ENT-VCG:[TID]:<src>:[CTAG]:::TYPE=<type>,TXCOUNT=<txcount>,[CCT=<cct>],[LCAS=<lcas>],[BUFFERS=<buffers>],[NAME=<name>][:];
ENT-WLEN syntax:
ENT-WLEN:[<TID>]:<aid>:<CTAG>:::[SIZE=<size>]:[<pst>],[<sst>];
Is changed to:
ENT-WLEN:[<TID>]:<aid>:<CTAG>::[<wct>]:[SIZE=<size>,][CKTID=<cktId>]:[<pst>],[<sst>];
RTRV-ALM-ALL syntax:
RTRV-ALM-ALL:[<TID>]::<CTAG>::[<ntfcncde>],[<condtype>],[<srveff>][,,,];
Is changed to:
RTRV-ALM-ALL:[<TID>]:[<aid>]:<CTAG>::[<ntfcncde>],[<condtype>],[<srveff>][,,,];
RTRV-COND-ALL syntax:
RTRV-COND-ALL:[<TID>]::<CTAG>::[<typereq>][,,,];
Is changed to:
RTRV-COND-ALL:[<TID>]:[<aid>]:<CTAG>::[<typereq>][,,,];
RTRV-CRS syntax:
RTRV-CRS:[<TID>]:<aid>:<CTAG>[:::CRSTYPE=<crstype>][:];
Is changed to:
RTRV-CRS:[<TID>]:[<aid>]:<CTAG>[:::CRSTYPE=<crstype>][:];
RTRV-GIGE syntax:
RTRV-GIGE:[<TID>]:<aid>:<CTAG>;
Is changed to:
RTRV-GIGE:[<TID>]:<aid>:<CTAG>[::::];
RTRV-NE-WDMANS syntax:
RTRV-NE-WDMANS:[<TID>]:[<aid>]:<CTAG>;
Is changed to:
RTRV-NE-WDMANS:[<TID>]:[<aid>]:<CTAG>[::::];
RTRV-WDMANS syntax:
RTRV-WDMANS[:<TID>]:<aid>:<CTAG>;
Is changed to:
RTRV-WDMANS[:<TID>]:<aid>:<CTAG>[::::];
TL1 Response Changes
The following TL1 responses have changed in Release 5.0.x.
RTRV-BITS response:
<aid>::[<linecde>],[<fmt>],[<lbo>],[<syncmsg>],[<aisthrshld>],<saBit>:[<pst>]
Is changed to:
<aid>::[<linecde>],[<fmt>],[<lbo>],[<syncmsg>],[<aisthrshld>],<saBit>,[<bitsfac>],[<admssm>]:[<pst>]
RTRV-CRS response:
<from>,<to>:<cct>,<level>::<pst>,[<sst>]
Is changed to:
<from>,<to>:<cct>,<level>::[<dritype>],[<drinode>],[<cktId>]:<pst>-<pstq>[,<sst>[&<sst>]*]
RTRV-DS1 response:
<aid>::[<tacc>],[<taptype>]
Is changed to:
<aid>::[<tacc>],[<taptype>],[<mode>],[<fmt>]
RTRV-DS3I response:
<aid>::<fmt>,<linecde>,<lbo>,[<tacc>],[<taptype>],[<sfber>],[<sdber>],[<soak>]:<pst>,[<sst>]
Is changed to:
<aid>::<fmt>,<linecde>,<lbo>,[<tacc>],[<taptype>],[<sfber>],[<sdber>],[<soak>],[<name>]:<pst>-<pstq>[,<sst>[&<sst>]*]
RTRV-E1 response:
<aid>::<linecde>,<fmt>,[<tacc>],[<taptype>],[<sfber>],[<sdber>],[<soak>]:<pst>,[<sst>]
Is changed to:
<aid>::<linecde>,<fmt>,[<tacc>],[<taptype>],[<sfber>],[<sdber>],[<soak>],[<name>]:<pst>-<pstq>[,<sst>[&<sst>]*]
RTRV-E4 response:
<aid>::[<payload>],[<sfber>],[<sdber>],[<soak>]:<pst>,[<sst>]
Is changed to:
<aid>::[<payload>],[<sfber>],[<sdber>],[<soak>],[<name>]:<pst>-<pstq>[,<sst>[&<sst>]*]
RTRV-EC1 response:
<aid>::[<pjmon>],[<lbo>],[<rxequal>],[<soak>],[<soakleft>],[<sfber>],[<sdber>]:<pst>,[<sst>]
Is changed to:
<aid>::[<pjmon>],[<lbo>],[<rxequal>],[<soak>],[<soakleft>],[<sfber>],[<sdber>],[<name>]:<pst>-<pstq>[,<sst>[&<sst>]*]
RTRV-EQPT response:
<aid>:<aidtype>,<equip>,[<role>],[<status>]:[<protid>],[<prtype>],[<rvrtv>],[<rvtm>],[<cardname>],[<ioscfg>]:[<pst>],[<sst>]
Is changed to:
<aid>:<aidtype>,<equip>,[<role>],[<status>]:[<protid>],[<prtype>],[<rvrtv>],[<rvtm>],[<cardname>],[<ioscfg>],[<cardmode>],[<peerid>],[<regenname>],[<pwl>]:<pst>-<pstq>[,<sst>[&<sst>]*]
RTRV-FSTE response:
<aid>::[<adminstate>],[<linkstate>],[<mtu>],[<flowctrl>],[<duplex>],[<speed>]
Is changed to:
<aid>::[<adminstate>],[<linkstate>],[<mtu>],[<flowctrl>],[<duplex>],[<speed>],[<flow>],[<expduplex>],[<expspeed>],[<vlancosthreshold>],[<iptosthreshold>],[<name>]:<pst>-<pstq>[,<sst>[&<sst>]*]
RTRV-G1000 response:
<aid>::[<mfs>],[<flow>],[<lan>],[<optics>],[<soak>],[<als>],[<trans>],[<tport>],<lwmrk>,<hiwmrk>,[<buff>]:[<soakleft>]:<pst>,[<sst>]
Is changed to:
<aid>::[<mfs>],[<flow>],[<lan>],[<optics>],[<soak>],[<trans>],[<tport>],<lwmrk>,<hiwmrk>,[<buff>]:[<soakleft>],[<autoneg>],[<name>],[<encap>]:<pst>-<pstq>[,<sst>[&<sst>]*]
RTRV-GIGE response:
<aid>::[<adminstate>],[<linkstate>],[<mtu>],[<flowctrl>],[<optics>],[<duplex>],[<speed>]
Is changed to:
<aid>::[<adminstate>],[<linkstate>],[<mtu>],[<flowctrl>],[<optics>],[<duplex>],[<speed>],[<name>]:<pst>-<pstq>[,<sst>[&<sst>]*]
RTRV-NE-WDMANS response:
<aid>,<aidtype>::[<regulated>]
Is changed to:
<aid>,<aidtype>::[<regulated>],[<param>]:
RTRV-OCH response:
<aid>:,,[<role>],[<status>]:[<rdirn>],[<opticalPortType>],[<power>],[<expWlen>],[<actWlen>],[<iloss>],[<voamode>],[<voaattn>],[<voapwr>],[<voarefattn>],[<voarefpwr>],[<refopwr>],[<calopwr>],[<chpower>],[<portname>],[<sfber>],[<sdber>],[<alsmode>],[<alsrcint>],[<alsrcpw>],[<comm>],[<gccrate>],[<dwrap>],[<fec>],[<osfber>],[<osdber>],[<macaddr>],[<syncmsg>],[<senddus>],[<lsrstat>],[<soak>],[<soakleft>],[<ospf>]:<pst>,[<sst>]
Is changed to:
<aid>:,,[<role>],[<status>]:[<rdirn>],[<opticalPortType>],[<power>],[<expWlen>],[<actWlen>],[<iloss>],[<voamode>],[<voaattn>],[<voapwr>],[<voarefattn>],[<voarefpwr>],[<refopwr>],[<calopwr>],[<chpower>],[<portname>],[<sfber>],[<sdber>],[<comm>],[<gccrate>],[<dwrap>],[<fec>],[<payloadmap>],[<lbclcurr>],[<optcurr>],[<oprcurr>],[<osfber>],[<osdber>],[<macaddr>],[<syncmsg>],[<senddus>],[<soak>],[<soakleft>],[<ospf>]:<pst>-<pstq>[,<sst>[&<sst>]*]
RTRV-OCN-TYPE response:
<aid>:[<stringValue>],,[<role>],[<status>]:[<dcc>],[<area>],[<tmgref>],[<syncmsg>],[<senddus>],[<pjmon>],[<sfber>],[<sdber>],[<mode>],[<wvlen>],[<ringid>],[<blsrtype>],[<mux>],[<unic>],[<ccid>],[<nbrix>],[<soak>],[<soakleft>],[<ssmrcv>],[<ospf>],[<ldcc>],[<alsmode>],[<alsrcint>],[<alsrcpw>],[<lsrstat>]:<pst>,[<sst>]
Is changed to:
<aid>:[<stringValue>],,[<role>],[<status>]:[<dcc>],[<area>],[<tmgref>],[<syncmsg>],[<senddus>],[<pjmon>],[<sfber>],[<sdber>],[<mode>],[<wvlen>],[<ringid>],[<blsrtype>],[<mux>],[<unic>],[<ccid>],[<nbrix>],[<soak>],[<soakleft>],[<ssmrcv>],[<ospf>],[<ldcc>],[<lbclcurr>],[<optcurr>],[<oprcurr>],[<name>],[<exptrc>],[<trc>],[<inctrc>],[<trcmode>],[<trcformat>],[<admssm>],[<senddusff>]:<pst>-<pstq>[,<sst>[&<sst>]*]
RTRV-OMS response:
<aid>::<rdirn>,<opticalPortType>,[<power>],<expBand>,[<actBand>],[<iloss>],[<voamode>],[<voaattn>],[<voapwr>],[<voarefattn>],[<voarefpwr>],[<refopwr>],[<calopwr>],[<chpower>]:<pst>,[<sst>]
Is changed to:
<aid>::<rdirn>,<opticalPortType>,[<power>],<expBand>,[<actBand>],[<iloss>],[<voamode>],[<voaattn>],[<voapwr>],[<voarefattn>],[<voarefpwr>],[<refopwr>],[<calopwr>],[<chpower>],[<name>],[<soak>],[<soakleft>]:<pst>-<pstq>[,<sst>[&<sst>]*]
RTRV-OSC response:
<aid>::[<ringId>],[<nodeId>],[<east>],[<west>]
Is changed to:
<aid>::[<ringId>],[<nodeId>],[<east>],[<west>],[<name>]
RTRV-OTS response:
<aid>::<rdirn>,<opticalPortType>,[<power>],[<iloss>],[<voamode>],[<voaattn>],[<voapwr>],[<voarefattn>],[<voarefpwr>],[<laserst>],[<osri>],[<alsmode>],[<alsrcint>],[<alsrcpw>],[<amplmode>],[<gain>],[<expgain>],[<refopwr>],[<calopwr>],[<reftilt>],[<caltilt>],[<dculoss>],[<awgst>],[<heatst>]:<pst>,[<sst>]
Is changed to:
<aid>::<rdirn>,<opticalPortType>,[<power>],[<iloss>],[<voamode>],[<voaattn>],[<voapwr>],[<voarefattn>],[<voarefpwr>],[<osri>],[<amplmode>],[<chpower>],[<gain>],[<expgain>],[<refopwr>],[<offset>],[<reftilt>],[<caltilt>],[<aseopwr>],[<dculoss>],[<awgst>],[<heatst>],[<name>],[<soak>],[<soakleft>]:<pst>-<pstq>[,<sst>[&<sst>]*]
RTRV-POS response:
<aid>::[<adminstate>],[<linkstate>],[<mtu>]
Is changed to:
<aid>::[<adminstate>],[<linkstate>],[<mtu>],[<encap>],[<name>]:<pst>-<pstq>[,<sst>[&<sst>]*]
RTRV-STM1E response:
<aid>::[<payload>],[<syncmsg>],[<senddus>],[<sfber>],[<sdber>],[<soak>]:<pst>,[<sst>]
Is changed to:
<aid>::[<payload>],[<syncmsg>],[<senddus>],[<sfber>],[<sdber>],[<soak>],[<name>]:<pst>-<pstq>[,<sst>[&<sst>]*]
RTRV-T1 response:
<aid>::[<linecde>],[<fmt>],[<lbo>],[<tacc>],[<taptype>],[<soak>],[<soakleft>],[<sfber>],[<sdber>]:<pst>,[<sst>]
Is changed to:
<aid>::[<linecde>],[<fmt>],[<lbo>],[<tacc>],[<taptype>],[<soak>],[<soakleft>],[<sfber>],[<sdber>],[<name>],[<syncmsg>],[<senddus>],[<retime>]:<pst>-<pstq>[,<sst>[&<sst>]*]
RTRV-T3 response:
<aid>::[<fmt>],[<linecde>],[<lbo>],[<inhfelpbk>],[<tacc>],[<taptype>],[<soak>],[<soakleft>],[<sfber>],[<sdber>]:<pst>,[<sst>]
Is changed to:
<aid>::[<fmt>],[<linecde>],[<lbo>],[<inhfelpbk>],[<tacc>],[<taptype>],[<soak>],[<soakleft>],[<sfber>],[<sdber>],[<name>]:<pst>-<pstq>[,<sst>[&<sst>]*]
RTRV-VCG response:
<src>::<type>,<txcount>,<cct>,<lcas>
Is changed to:
<src>::<type>,<txcount>,<cct>,<lcas>,<buffers>,[<name>]:<pst>
RTRV-WDMANS response:
<aid>::[<powerIn>],[<powerOut>],[<powerExp>],[<powerDrop>],[<sysType>],[<apcEnable>],[<ringType>]
Is changed to:
<aid>::[<powerIn>],[<powerOut>],[<powerExp>],[<ringType>],[<_opticalNodeType>],[<lastrundat>],[<lastruntm>]
RTRV-WLEN response:
<aid>::[<mode>],[<size>]:[<pst>],[<sst>]
Is changed to:
<aid>::[<wct>]:[<size>],[<cktId>]:<pst>-<pstq>[,<sst>[&<sst>]*]
TL1 ENUM Changes
The following section, including Table 3 through Table 62, highlights ENUM items changed (added or removed) for Release 5.0.x, by ENUM type.
Table 3 APC_STATE enum items added to Release 5.0.x
APC_STATE_DISABLE
"DISABLE"
APC_STATE_FORCED_DISABLE
"FORCED-DISABLE"
APC_STATE_WORKING
"WORKING"
APC_STATE is used in the following commands:
•
Table 4 BITS_FAC enum items added to Release 5.0.x
RATE_2MHZ
"2M"
RATE_64K
"64K"
RATE_6MHZ
"6M"
RATE_E1
"E1"
RATE_T1
"T1"
BITS_FAC is used in the following commands:
•
•
Table 5 BUFFERS enum items added to Release 5.0.x
BUFFERS_DEFAULT
"DEFAULT"
BUFFERS_EXPANDED
"EXPANDED"
BUFFERS is used in the following commands:
•
•
CARDMODE is used in the following commands:
•
•
CCT is used in the following commands:
•
•
•
•
•
•
•
COMM_TYPE is used in the following commands:
•
•
•
Table 9 CRS_TYPE enum items added to Release 5.0.x
CRS_TYPE_STS18C
"STS18C"
CRS_TYPE_STS36C
"STS36C"
CRS_TYPE is used in the following commands:
•
DETECTION_GUARD_TIMER is used in the following commands:
•
•
•
DIAGTYPE is used in the following commands:
•
Table 12 DRINODE enum items added to Release 5.0.x
DRINODE_INT
"INT"
DRINODE_NA
"NA"
DRINODE_PRI
"PRI"
DRINODE_SEC
"SEC"
DRINODE is used in the following commands:
•
•
DRITYPE is used in the following commands:
•
•
Table 14 DS1MODE enum items added to Release 5.0.x
DS1MODE_BFDL
"BFDL"
DS1MODE_FDL
"FDL"
DS1MODE is used in the following commands:
•
•
Table 15 ENCAP enum items added to Release 5.0.x
ENCAP_HDLC
"HDLC"
ENCAP_HDLC_LEX
"HDLC-LEX"
ENCAP_HDLC_X86
"HDLC-X86"
ENCAP_UNKNOWN
"UNKNOWN"
ENCAP is used in the following commands:
•
•
•
•
EQPT_TYPE is used in the following commands:
•
•
•
•
•
EQUIPMENT_TYPE is used in the following commands:
•
Table 18 FCS enum items added to Release 5.0.x
FCS_16
"FCS-16"
FCS_32
"FCS-32"
FCS_NONE
"NONE"
FCS is used in the following commands:
•
•
Table 19 FEC_MODE enum items added to Release 5.0.x
FEC_ENH
"ENH"
FEC_OFF
"OFF"
FEC_STD
"STD"
FEC_MODE is used in the following commands:
•
•
Table 20 LASER_STATUS enum items no longer supported in Release 5.0.x
LASER_STATUS_LASER_OFF
"OFF"
LASER_STATUS_LASER_ON
"ON"
LASER_STATUS is used in the following commands:
•
Table 21 LASER_STATUS enum items added to Release 5.0.x
LASER_STATUS_LASER_DOWN
"DOWN"
LASER_STATUS_LASER_UP
"UP"
LASER_STATUS is used in the following commands:
•
Table 22 LPBK_TYPE enum items added to Release 5.0.x
LPBK_TYPE_FE_CMD_ESF_PAYLD_LPBK
"PAYLOAD"
LPBK_TYPE is used in the following commands:
•
•
MFS_TYPE is used in the following commands:
•
•
MOD1PAYLOAD is used in the following commands:
•
•
Table 25 MOD2 enum items no longer supported in Release 5.0.x
MOD2_M2_CLNT
"CLNT"
MOD2_M2_OSC
"OSC"
MOD2 is used in the following commands:
•
•
•
•
•
•
•
•
MOD2 is used in the following commands:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Table 27 MOD2ALM enum items no longer supported in Release 5.0.x
MOD2ALM_M2_CLNT
"CLNT"
MOD2ALM_M2_OSC
"OSC"
MOD2ALM is used in the following commands:
•
•
•
•
---
MOD2ALM is used in the following commands:
•
•
•
•
Table 29 MOD2B enum items no longer supported in Release 5.0.x
MOD2B_M2_CLNT
"CLNT"
MOD2B_M2_FC
"FC"
MOD2B is used in the following commands:
•
•
•
•
•
•
•
•
•
•
•
MOD2B is used in the following commands:
•
•
•
•
•
•
•
•
•
•
•
•
Table 31 MOD2O enum items no longer supported in Release 5.0.x
MOD2O_M2_CLNT
"CLNT"
MOD2O is used in the following commands:
•
•
MOD2_DATA is used in the following commands:
•
•
•
Table 34 MOD_PATH enum items added to Release 5.0.x
MOD_PATH_M2_STS18C
"STS18C"
MOD_PATH_M2_STS36C
"STS36C"
MOD_PATH is used in the following commands:
•
•
•
•
•
•
•
•
•
•
Table 35 NE_SECU_MODE enum items added to Release 5.0.x
NE_SECU_MODE_REPEATER
"REPEATER"
NE_SECU_MODE_SECURE
"SECURE"
NE_SECU_MODE is used in the following commands:
•
Table 36 ONE_PLUS_ONE enum items added to Release 5.0.x
OPTIMIZED_ONEPLUSONE
"OPTIMIZED"
STANDARD_ONEPLUSONE
"STANDARD"
ONE_PLUS_ONE is used in the following commands:
•
•
OPTICAL_NODE_TYPE is used in the following commands:
•
---
Table 38 OPTICAL_PORT_TYPE enum items added to Release 5.0.x
OPTICAL_PORT_TYPE_OPT_PORT_IN_PT
"IN-PT"
OPTICAL_PORT_TYPE_OPT_PORT_OUT_PT
"OUT-PT"
OPTICAL_PORT_TYPE is used in the following commands:
•
•
•
Table 39 OPTICAL_WLEN enum items no longer supported in Release 5.0.x
OPTICAL_WLEN_WL_UNKNOWN
"USE-TWL1"
OPTICAL_WLEN is used in the following commands:
•
•
•
•
Table 40 OPTICAL_WLEN enum items added to Release 5.0.x
OPTICAL_WLEN_WL_USETWL1
"USE-TWL1"
OPTICAL_WLEN is used in the following commands:
•
•
•
•
•
•
•
•
Table 41 PAYLOAD enum items no longer supported in Release 5.0.x
PAYLOAD_PT_10GE
"10GE"
PAYLOAD_PT_1GE
"1GE"
PAYLOAD_PT_SDI_D1_VIDEO
"SDI-D1-VIDEO"
PAYLOAD is used in the following commands:
•
•
•
•
•
PAYLOAD is used in the following commands:
•
•
•
•
•
Table 43 PAYLOAD_MAPPING enum items added to Release 5.0.x
PAYLOAD_MAPPING_ASYNCH
"ASYNCH"
PAYLOAD_MAPPING_ODU
"ODU"
PAYLOAD_MAPPING_SYNCH
"SYNCH"
PAYLOAD_MAPPING is used in the following commands:
•
•
Table 44 PORT_TYPE enum items added to Release 5.0.x
PORT_TYPE_TRANSMUX
"TRANSMUX"
PORT_TYPE is used in the following commands:
•
Table 45 PRODUCT_TYPE enum items added to Release 5.0.x
PRODUCT_TYPE_NE_15310_CL
"ONS15310-CL"
PRODUCT_TYPE is used in the following commands:
•
Table 46 PST enum items added to Release 5.0.x
PST_SS_IS_SDH
"unlocked"
PST_SS_OOS_SDH
"locked"
PST_SS_UNKNOWN
"UNKNOWN"
PST is used in the following commands:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
RECOVERY_GUARD_TIMER is used in the following commands:
•
•
•
REGULATED_PARAM_NAME is used in the following commands:
•
REGULATED_PORT_TYPE is used in the following commands:
•
Table 50 SAMPLE_TYPE enum items added to Release 5.0.x
SAMPLE_TYPE_ABSOLUTE
"ABSOLUTE"
SAMPLE_TYPE_DELTA
"DELTA"
SAMPLE_TYPE is used in the following commands:
•
Table 51 SNMP_VERSION enum items added to Release 5.0.x
SNMP_VERSION_SNMPV1
"SNMPV1"
SNMP_VERSION_SNMPV2
"SNMPV2"
SNMP_VERSION is used in the following commands:
•
•
SST is used in the following commands:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Table 53 STARTUP_TYPE enum items added to Release 5.0.x
STARTUP_TYPE_FALLING
"FALLING"
STARTUP_TYPE_RISING
"RISING"
STARTUP_TYPE_RISING_OR_FALLING
"RISING-OR-FALLING"
STARTUP_TYPE is used in the following commands:
•
•
•
Table 54 STM1E_MODE enum items added to Release 5.0.x
STM1E_MODE_STM1_MODE
"STM1E"
STM1E_MODE is used in the following commands:
•
SYS_TYPE is used in the following commands:
•
•
Table 56 TMPER enum items added to Release 5.0.x
TMPER_PER_HR
"1-HR"
TMPER_PER_MIN
"1-MIN"
TMPER_RAW_DATA
"RAW-DATA"
TMPER is used in the following commands:
•
•
•
•
•
•
•
•
•
Table 57 TRCFORMAT enum items added to Release 5.0.x
TRCFORMAT_16_BYTE
"16-BYTE"
TRCFORMAT_1_BYTE
"1-BYTE"
TRCFORMAT_64_BYTE
"64-BYTE"
TRCFORMAT is used in the following commands:
•
•
•
•
•
•
Table 58 TRCLEVEL enum items no longer supported in Release 5.0.x
TRCLEVEL_TL_J1_PATH
"J1"
TRCLEVEL_TL_TANDEM_1
"TCM1"
TRCLEVEL_TL_TANDEM_2
"TCM2"
TRCLEVEL is used in the following commands:
•
•
•
•
Table 59 TRCMODE enum items no longer supported in Release 5.0.x
TRCFORMAT_16_BYTE
"16-BYTE"
TRCFORMAT_1_BYTE
"1-BYTE"
TRCFORMAT_64_BYTE
"64-BYTE"
TRCMODE is used in the following commands:
•
•
•
•
•
•
•
•
•
•
•
•
VALIDITY is used in the following commands:
•
•
Table 61 VERIFICATION_GUARD_TIMER enum items added to Release 5.0.x
VERIFICATION_GUARD_TIMER_1
"1.0"
VERIFICATION_GUARD_TIMER_500
"0.5"
VERIFICATION_GUARD_TIMER is used in the following commands:
•
•
•
Table 62 WCT enum items added to Release 5.0.x
WCT_ONEWAY
"1WAY"
WCT_TWOWAY
"2WAY"
WCT is used in the following commands:
•
•
Related Documentation
Release-Specific Documents
•
•
•
•
•
•
Platform-Specific Documents
•
Provides installation, turn up, test, and maintenance procedures•
Provides technical reference information for SONET/SDH cards, nodes, and networks•
Provides a list of SONET alarms and troubleshooting procedures, general troubleshooting information, and hardware replacement procedures•
Provides a comprehensive list of TL1 commandsObtaining Documentation
The following sections provide sources for obtaining documentation from Cisco Systems.
World Wide Web
You can access the most current Cisco documentation on the World Wide Web at the following sites:
Documentation CD-ROM
Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or as an annual subscription.
Ordering Documentation
Cisco documentation is available in the following ways:
•
http://www.cisco.com/cgi-bin/order/order_root.pl
•
http://www.cisco.com/go/subscription
•
Documentation Feedback
If you are reading Cisco product documentation on the World Wide Web, you can submit technical comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco.
You can e-mail your comments to bug-doc@cisco.com.
To submit your comments by mail, use the response card behind the front cover of your document, or write to the following address:
Attn Document Resource Connection
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-9883We appreciate your comments.
Obtaining Technical Assistance
Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools. For Cisco.com registered users, additional troubleshooting tools are available from the TAC website.
Cisco.com
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information and resources at anytime, from anywhere in the world. This highly integrated Internet application is a powerful, easy-to-use tool for doing business with Cisco.
Cisco.com provides a broad range of features and services to help customers and partners streamline business processes and improve productivity. Through Cisco.com, you can find information about Cisco and our networking solutions, services, and programs. In addition, you can resolve technical issues with online technical support, download and test software packages, and order Cisco learning materials and merchandise. Valuable online skill assessment, training, and certification programs are also available.
Customers and partners can self-register on Cisco.com to obtain additional personalized information and services. Registered users can order products, check on the status of an order, access technical support, and view benefits specific to their relationships with Cisco.
To access Cisco.com, go to the following website:
Technical Assistance Center
The Cisco TAC website is available to all customers who need technical assistance with a Cisco product or technology that is under warranty or covered by a maintenance contract.
Contacting TAC by Using the Cisco TAC Website
If you have a priority level 3 (P3) or priority level 4 (P4) problem, contact TAC by going to the TAC website:
http://www.cisco.com/en/US/support/index.html
P3 and P4 level problems are defined as follows:
•
•
In each of the above cases, use the Cisco TAC website to quickly find answers to your questions.
To register for Cisco.com, go to the following website:
http://tools.cisco.com/RPF/register/register.do
If you cannot resolve your technical issue by using the TAC online resources, Cisco.com registered users can open a case online by using the TAC Case Open tool at the following website:
http://www.cisco.com/tac/caseopen
Contacting TAC by Telephone
If you have a priority level 1 (P1) or priority level 2 (P2) problem, contact TAC by telephone and immediately open a case. To obtain a directory of toll-free numbers for your country, go to the following website:
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml
P1 and P2 level problems are defined as follows:
•
•
This document is to be used in conjunction with the documents listed in the "Related Documentation" section.
Copyright © 2007, Cisco Systems, Inc.
All rights reserved.
