 Feedback
|
Table Of Contents
Release Notes for Cisco ONS 15327
Release 4.0Maintenance and Administration
BLSR Support for Mixed Node Networks
Resolved Software Caveats for Release 4.0
Maintenance and Administration
DDTS # CSCdy56366 and CSCdy12392
New Features and Functionality
New Software Features and Functionality
Port Based Numbering of Alarms
Ethernet Tx and Rx Utilization
FTP Database Backup and Restore Support
Changes in TL1 Functionality Since Release 3.4
TL1 Syntax Changes Since Release 3.4
ENUM Changes to TL1 Since Release 3.4
ENUM Value Changes for Existing Commands
Enum Table Changes for Existing TL1 Commands Since Release 3.4
Enum Changes For New Commands in Release 4.0
Obtaining Technical Assistance
Contacting TAC by Using the Cisco TAC Website
Release Notes for Cisco ONS 15327
Release 4.0
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.
March, 2003
Release notes address closed (maintenance) issues, caveats, and new features for the Cisco ONS 15327 SONET multiplexer. For detailed information regarding features, capabilities, hardware, and software introduced with this release, refer to Release 4.0 of the Cisco ONS 15327 Installation and Operations Guide, Cisco ONS 15327 Troubleshooting and Reference Guide, and Cisco ONS 15454 and Cisco ONS 15327 TL1 Command Guide. For the most current version of the Release Notes for Cisco ONS 15327 Release 4.0, 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 4.0
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 4.0 since the production of the Cisco ONS 15327 System Software CD for Release 4.0.
The following changes to the release notes have been added for Release 4.0.
Changes to Caveats
The following caveat has been added.
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
DDTS # 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 under investigation.
DDTS # 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 under investigation.
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 # 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 will be resolved in a future release.
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 be resolved in a future release.
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 is under investigation.
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 is under investigation.
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 be resolved in a future release.
DDTS # CSCdy38603
VT Cross-connects downstream from a DS1 can automatically transition from the OOS-AINS state to the IS state even though the DS1 signal is not clean (for example, when there is an LOS present). This can occur when you have created a VT circuit across multiple nodes with DS1s at each end, and you have not yet applied a signal to the DS1 ports, and then you place the DS1 ports in OOS-AINS, OOS-MT, or IS. When you then place the circuit in OOS-AINS, the circuit state changes to IS (within one minute). This issue will be resolved in a future release.
DDTS # CSCdw43896
A software revert from Release 3.3 or 3.4 to 1.0.1 or 1.0.2 can cause a PDI-P alarm on intermediate nodes of a DS3 circuit after an XTC switch on the node terminating this circuit. This can occur when, after you revert all the nodes of a path protection from Release 3.3-4 to Release 1.0.1-2, then perform an XTC side switch on the node terminating the DS3 circuit. If this occurs, remove the active XTC (software reset will not work) on the node terminating the DS3 circuit. This issue is resolved for Releases 3.3 and later, but will still occur when you revert from one of these releases to Release 1.0.1-2. The issue cannot be resolved for these earlier releases.
Upgrades from Release 1.0
If you wish to upgrade from Release 1.0 to Release 4.0, you must first upgrade to maintenance Release 1.0.2. If you are already running maintenance Release 1.0.1 or better, you do not have to perform the intermediate upgrade.
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 TCC+, cross connect, DS1 and DS3 cards, with a protection group automatically provisioned. On the ONS 15454, similar behavior occurs for the TCC+ 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. It is not known at this time when or if this issue will be resolved.
Line Cards
DDTS # CSCea78368
Release 4.0 ONS 15454 and 15327 nodes may encounter spontaneous DS-1, DS-1N, or XTC card resets under the following conditions. When a DS1 port is provisioned for ESF framing, inject LOF (loss of frame) into the port (in other words, use D4 framing on the test set or external equipment). The active DS1 card reboots (or on the ONS 15327, the active XTC reboots). If the DS1 card (or XTC) is part of a protection group, the protect card will become active and may also reboot due to the LOF.
This behavior is not configuration dependent. It occurs on any DS-1 or DS-1N card present in any slot and for any port, provided it is provisioned for ESF framing and is active. If all ports on the active DS1 card are provisioned for D4 framing, this behavior is not observed.
To avoid this issue, provision all ports and external DS-1 equipment for D4 framing. This applies to both ONS 15454 and 15327.
Another workaround (only for the ONS 15454) is to provision the circuit from the affected DS1 port to another unused port on which line framing is stable. If the DS1 card autoresets due to LOF (as discussed above), the traffic on the adjacent port will not be affected if protection is not enabled. For the ONS 15327, when the XTC switches to the protect card due to the LOF condition on one of the ports, hits greater than 60 ms could occur for the traffic on the adjacent port(s). This issue is resolved in Release 4.1
E Series and G Series 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 is under investigation.
DDTS # CSCdy63172
With E100/E1000 cards, a CARLOSS alarm present, and port alarms suppressed from CTC, Manual Alarm Suppression does not correctly suppress CARLOSS alarms. This issue is under investigation.
DDTS # CSCdy47038
G1000-2 path alarm profiles applied on port 2 are not updated to reflect the correct alarm severities. This issue is under investigation.
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. A future hardware release will incorporate improved hardware PLL circuitry on the G1000-2 line card to allow an active XTC removal without causing excessive traffic loss.
Path Protection Functionality
DDTS # CSCea23862
After you perform a force switch on one of the spans of a DRI or IDRI topology with path protection-DRI circuits present, if you then apply a clear on the same span, the state will not show up immediately in CTC. This issue is under investigation.
BLSR Functionality
DDTS # CSCdz35479
Rarely, CTC Network view can freeze following the deletion or addition of a node from or to a BLSR. This can result in the CTC Network view no longer updating correctly. If this occurs, restart CTC. This issue is under investigation.
DDTS # CSCdy65890
If you have PCA circuits over two-fiber or four-fiber BLSR protect channels, an incorrect auto-inservice transition occurs after traffic preemption. You may place the circuit back into the OOS-AINS state after the BLSR has returned to the unswitched mode, using the Circuit Editing pane of the CTC. This issue will be resolved in a future release.
DDTS # CSCdy48872
Issuing a lockout span in one direction while a ring switch (SF-R) is active on the other direction may result in a failure to restore PCA circuits on the ring.
To see this issue, on a node participating in a two fiber BLSR with PCA circuits terminating at the node over the two fiber BLSR, cause an SF-R by failing the receive fiber in one direction (say, west). Then, issue a lockout span in the other direction (in our example, east). Since the lockout span has higher priority than the SF-R, the ring switch should clear and PCA traffic should be restored on spans without a fiber fault. The ring switch does clear, but PCA traffic does not restore. To correct this issue, clear the fiber fault. All traffic restores properly. This issue will be resolved in Release 5.0.
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 will be resolved in a future release.
BLSR Support for Mixed Node Networks
The ONS 15327 is supported for BLSR in combination with ONS 15454 nodes only if Release 3.3 or greater is installed and running on all BLSR nodes. If you wish to provision a BLSR on a combination of ONS 15327 and ONS 15454 nodes, you should upgrade to Release 3.3 or greater on all ONS 15454 and ONS 15327 nodes first.
TL1
Note
DDTS # CSCdz79471
The default state, when no PST or SST inputs are given for The TL1 command, RMV-<MOD2_IO>, is OOS instead of OOS-MT. Thus, if you issue a RMV statement, followed by maintenance-state-only commands, such as OPR-LPBK, the maintenance state commands will not work, since the port will be in the out-of-service state (OOS), instead of the out-of-service maintenance state (OOS-MT). To work around this issue, place ports in the OOS-MT state, by specifying the primary state as OOS and a secondary state of MT in either the RMV-<MOD2_IO> command or the ED-<MOD2_IO> command.
Scripts that depend on the RMV-<MOD2_IO> command defaulting to OOS-MT without specifying the primary and secondary states should be updated to force the primary and secondary state inputs to be populated. This issue will be resolved in Release 5.0.
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.
DDTS # CSCdz86121
In one rare case, the ONS 15454/15327 times out a user session without communicating the timeout to TL1. If this happens, the TL1 user remains logged in, although the session is actually timed out. This can occur when you log into the node with a timeout of X minutes. If the user session sits idle for all but 5 seconds of the X minutes, then you have only 5 seconds to type in a command to notify the node that the session is active. If you try this, you will likely miss the five second window, in which case the node will respond as though the session is inactive and deny access. However, because you have typed a key, irrespective of the five second window, TL1 responds as though the session is active and does not log you out (time out). You will not have access to the node and will receive a "DENY" response to TL1 commands. The error message may vary depending on commands issued. To recover from this situation, log out and log back in to TL1. This issue will be 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 will be resolved in Release 5.0
DDTS # CSCea03186
The TL1 command, INH-USER-SECU, does not disable the userid appropriately. The command should disable the userid until the corresponding ALW-USER-SECU command is issued; however, the userid is automatically re-enabled after the user lock-out period expires. The user lockout period is set from the CTC. This issue will be alleviated in Release 4.0.1 by removal of the ALW-USER-SECU and INH-USER-SECU commands. The commands will be reinstated correctly in Release 5.0.
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.
Resolved Software Caveats for Release 4.0
The following items are resolved in Release 4.0.
Maintenance and Administration
DDTS # CSCdy56366 and CSCdy12392
With a 1+1 protection group and OC-3 or OC-12 cards, when a protection switch occurs, the PSC and PSD fields on the performance pane do not increment. This issue is resolved in Release 4.0.
DDTS # CSCdz00573
The OC3 and EC1 are the only cards for which near end STS path PM is available to CTM . To retrieve near end path PM for other cards, use TL1, SNMP, or CTC. Note that far end STS path PM is available for all electrical cards and the OC3. This issue is resolved in Release 4.0.
BLSR Functionality
DDTS # CSCdy59877
Rarely, an optical card participating in a BLSR may lose communication with the XC card in the same node, resulting in a traffic switch away from that optical card and a COMIOXC alarm raised on the XC. To recover from this situation, issue a soft reset on the optical card from CTC. This issue is resolved in Release 4.0.
DDTS # CSCdy59242
Under some circumstances, if a fail-to-switch alarm is raised upon introducing SF-R with the existing Lockout Span command, the alarm becomes stuck after the SF-R and Lockout Span are cleared.
The following example illustrates how this can occur.
In a two fiber BLSR, say the east side of Node 1 is connected to the west side of Node 2.
Step 1
Step 2
Step 3
Step 4
The issue is that Node 2 ignores a long-path Lockout Span on its east side and initiates a ring switch with a local SF-R request, then fails.
To avoid this issue, make sure the ring is in the idle state and issue an Exercise Ring command on the span that reports Fail-to-Switch alarm to clear that alarm. This issue is resolved in Release 4.0.
DDTS # CSCdv89939
After a BLSR span or ring switch, traffic is switched to a different set of nodes and a protection STS is used. At this point, any ongoing J1 monitoring does not follow the switch. As a result, there is no J1 monitoring on the protection path. If there is a mismatch of the J1 string on the protection path, the TIM_P alarm will not be raised. Also, you can retrieve the actual captured J1 string on the working path, but if BLSR switched from working to protect, you cannot retrieve the J1 string on the protect path. This issue is resolved in Release 4.0.
DDTS # CSCdy10805
If you upgrade one of the rings in a two by two BLSR configuration, an EXTRA-TRAF-PREEMPT alarm may be raised and subsequently fail to clear on one of the rings. If the ring that has the stuck alarm already has some PCA circuits on it, you can issue and then clear a Force Ring. This should clear the stuck alarm. If no PCA circuits exist on the ring, then create one temporarily, and follow the above procedure to clear the alarm. After the alarm clears, you can remove the Force Ring, then delete the PCA circuit. This issue is resolved in Release 4.0.
DDTS # CSCdy30125
In a two by two BLSR configuration, with PCA circuits passing through the common node, if one of the rings is a two fiber BLSR and you upgrade it, a PCA connection will be promoted to become protected on the upgraded ring side. In this scenario, you can end up with a circuit that is PCA on one ring and protected on the other ring.
This can occur with any colliding STSs; in other words, any situation where the STS from the working side is going to overlay the STS from the protection side when a ring or span switch occurs. On a span switch in a four fiber BLSR this would be STS #1 on the working and STS #1 on the protect on the same side (i.e. east or west). For a ring switch on a four fiber BLSR it would be STS #1 on the working and STS #1 on the protect on the opposite side of the ring. In a two fiber BSLR there is only a ring switch, so the colliding STSs would be STS #1 on one side of the ring and STS #7 on the opposite side (for an OC-12 ring, for example). Symptoms of a failure will be protected traffic that is dropped or that has a stuck AIS-P.
When you perform a two fiber BLSR upgrade in a two by two configuration, ensure that no PCA circuits cross through the common node before you start the upgrade. Note that the PCA circuits that are added and dropped on the same ring are safe, as they will be promoted to become fully protected. All PCA circuits that cross the common node to go to another ring must be deleted before the upgrade, then recreated once the upgrade is successfully finished. This issue is resolved in Release 4.0.
Path Protection Functionality
DDTS # CSCdy62713
If you change the state of a path protection VT non-revertive circuit from IS to OOS and back to IS, then fail an active fiber span carrying the circuit, the circuit will not switch, and this can result in traffic outage. To avoid this, make sure the circuit is revertive before placing it in the OOS (out of service) state. Wait at least 30 seconds before changing a VT path protection selector from one state to another. This issue is resolved in Release 4.0.
DDTS # CSCdw66071
After a switch to protect is cleared for a revertive path protection circuit, the WTR alarm is not raised, although the wait period is observed and the circuit reverts back to working. This issue is resolved in Release 4.0.
New Features and FunctionalityThis section highlights new features and functionality for Release 4.0. For detailed documentation of each of these features, consult the user documentation.
New Hardware
There is no new hardware for this release of the ONS 15327.
New Software Features and Functionality
Cross-connect Loopback
A cross-connect loopback tests a circuit path as it passes through the cross-connect card and loops back to the port being tested. Testing and verifying circuit integrity often involves taking down the whole line; however, with the Release 4.0 cross-connect loopback, you can create a loopback on any embedded channel at supported payloads at the STS-1 granularity and higher. For example, you can loop back a single STS-1, STS-3c, STS-6c, etc., on an optical facility without interrupting the other STS circuits. Cross-connect loopbacks are supported for optical cards.
A cross-connect loopback is allowed only if the connection state of the circuit is OOS-AINS or OOS-MT. The cross-connect loopback option is available on all optical paths in the system that are cross-connected. When a cross-connect loopback is selected, if the near end is involved in a cross-connect loopback, an AIS (Alarm Indication Signal) is transmitted from the far end of the existing cross-connect. If the line supporting the path involved with a cross-connect loopback is involved in a 1+1 protection scheme, both the Active and Working paths are looped back in the cross connect matrix. Paths that are in a cross-connect loopback are not permitted to be used for test access. Only one type of loopback is allowed on a supporting line and path. If a facility loopback exists on an OC-48 line, you may not perform a cross-connect loopback on any paths in that line, and vice-versa. Addition and deletion of cross connects is permitted while the port is in an active loopback. However, if a cross-connect is deleted while the path is in a cross-connect loopback, the loopback is automatically removed by the system.
For more specific details, consult the "Cisco ONS 15327 Reference Manual," Release 4.0.
Audit Trail Enhancements
In Release 4.0, the Audit Trail feature has been improved. To use the Audit Trail features, you must be logged on with either Provisioning or Superuser privileges.
You can now save Audit Trail records created since the last archive operation to a local file. Multiple archive files, when put together, provide a view of the node's audit travel over time with no omissions or overlap.
Two new alarms indicate when an archive of the Audit Trail is needed:
•
•
Both of the new alarms clear automatically when you perform an archive via CTC.
CTC Logical Network View
In the Network view, the graphic area displays a background image with colored ONS 15327 icons. With Release 4.0, a superuser can set up the new logical network view feature to enable each user to see the same network view.
For more specific details, consult the "Cisco ONS 15327 Reference Manual," Release 4.0.
Port Based Numbering of Alarms
With Release 4.0, all alarms and conditions are announced against the associated externally visible port (numbered to match the ingress port of the signal). No alarms or conditions are announced against internal ports.
For more specific details, consult the "Cisco ONS 15327 Reference Manual," Release 4.0.
E-series Linear Mapper
The Linear Mapper is a new operation mode added to the current line of E-Series cards available on the ONS 15454 SONET, ONS 15454 SDH and the ONS 15327. This new mode accompanies the Multi-card EtherSwitch Group (Multi-card) mode and the Single-card (Single-card) EtherSwitch mode on each version of E-Series card starting with Release 4.0.
The Linear Mapper is a software feature and does not require you to purchase additional hardware if you have already deployed the E-Series cards. The Linear Mapper feature will become available to you in the form of a "Port-mapped" mode after you activate Release 4.0 or higher on the ONS platform.
The benefit of the Linear Mapper, which can also be referred to as Port-mapped mode, is that it allows Ethernet traffic to be mapped directly onto the SONET/SDH circuit without passing through a layer 2 (L2) switching engine. Although the L2 switching capabilities of E-Series cards provide a much wider range of functionality than a simple L1 Ethernet-to-SONET/SDH mapping scheme, there are several characteristics unique to the E-Series card's L2 switching engine that may present limitations in some applications. Such limitations of the L2 switching engine on the E-Series card include:
Broadcast and Multicast rate limitation: Unicast packet loss can occur when Broadcast or Multicast traffic is present in the Ethernet circuit (for reference see Field Notice 13171).
Excessive Ethernet circuit down time when a protection switch or XTC switch occurs. This is due to the fact that each circuit must wait for Spanning Tree Protocol (STP) reconvergence, which can take several minutes.
Each card is limited to eight Spanning Tree instances, limiting the number of VLANs that can be provisioned from one card without implementing provisioning workarounds.
When you place the E-Series card in port-mapped mode, you can realize the following benefits:
•
•
•
•
Whether port-mapped mode is beneficial to your network or not depends on the particular application. Several applications may benefit more from the L2 features provided by Multi-card EtherSwitch Group mode and/or Single-card EtherSwitch mode. Use the guidelines above in combination with the user documentation to analyze your particular network and determine if port-mapped mode will improve performance.
Cisco offers other Ethernet data cards for the ONS 15454 and ONS 15327. These include the L1 Ethernet-to-SONET/SDH G-Series card and the L2/L3 switching ML-Series card. When choosing a data solution, each card family should be considered to ensure that you have achieved the most appropriate solution.
Graphical Display of Lockout
Release 4.0, offers a new, detailed graphical display of lockout conditions on a span. Prior to Release 4.0, there is no clear indication when a span that is locked out has been manually switched. In previous releases, these events are reported in the Conditions tab or as a non-reporting event in the alarm tab.
Graphical indications of a Lockout, Force, or Manual switch condition are displayed for the following schemes:
•
•
The graphical display of a condition can be viewed from the Network, Circuit and Detailed Circuit maps when a protection switch is applied.
Possible displayed values are:
•
•
•
•
Database Downgrade Protection
With Release 4.0, CTC prevents restoration of a database written by a software version newer than what the XTC is running. CTC issues a warning, but allows you to proceed, when reverting to an older software version.
For more specific details, consult the "Cisco ONS 15327 Reference Manual," Release 4.0.
Proxy Server Port Reduction
In previous releases, CTC was able to manage nodes behind routers that performed network address translation (NAT) but required that intermediate routers allow connections on many ports. Additionally, these intermediate routers needed to be configured to allow connections to be initiated from both CTC and the GNE. With Release 4.00, CTC can now manage nodes behind routers that perform NAT or port address translation (PAT). Intermediate routers need only be configured to allow connections from CTC to the GNE on ports 80 (HTTP) and 1080 (SOCKS) and packets for established connections from the GNE to CTC. The superuser can enable this functionality on the node level Provisioning > Network tab.
For more specific details, consult the "Cisco ONS 15327 Reference Manual," Release 4.0.
Ethernet Tx and Rx Utilization
The node view port utilization values for Release 4.0 now separate transmit values from receive values. This affords you a clearer picture of actual utilization levels in this view, even when levels are very small.
BLSR J1 CTC
In Release 4.0, several enhancements have been made to improve support for C2 and unmatched J1 path trace with BLSR protection switching. In summary, the following have been addressed.
In Release 4.0, CTC displays all unmatched J1 Path Trace detected and C2 byte, including:
•
•
•
•
•
•
This allows you to locate Path Trace Mismatch even for a switched BLSR circuit.
For more specific details, consult the "Cisco ONS 15327 Reference Manual," Release 4.0.
CTC Path Trace Alarm Support
In Release 4.0, after traffic has switched to a protection span, standard TIM-P alarms will be raised when there is a J1 mismatch detected on the switched STSs.
CTC NCP Display Enhancement
In Release 4.0, NCP is enhanced to support the display of a switched BLSR path, in addition to the working path. NCP is also enhanced to display alarms on the STSs where the switched BLSR path is, and allows you to monitor path trace on the switched BLSR path such that:
•
•
For more specific details, consult the "Cisco ONS 15327 Reference Manual," Release 4.0.
CTC PM Support
In Release 4.0, when traffic is switched from the working to the protection span, standard SONET and SDH Near End Path PM values are available over the protection span in the 2-fiber and 4-fiber BLSR.
For more specific details, consult the "Cisco ONS 15327 Reference Manual," Release 4.0.
New TL1 Features
The following TL1 features are new for release 4.0. For detailed instructions on using TL1 commands, consult the TL1 Command Guide for Release 4.0.
FTP Database Backup and Restore Support
The new FTP database backup/restore support feature allows you to back up and restore your database via FTP using the TL1 interface. The following commands support the FTP download functionality.
•
•
Security Enhancements
The following new commands have been added to enhance security.
•
•
•
•
•
The following additional features support security.
Configurable Timeouts
Timeouts are now configurable via CTC. CTC allows timeout values ranging from 0 to 16 hours and 39 minutes (999 minutes). A value of 0 means the timeout is to be treated as infinite (no timeout). The timeout configuration via CTC only applies to users who are not currently logged in. Users logged in when the timeout is changed continue to use the timeout that was in effect when they logged in until they logout. One session per user is now supported and is configurable via CTC. This means that a login will fail for a valid username/password combination if someone has already logged into the system using that combination. This restriction applies to both CTC and TL1. For instance, if a user is logged in using CTC, the TL1 ACT-USER command will be denied.
If you fail to log in to a node because of a correct userid and an incorrect password, that userid will be locked out after X tries, where X is configurable. You may remain locked out or may be re-admitted after a period of N seconds, where N is configurable. The default settings are X = 5 and N = 30, causing a short 30 second lockout after 5 failed attempts. During the lockout period, attempts to login with a valid username/password combination will be denied.
Configurable Password Features
Also configurable via CTC, but enforceable in TL1 are the following password enhancements.
Number of unusable password days and number of distinct passwords: When you change your password, the new password must differ from the previous X passwords that have been used in the last Y days. The defaults are X = 1 and Y = 20, which means that the new password cannot be the same as the current password. In this case, the Y days is unused because the current password is always in use. A setting of X = 2 and Y = 20 would mean that the new password cannot be the same as the current password and cannot be the same as the previous password unless the previous password has not been used for 20 days. A setting of X = 5 and Y = 30 would mean that the new password cannot be the same as the current password and cannot be the same as the other previous 4 passwords unless the other previous 4 passwords have not been used for 30 days.
Forcible logout: An administrator now has the capability to forcibly log out a user. The interface is via CTC only, but a TL1 user can be logged out too. If a TL1 user is logged out, the REPT^EVT^SESSION message will appear indicating the forced logout.
Cross-Connect Loopback
The following new commands support cross-connect loopbacks.
•
•
Active Path Determination
The RTRV-<STS_PATH> command has added UPSRPTHSTATE in its output to indicate the path state in cases where the STS path is the path of path protection.
Dual Ring Interconnect
The ENT-CRS-<STS_PATH> and ENT-CRS-VT1 commands now support the 2WAYDC connection type.
The ED-<STS_PATH>, RTRV-<STS_PATH>, and ED-VT1, RTRV-VT1 commands have added a new field, HOLDOFFTIMER.
Prompting Feature
A TL1 Prompting tool has been added. This feature is primarily for prompting options for command (VMM) and payload prompting. Other fields are mostly mandatory and user input is required for them.
Prompting can be invoked by entering "Ctrl-P."
The CTC-TL1 window does not support this feature.
If the prompting tool requires user input, a message "User Input Required" will be displayed. If the prompting tool is asked for fields that are not supported, a message "Field Not Supported" will be displayed.
Pattern Matching enables you to enter only the first few characters of a command, or only as many as is necessary to distinguish the command from others. The prompting tool will return a list of possible named parameters.
Prompting can be invoked for Named or Positional parameter blocks.
In a GNE to ENE scenario, the GNE prompts the user on behalf of the ENE.
Add or Drop a Cross Connect
The following new commands support adding or dropping a cross connect over a cross connection or a circuit via TL1.
•
•
J1 and C2 Support
As of Release 4.0, the C2 byte can be retrieved using the following commands. Also, J1 STS path trace can be provisioned on the protect STS path of a switched BLSR.
•
•
•
•
The RTRV-<STS_PATH> command adds a new input field, BLSRPTHTYPE, allowing you to retrieve the STS J1 path trace information on either the STS path of PCA circuits or the STS path of NON-PCA circuits.
The RTRV-<STS_PATH> command also adds a new output field, BLSRPTHSTATE.
Test Access
As of Release 4.0, PCA test access is supported. Creation of an STS (or VT) Test Access point on a protect channel of a two-fiber, or four-fiber BLSR is supported. Connecting to an STS or VT PCA circuit is also now supported.
Test access on a PCA will be preempted when a BLSR switch takes place.
Test Access Intrusive modes (splta, spltb, loope, loopf, splte, spltf, spltef) are allowed on circuits that are IS. The circuit state will be internally changed to OOS_MT during the period the connection is maintained. Test Access will then remember and restore the original circuit state once the connection is disabled via the DISC-TACC command or a session timeout.
Other New Commands Added
The following new command has been added for Release 4.0.
•
Changes in TL1 Functionality Since Release 3.4
AID Formats
The STS/VT path AID formats for optical cards (OCn, EC1) have been changed to add the port number between the slot number and the STS number. Format differences are as follows.
STS AID formats
Prior to Release 4.0, the optical card STS AID format is:
STS-SlotNumber-RealStsNumber
As of Release 4.0, the new format is:
STS-SlotNumber-PortNumber-RelativeStsNumber
VT AID formats
Prior to Release 4.0, the optical card VT AID format is:
VT1-SlotNumber-RealStsNumber-VtGroupNumber-RelativeVtNumber
As of Release 4.0, the new format is:
VT1-SlotNumber-PortNumber-RelativeStsNumber-VtGroupNumber-RelativeVtNumber
Security Enhancements
Additional autonomous messages are reported via the REPT^EVT^SECU message in Release 4.0.
The new messages, available to Superusers only, are:
•
•
•
•
•
•
•
•
•
•
Changes to Change Reporting
Change reporting in Release 4.0 adds the following new support:
•
•
•
•
New Conditions
The following new conditions have been added as of Release 4.0.
•
•
•
•
Minor Changes
The following minor changes have been made to TL1 commands for Release 4.0.
•
•
•
TL1 Syntax Changes Since Release 3.4
Command Syntax Changes
In the following section the Release 3.4 command is listed first, followed by the new Release 4.0 command.
ED-CRS-<STS_PATH> syntax changed:
ED-CRS-<STS_PATH>[:<TID>]:<src>,<dst>:<CTAG>::::<pst>,[<sst>];
ED-CRS-<STS_PATH>[:<TID>]:<src>,<dst>:<CTAG>[:::<dmode>=<drop>]:<pst>,[<sst>];
ED-CRS-VT1 syntax changed:
ED-CRS-VT1[:<TID>]:<src>,<dst>:<CTAG>::::<pst>,[<sst>];
ED-CRS-VT1[:<TID>]:<src>,<dst>:<CTAG>[:::<dmode>=<drop>]:<pst>,[<sst>];
ED-G1000 syntax changed:
ED-G1000[:<TID>]:<aid>:<CTAG>[:::MFS=<mfs>,][FLOW=<flow>,][SOAK=<soak>][:<pst>,][<sst>];
ED-G1000[:<TID>]:<aid>:<CTAG>[:::MFS=<mfs>,][FLOW=<flow>][:<pst>,][<sst>];
ED-<STS_PATH> syntax changed:
ED-<STS_PATH>[:<TID>]:<aid>:<CTAG>[:::SFBER=<sfber>,][SDBER=<sdber>,][RVRTV=<rvrtv>,][RVTM=<rvtm>,][SWPDIP=<swpdip>,][EXPTRC=<exptrc>,][TRC=<trc>,][TRCMODE=<trcmode>,][TACC=<tacc>][:<pst>,][<sst>];
ED-<STS_PATH>[:<TID>]:<aid>:<CTAG>[:::SFBER=<sfber>,][SDBER=<sdber>,][RVRTV=<rvrtv>,][RVTM=<rvtm>,][SWPDIP=<swpdip>,][HOLDOFFTIMER=<holdofftimer>,][EXPTRC=<exptrc>,][TRC=<trc>,][TRCMODE=<trcmode>,][TACC=<tacc>][:<pst>,][<sst>];
ED-VT1 syntax changed:
ED-VT1[:<TID>]:<aid>:<CTAG>[:::RVRTV=<rvrtv>,][RVTM=<rvtm>,][TACC=<tacc>][:<pst>,][<sst>];
ED-VT1[:<TID>]:<aid>:<CTAG>[:::RVRTV=<rvrtv>,][RVTM=<rvtm>,][HOLDOFFTIMER=<holdofftimer>,][TACC=<tacc>][:<pst>,][<sst>];
Response Changes of TL1 Commands
In the following section the Release 3.4 response is listed first and the new Release 4.0 response is listed second:
RTRV-ALM-ALL response changes:
[<aid>],[<aidtype>]:<ntfcncde>,<condtype>,<srveff>,,,,:[<desc>],[<aiddet>]
[<aid>],[<aidtype>]:<ntfcncde>,<condtype>,<srveff>,<ocrdat>,<ocrtm>,,:[<desc>],[<aiddet>]
RTRV-ALM-BITS response changes:
<aid>,[<aidtype>]:<ntfcncde>,<condtype>,<srveff>,,,,:[<desc>],
<aid>,[<aidtype>]:<ntfcncde>,<condtype>,<srveff>,[<ocrdat>],[<ocrtm>],,:[<desc>],
RTRV-ALM-ENV response changes:
<aid>:<ntfcncde>,<almtype>,,,[<desc>]
<aid>:<ntfcncde>,<almtype>,[<ocrdat>],[<ocrtm>],[<desc>]
RTRV-ALM-EQPT response changes:
[<aid>],[<aidtype>]:<ntfcncde>,<condtype>,<srveff>,[<stringValue>],[<stringValue1>],,:[<desc>],
[<aid>],[<aidtype>]:<ntfcncde>,<condtype>,<srveff>,[<ocrdat>],[<ocrtm>],[<stringValue>],:[<desc>],
RTRV-ALM-RING response changes:
<aid>:<ntfcncde>,<condtype>,<srveff>,,,,:[<desc>],
<aid>:<ntfcncde>,<condtype>,<srveff>,[<ocrdat>],[<ocrtm>],,:[<desc>],
RTRV-ALM-SYNCN response changes:
<aid>,[<aidtype>]:<ntfcncde>,<condtype>,<srveff>,,,,:[<desc>],
<aid>,[<aidtype>]:<ntfcncde>,<condtype>,<srveff>,[<ocrdat>],[<ocrtm>],,:[<desc>],
RTRV-ALM-UCP response changes:
<aid>:<ntfcncde>,<condtype>,<srveff>,,,,:[<desc>],
<aid>:<ntfcncde>,<condtype>,<srveff>,[<ocrdat>],[<ocrtm>],,:[<desc>],
RTRV-ALM-VT1 response changes
<aid>,[<aidtype>]:<ntfcncde>,<condtype>,<srveff>,[<stringValue>],[<stringValue1>],[<stringValue2>],[<stringValue3>]:[<desc>],
<aid>,[<aidtype>]:<ntfcncde>,<condtype>,<srveff>,[<ocrdat>],[<ocrtm>],[<stringValue>],[<stringValue1>]:[<desc>],
RTRV-COND-ALL response changes:
<aid>,[<aidtype>]:[<ntfcncde>],<typerep>,[<srveff>],,,,,[<desc>]
<aid>,[<aidtype>]:[<ntfcncde>],<typerep>,[<srveff>],[<ocrdat>],[<ocrtm>],,,[<desc>]
RTRV-COND-BITS response changes:
<aid>,[<aidtype>]:[<ntfcncde>],<typerep>,[<srveff>],,,,,[<desc>]
<aid>,[<aidtype>]:[<ntfcncde>],<typerep>,[<srveff>],[<ocrdat>],[<ocrtm>],,,[<desc>]
RTRV-COND-ENV response changes:
<aid>:<ntfcncde>,<almtype>,,,,,,[<desc>]
<aid>:<ntfcncde>,<almtype>,[<ocrdat>],[<ocrtm>],,,,[<desc>]
RTRV-COND-EQPT response changes:
<aid>,[<aidtype>]:[<ntfcncde>],<typerep>,[<srveff>],,,,,[<desc>]
<aid>,[<aidtype>]:[<ntfcncde>],<typerep>,[<srveff>],[<ocrdat>],[<ocrtm>],,,[<desc>]
RTRV-COND-RING response changes:
<aid>:[<ntfcncde>],<typerep>,[<srveff>],,,,,[<desc>],
<aid>:[<ntfcncde>],<typerep>,[<srveff>],[<ocrdat>],[<ocrtm>],,,[<desc>],
RTRV-COND-SYNCN response changes:
<aid>,[<aidtype>]:[<ntfcncde>],<typerep>,[<srveff>],,,,,[<desc>]
<aid>,[<aidtype>]:[<ntfcncde>],<typerep>,[<srveff>],[<ocrdat>],[<ocrtm>],,,[<desc>]
RTRV-COND-UCP response changes:
<aid>:[<ntfcncde>],<typerep>,[<srveff>],,,,,[<desc>],
<aid>:[<ntfcncde>],<typerep>,[<srveff>],[<ocrdat>],[<ocrtm>],,,[<desc>],
RTRV-COND-VT1 response changes:
<aid>,[<aidtype>]:[<ntfcncde>],<typerep>,[<srveff>],,,,,[<desc>]
<aid>,[<aidtype>]:[<ntfcncde>],<typerep>,[<srveff>],[<ocrdat>],[<ocrtm>],,,[<desc>]
RTRV-EQPT response changes:
<aid>:<aidtype>,<equip>,[<role>],[<status>]:[<protid>],[<prtype>],[<rvrtv>],[<rvtm>],[<cardname>]:[<pst>],[<sst>]
<aid>:<aidtype>,<equip>,[<role>],[<status>]:[<protid>],[<prtype>],[<rvrtv>],[<rvtm>],[<cardname>],[<ioscfg>]:[<pst>],[<sst>]
RTRV-INV response changes:
<aid>,<aidtype>::[<pn>],[<hwrev>],[<fwrev>],[<sn>],[<clei>]
<aid>,<aidtype>::[<pn>],[<hwrev>],[<fwrev>],[<sn>],[<clei>],[<dwl=nwl in code>],[<twl1= wl1 in code>],[<twl2=wl2 in code>],[<twl3=wl3 in code>]
RTRV-NE-GEN response changes:
[<ipaddr>],[<ipmask>],[<defrtr>],[<iiopport>],[<ntp>],[<name>],[<swver>],[<load>],[<protswver>],[<protload>],[<defdesc>]
[<ipaddr>],[<ipmask>],[<defrtr>],[<iiopport>],[<ntp>],[<name>],[<swver>],[<load>],[<protswver>],[<protload>],[<defdesc>],[<platform>]
RTRV-PMSCHED-ALL response changes:
<aid>,[<aidtype>]:<reptinvl>,<reptdat>,<repttm>,[<numinvl>],[<montype>],[<monlev>],<locn>,[<dirn>],[<tmper>],[<inhmode>]
<aid>,[<aidtype>]:<reptinvl>,<reptdat>,<repttm>,[<numinvl>],[<montype>],[<monlev>],<locn>,[<dirn>],[<tmper>],<tmofst>,[<inhmode>]
RTRV-PMSCHED-<MOD2> response changes:
<aid>,[<aidtype>]:<reptinvl>,<reptdat>,<repttm>,[<numinvl>],[<montype>],[<monlev>],<locn>,[<dirn>],[<tmper>],[<inhmode>]
<aid>,[<aidtype>]:<reptinvl>,<reptdat>,<repttm>,[<numinvl>],[<montype>],[<monlev>],<locn>,[<dirn>],[<tmper>],<tmofst>,[<inhmode>]
RTRV-<STS_PATH> syntax changed:
RTRV-<STS_PATH>[:<TID>]:<aid>:<CTAG>[::::];
RTRV-<STS_PATH>[:<TID>]:<aid>:<CTAG>[:::BLSRPTHTYPE=<blsrpthtype>][:];
RTRV-<STS_PATH> response changes:
<aid>::[<level>],[<sfber>],[<sdber>],[<rvrtv>],[<rvtm>],[<swpdip>],[<exptrc>],[<trc>],[<inctrc>],[<trcmode>],[<tacc>]:[<pst>],[<sst>]
<aid>::[<level>],[<sfber>],[<sdber>],[<rvrtv>],[<rvtm>],[<swpdip>],[<holdofftimer>],[<exptrc>],[<trc>],[<inctrc>],[<trcmode>],[<tacc>],[<upsrpthstate>],[<c2>],[<blsrpthstate>]:[<pst>],[<sst>]
RTRV-VT1 response changes:
<aid>::[<rvrtv>],[<rvtm>],[<tacc>]:[<pst>],[<sst>]
<aid>::[<rvrtv>],[<rvtm>],[<holdofftimer>],[<tacc>],[<upsrpthstate>]:[<pst>],[<sst>]
SCHED-PMREPT-<MOD2> syntax changed:
SCHED-PMREPT-DS1[:<TID>]:<aid>:<CTAG>[::<reptinvl>,][<reptstatm>,][<numrept>],,[<monlev>,][<locn>],,[<tmper>][,];
SCHED-PMREPT-DS1[:<TID>]:<aid>:<CTAG>[::<reptinvl>,][<reptstatm>,][<numrept>],,[<monlev>,][<locn>],,[<tmper>,][<tmofst>];
ENUM Changes to TL1 Since Release 3.4
ENUM Value Changes for Existing Commands
ENUM Value Changes for ENT-CRS-<STS_PATH>, ENT-CRS-VT1, RTRV-CRS, RTRV-CRS-<STS_PATH>, and RTV-CRS-VT1
The CCT enum has added the following item in Release 4.0:
•
ENUM Value Changes for RTRV-CRS
The CRS_TYPE enum has added the following 8 items in Release 4.0:
•
•
•
•
•
•
•
ENUM Value Changes for ED-T3 and RTRV-T3
The DS_LINE_TYPE enum has changed the following 2 items for Release 4.0:
•
•
ENUM Value Changes for RTRV-PM-<MOD2>, RTRV-PM-VT1, RTRV-TH-<MOD2>, RTRV-TH-VT1, and SET-TH-<MOD2>
ALL_MONTYPE enums have added the following 83 items in Release 4.0:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
ENUM Value Changes for REPT^EVT
The ALL_THR enum has added the following 46 items in Release 4.0:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
The ALM_THR enum has added the following 9 items in Release 4.0:
•
•
•
•
•
•
•
•
•
ENUM Value Changes for RTRV-G1000
Note
The FLOW enum has added the following 2 items in Release 4.0:
•
•
•
•
•
•
ENUM Value Changes for OPR-LPBK-<MOD2>, RLS-LPBK-<MOD2>, RTRV-PM-<MOD2>, RTRV-PMSCHED-ALL, RTRV-PMSCHED-<MOD2>, RTRV-TH-<MOD2>, and SET-TH-<MOD2>
The MOD2 enum has added the following 4 items in Release 4.0:
•
•
•
•
ENUM Value Changes for RTRV-ALM-<MOD2ALM> and RTRV-COND-<MOD2ALM>
The MOD2ALM enum has added the following 7 items in Release 4.0:
•
•
•
•
•
•
•
ENUM Value Changes for ED-BITS, RTRV-BITS and RTRV-SYNCN
The SYNC_CLOCK_REG_QUALITY_LEVEL enum has added the following 7 items in Release 4.0:
•
•
•
•
ENUM Value Changes for ED-NE-SYNCN and RTRV-NE-SYNCN
The SYNC_CLOCK_LEVEL enum has added the following 7 items in Release 4.0:
ABOVE-G811
ABOVE-G12L
ABOVE-G12T
ABOVE-SETS
BELOW-SETS
Enum Table Changes for Existing TL1 Commands Since Release 3.4
ENUM Value Changes for RTRV-<STS_PATH>
The BLSR_PTH_STATE enum type has been added into the RTRV-<STS_PATH> command output format with the following 5 items in Release 4.0:
•
•
•
•
•
ENUM Value Changes for RTRV-<STS_PATH>
The BLSR_PTH_TYPE enum has been added into the RTRV-<STS_PATH> command input syntax with the following 2 items in Release 4.0:
•
•
The DIRN enum has been dropped in Release 4.0. DIRN is UNUSED in any command.
The DS3_FMT enum has been dropped in Release 4.0. DS3_FMT is UNUSED in any command.
The ENV_CRTL_MODE enum has been dropped in Release 4.0. ENV_CRTL_MODE is UNUSED in any command.
The EXT_RING enum has been dropped in Release 4.0. EXT_RING is UNUSED in any command.
The MODIFIER enum has been dropped in Release 4.0. MODIFIER is UNUSED in any command.
ENUM Value Changes for REPT^RMV^<MOD_IO> and REPT^RST^<MOD_IO>
The MOD2_IO enum has added the following 4 items in Release 4.0:
•
•
•
•
The STM_TYPE enum has been dropped in Release 4.0. STM_TYPE is UNUSED in any command.
The TMG_REF enum has been dropped in Release 4.0. TMG_REG is UNUSED in any command.
The USE_DST enum has been dropped in Release 4.0. USE_DST is UNUSED in any command.
Enum Changes For New Commands in Release 4.0
ENUM Value Changes for ED-CLNT, ED-OCH, RTRV-CLNT, and RTRV-OCH
The ALS_MODE enum type has added the following 4 items in Release 4.0:
•
•
•
•
ENUM Value Changes for ED-CLNT, ED-OCH, RTRV-CLNT, and RTRV-OCH
The COMM_TYPE enum has added the following 3 items in Release 4.0:
•
•
•
ENUM Value Changes for RTRV-FSTE and RTRV-GIGE
The ETHER_DUPLEX enum has added the following 3 items in Release 4.0:
•
•
•
ENUM Value Changes for RTRV-FSTE and RTRV-GIGE
The ETHER_SPEED enum has added the following 5 items in Release 4.0:
•
•
•
•
•
ENUM Value Changes for RTRV-FSTE, RTRV-G1000, and RTRV-GIGE
The FLOW enum has added the following 4 items in Release 4.0:
•
•
•
•
ENUM Value Changes for ED-OCH and RTRV-OCH
The GCCRATE enum has been added the following 2 items in Release 4.0:
•
•
ENUM Value Changes for RTRV-GIGE, RTRV-G1000
The OPTICS enum has added the following 4 items in Release 4.0:
•
•
•
•
ENUM Value Changes for ENT-FFP-CLNT and RTRV-FFP-CLNT
The PROTTYPE enum has added the following item in Release 4.0:
•
ENUM Value Changes for ED-OCH and RTRV-OCH
The RDIRN_MODE enum has added the following 2 items in Release 4.0:
•
•
ENUM Value Changes for COPY-RFILE
The RFILE enum has added the following 2 items in Release 4.0:
•
•
ENUM Value Changes for ED-DWDM and RTRV-DWDM
The TERM_MODE enum has added the following 3 items in Release 4.0:
•
•
•
ENUM Value Changes for ED-TRC-OCH and RTRV-TRC-CLNT
The TRCFORMAT enum has added the following 3 items in Release 4.0:
•
•
•
ENUM Value Changes for ED-TRC-CLNT, ED-TRC-OCH, RTRV-TRC-CLNT, and RTRV-TRC-OCH
The TRCLEVEL enum has added the following 5 items in Release 4.0:
•
•
•
•
•
ENUM Value Changes for RTRV-FSTE, RTRV-GIGE, and RTRV-POS
The UP_DOWN enum has added the following 2 items in Release 4.0:
•
•
ENUM Value Changes for ED-OCH and RTRV-OCH
The VOA_STATE enum has added the following 2 items in Release 4.0:
•
•
Related Documentation
Release-Specific Documents
•
•
•
•
Platform-Specific Documents
•
•
•
•
•
Obtaining 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:
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://www.cisco.com/register/
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.
CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, the Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing, FormShare, iQ Breakthrough, iQ FastTrack, the iQ Logo, iQ Net Readiness Scorecard, Networking Academy, ScriptShare, SMARTnet, TransPath, and Voice LAN are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, The Fastest Way to Increase Your Internet Quotient, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, LightStream, MGX, MICA, the Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast, StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.
All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0301R)
Copyright © 2003, Cisco Systems, Inc.
All rights reserved.
