Configuring Splitter Protection and Line Card Protection with APS

Table Of Contents

Configuring Splitter Protection and Line Card Protection with APS

About APS

About Splitter Protection

Considerations for Using Splitter Protection

Configuring Splitter Protection

Displaying the Splitter Protection Configuration

About Line Card Protection

Considerations for Using Line Card Protection

Configuring Line Card Protection

Configuring Y-Cable Protection

Configuring Splitter Protected Line Card Motherboards for Line Card Protection

About Path Switching

Configuring Path Switching

Changing the Path Switching Direction for Y-Cable Protection

Displaying the Path Switching Configuration

Switchovers and Lockouts

Y-Cable Protection APS Priority Scheme

Splitter Protection APS Priority Scheme

Requesting a Switchover

Requesting a Lockout

Clearing Switchover and Lockout Requests

Configuring Splitter Protection and Line Card Protection with APS

This chapter describes how to configure splitter protection and line card protection with APS (Automatic Protection Switching). This chapter contains the following sections:

• About APS

• About Splitter Protection

• Configuring Splitter Protection

• About Line Card Protection

• Configuring Line Card Protection

• About Path Switching

• Configuring Path Switching

• Switchovers and Lockouts

About APS

APS provides protection against signal transmission failure. The Cisco ONS 15540 supports the following APS features:

•1+1 path protection

•Splitter protection

•Line card protection

•Bidirectional and unidirectional path switching

The 1+1 path protection acrhitecture transmits the client signal on both the working and protection paths.

Note For an animated description of the APS implementation on the Cisco ONS 15540, go to the following URL:

http://www.cisco.com/mm/dyngraph/APS15540.html

About Splitter Protection

Splitter protection on the Cisco ONS 15540 provides protection against facility failure, such as trunk fiber cuts, but not transponder module failures or client equipment failures. Splitter protection internally replicates the client optical signal received from the transponder module and transmits it to mux/demux modules in both slot 0 and slot 1 (see Figure 5-1).

Figure 5-1 Splitter Protection Scheme

On the trunk side, a fiber pair, with one receive fiber and one transmit fiber, connects to one mux/demux module in slot 0. Another trunk fiber pair connects to a mux/demux module in slot 1. The client signal is transmitted through both mux/demux modules to the trunk fiber pairs. A 2 x 2 switch on the line card motherboard receives both signals from the trunk fiber pairs and selects one as the active signal. When a signal failure is detected, the 2 x 2 switch switches over to the standby signal. The standby signal then becomes the active signal.

Considerations for Using Splitter Protection

The following considerations apply when considering the use of splitter protection:

•Each subcard position in the splitter protected line card motherboard corresponds to a specific subcard position in both of the mux/demux motherboards in slots 0 and 1.

For detailed information on backplane connectivity, refer to the
Cisco ONS 15540 ESP Planning and Design Guide.

•Splitter protection does not protect against failure in the transponder module, where the lasers are located. Splitter protection also does not protect against failure of the client equipment.

To protect against transponder module failure, use y-cable protection as described in the "About Line Card Protection" section and the "Configuring Line Card Protection" section. To protect against both transponder module failure and client failure, implement protection on the client equipment instead.

•A fully configured system can support 32 channels in splitter protection mode.

•Splitter protection is nonrevertive. After correcting the problem that caused the signal failure and verifying the signal quality, you must manually switch the signal over to begin using the former working path. Use optical testing equipment to verify the signal quality. For more information on troubleshooting signal failures and restoring connectivity, refer to the
Cisco ONS 15540 ESP Troubleshooting Guide.

•For interfaces with either Sysplex ETR or Sysplex CLO protocol encapsulation, configure bidirectional path switching to ensure proper functioning of the protocol.

For detailed information on shelf configuration rules, refer to the
Cisco ONS 15540 ESP Planning and Design Guide.

Configuring Splitter Protection

The following steps describe the tasks required to configure splitter protection:

Step 1 Determine the number of clients you need to support and which channels you will deploy to transport client data.

Step 2 Ensure that the correct transponder modules are inserted in the line card motherboards in slots 2 through 5 and 8 through 11.

Step 3 Ensure that the mux/demux modules needed to support the deployed channels are inserted in the correct subcards of the mux/demux motherboards.

For each band of four or eight channels, you need a mux/demux module in the correct subcard position in the mux/demux motherboard in slot 0 and in the same subcard position in the mux/demux motherboard in slot 1.

For detailed information on hardware configuration rules, refer to the
Cisco ONS 15540 ESP Planning and Design Guide.

Step 4 Ensure that the add/drop mux/demux modules are correctly interconnected with the external optical patch cables.

Step 5 Configure APS from the CLI (command-line interface).

Caution Laser safety control interrupts signal transmission with splitter protected configurations. If you configure the system with splitter protection and enable laser safety control, the transmit laser to the client shuts down when an open fiber occurs on one transport fiber and signal transmission to the client is interrupted.

To enable splitter protection, use the following commands, beginning in global configuration mode:

Command

Purpose

Step 1

Switch(config)# redundancy

Switch(config-red)#

Enters redundancy configuration mode.

Step 2

Switch(config-red)# associate interface wavepatch */*/working-interface wavepatch */*/protection-interface [enable | disable]

or

Switch(config-red)# associate interface wavepatch slot/*/working-interface wavepatch slot/*/protection-interface [enable | disable]

Configures APS splitter protection mode on the entire chassis. The default state is disabled.

or

Configures APS splitter protection mode on the interfaces in a slot. The default state is disabled.

Note The prompt stays in redundancy mode when the interface identifiers contain wildcards. To configure an individual interface pair, continue to the next step.

Step 3

Switch(config-red)# associate group name

Switch(config-red-aps)#

Specifies an APS group name and enters APS configuration mode.

Note The group name is case sensitive.

Step 4

Switch(config-red-aps)# aps disable

Disables APS activity between the interfaces.

Note For newly created APS groups, APS activity is disabled by default.

Step 5

Switch(config-red-aps)# aps working wavepatch slot/subcard/port

Configures the working path interface.

Step 6

Switch(config-red-aps)# aps protection wavepatch slot/subcard/port

Configures the protection path interface.

Step 7

Switch(config-red-aps)# aps timer search-for-up minimum maximum

Changes the interval times for the search-for-up timer. If both wavepatch interfaces are down, or the wave interface is down, the system first checks one wavepatch connection, starting at the minimum interval, then the other wavepatch connection, until one of the connections comes up. The default minimum starting interval is 2 seconds and the default maximum interval is 32 seconds.

Step 8

Switch(config-red-aps)# aps timer switchover min-interval seconds

Changes the interval times for the successive switchover timer. The default interval is 2 seconds.

Step 9

Switch(config-red-aps)# aps enable

Enables APS activity between the interfaces.

Examples

This example shows how to associate all the wavepatch interfaces in the shelf for splitter protection and enable APS activity.
Switch# configure terminalSwitch(config)# redundancySwitch(config-red)# associate interface wavepatch */*/0 wavepatch */*/1 enableSwitch(config-red)#

This example shows how to associate all the wavepatch interfaces in slot 2 for splitter protection and enable APS activity.
Switch# configure terminalSwitch(config)# redundancySwitch(config-red)# associate interface wavepatch 2/*/0 wavepatch 2/*/1 enableSwitch(config-red)#

This example shows how to associate wavepatch interfaces for the transponder module in slot 3 and subcard 0 for splitter protection and modify the default attribute settings.
Switch# configure terminalSwitch(config)# redundancySwitch(config-red)# associate group dallas1Switch(config-red-aps)# aps working wavepatch 3/0/0Switch(config-red-aps)# aps protection wavepatch 3/0/1Switch(config-red-aps)# aps timer search-for-up 5 40Switch(config-red-aps)# aps enable
Displaying the Splitter Protection Configuration

To display the splitter protection configuration, use the following EXEC commands:

Command

Purpose

show aps

Displays the APS configuration summary.

show aps {detail | group name | interface wavepatch slot/subcard/port}

Displays detailed APS configuration information for groups and interfaces.

Note Group names are case sensitive.

Example

The following example shows how to display the APS splitter protection configuration:
Switch# show aps
AR : APS Role, Wk: Working, Pr: ProtectionAS : APS State, Ac: Active, St: StandbyIS : Interface State, Up: Up, Dn: DownMPL: Minimum Protection Level, SD: Signal Degrade, SF: Signal FailureLOL: Loss of Light, - not currently protected
Interface AR AS IS MPL Redundant Intf Group Name~~~~~~~~~~~~~~~~~ ~~ ~~ ~~ ~~~ ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~Wavepatch5/3/0 Wk St Up Wavepatch5/3/1 SeattleWavepatch5/3/1 Pr Ac Up LOL Wavepatch5/3/0 Seattle
Switch# show aps detail
APS Group Seattle :
architecture.: 1+1, remote prov: 1+1span.........: end-to-end (network side splitter)direction....: prov: uni, current: uni, remote prov: unirevertive....: nocreated......: 14 hours, 54 minutesaps state....: associated (enabled)request timer: holddown: 5000 ms, max: 15000 ms, count 2search-up int: min: 2 secs, max: 32 secsswitched chan: 1channel ( 0): Wavepatch5/3/1 (ACTIVE - UP): channel request: no-request: transmit request: do-not-revert: receive request: no-requestchannel ( 1): Wavepatch5/3/0 (STANDBY - UP): channel request: do-not-revert: switchover count: 1: last switchover: 14 hours, 54 minutes
About Line Card Protection

Line card protection on the Cisco ONS 15540 provides protection against both facility failures and transponder module failures. With line card protection, the client equipment sends identical signals to two separate transponder modules on the Cisco ONS 15540. The client equipment itself duplicates the signal on two separate connects or it uses a y-cable. On the Cisco ONS 15540, the signal from one of the transponder modules crosses the optical backplane to a mux/demux module in slot 0; the signal from the other transponder module crosses the optical backplane to a mux/demux module in slot 1(see Figure 5-2).

Figure 5-2 Line Card Protection Scheme

The Cisco ONS 15540 supports two types of line card protection, client protection and y-cable protection. In client protection mode, both signals are transmitted to the client system. The client system decides which signal to use and when to switch over.

Note Client protection does not require APS configuration on the Cisco ONS 15540.

With y-cable protection, the signal from only one of the transparent interfaces is transmitted to the client. The Cisco ONS 15540 turns on the laser at the active transparent interface, and turns off the laser on the standby transparent interface. At each receiver on the trunk side of the transponder module, the system monitors the optical signal power level. If the system detects a failure of the active signal when an acceptable signal exists on the standby transponder module, a switchover to the standby signal occurs by turning off the active transmitter at the client interface and turning on the standby transmitter.

Considerations for Using Line Card Protection

The following considerations apply when considering the use of line card protection:

•Each subcard position in an unprotected line card motherboard corresponds to a specific subcard position in one of mux/demux motherboards. If the line card motherboard supports the "west direction," the signal is transmitted to slot 0. If the line card motherboard supports the "east direction," the signal is transmitted to slot 1.

•Y-cable line card protection does not protect against failures of the client equipment. To protect against client failures, ensure that protection is implemented on the client equipment itself.

•A fully provisioned single shelf configuration can support 16 channels in line card protection mode. A fully provisioned dual shelf configuration can support 32 channels in line card protection mode.

For more information about dual shelf nodes, see "Configuring Dual Shelf Nodes"

•Y-cable line card protection supports revertive APS switching. With revertive behavior, the signal automatically switches back to the working path after the signal failure has been corrected, the wait-to-restore timer has expired, and no other switchover requests have occurred before the wait-to-restore timer has expired. The default switching behavior is nonrevertive.

For information on switchover requests, see the "Requesting a Switchover" section.

•To simplify system management, terminate the client signal on two transponder modules of the same channel. In this way the client signal maps to the same WDM wavelength on both the working and protection paths.

•For interfaces with either Sysplex ETR or Sysplex CLO protocol encapsulation, configure bidirectional path switching to ensure proper functioning of the protocol.

Caution Do not configure y-cable protection with Sysplex CLO, Sysplex ETR, or ISC compatibility protocol encapsulation, or with the OFC safety protocol.

Proper physical configuration of the system is critical to the operation of line card protection. For detailed information on shelf configuration rules, refer to the
Cisco ONS 15540 ESP Planning and Design Guide.

Configuring Line Card Protection

The following is an overview of the tasks required to configure line card protection:

Step 1 Determine the number of clients you need to support and which channels you will deploy to transport the client data.

Step 2 Ensure that the mux/demux modules needed to support the deployed channels are inserted in the correct subcards of the mux/demux motherboards; also ensure that the appropriate subcard positions in the mux/demux motherboards are depopulated. (See the "Considerations for Using Line Card Protection" section.)

Step 3 Ensure that the mux/demux modules are correctly interconnected with the external optical patch cables.

Step 4 Shut down the wavepatch interfaces connecting to the unused mux/demux motherboard if you are using splitter protected line card motherboards.

Step 5 Configure y-cable protection from the CLI. If your client equipment manages the signal switchover, no CLI configuration is necessary on the Cisco ONS 15540.

Configuring Y-Cable Protection

Y-cable protection on the Cisco ONS 15540 requires configuration on the CLI. To configure y-cable protection, use the following commands, beginning in global configuration mode:

Command

Purpose

Step 1

Switch(config)# redundancy

Switch(config-red)#

Enters redundancy configuration mode.

Step 2

Switch(config-red)# associate group name

Switch(config-red-aps)#

Specifies an APS group name and enters APS configuration mode.

The group name is case sensitive.

Step 3

Switch(config-red-aps)# aps disable

Disables APS activity between the interfaces.

For newly associated pairs, APS activity is disabled by default.

Step 4

Switch(config-red-aps)# aps working transparent slot/subcard/port

Configures the working path interface.

Step 5

Switch(config-red-aps)# aps protection transparent slot/subcard/port

Configures the protection path interface.

Step 6

Switch(config-red-aps)# aps y-cable

Enables y-cable protection. The default state is no y-cable protection (disabled).

Step 7

Switch(config-red-aps)# aps revertive

Enables revertive switchover behavior. The default behavior is nonrevertive.

Step 8

Switch(config-red-aps)# aps timer wait-to-restore seconds

Modifies the interval for the wait-to-restore timer. If revertive protection is configured and a switchover has occurred, the system will wait this amount of time before switching back to the functioning working path. The default value is 300 seconds.

Step 9

Switch(config-red-aps)# aps enable

Enables APS activity between the interfaces.

Note Configure both nodes that add and drop the channel with the same revertive behavior.

Caution Do not configure y-cable protection with Sysplex CLO, Sysplex ETR, or ISC compatibility protocol encapsulation, or with the OFC safety protocol.

Example

This example shows how to associate two transparent interfaces for y-cable line card protection with revertive switchover behavior:
Switch# configure terminalSwitch(config)# redundancySwitch(config-red)# associate group blueSwitch(config-red-aps)# aps working transparent 3/0/0Switch(config-red-aps)# aps protection transparent 5/0/0Switch(config-red-aps)# aps revertiveSwitch(config-red-aps)# aps y-cableSwitch(config-red-aps)# aps enable
Displaying the Y-Cable Protection Configuration

To display the y-cable protection configuration, use the following EXEC commands:

Command

Purpose

show aps

Displays the APS configuration summary.

show aps {detail | group name | interface {transparent slot/subcard/0 | wavepatch slot/subcard/port}}

Displays detailed APS configuration information for interfaces and groups.

Note Group names are case sensitive.

Example

The following example shows how to display the y-cable protection for an APS group named blue:
Switch# show apsAR : APS Role, Wk: Working, Pr: ProtectionAS : APS State, Ac: Active, St: StandbyIS : Interface State, Up: Up, Dn: DownMPL: Minimum Protection Level, SD: Signal Degrade, SF: Signal FailureLOL: Loss of Light, - not currently protected
Interface AR AS IS MPL Redundant Intf Group Name~~~~~~~~~~~~~~~~~ ~~ ~~ ~~ ~~~ ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~Transparent2/3/0 Wk Ac Up SD Transparent4/3/0 YosemiteTransparent4/3/0 Pr St Up Transparent2/3/0 Yosemite
Switch# show aps group Yosemite
APS Group Yosemite :architecture.: 1+1, remote prov: 1+1span.........: end-to-end (client side y-cable)direction....: prov: uni, current: uni, remote prov: birevertive....: nocreated......: 14 hours, 53 minutesaps state....: associated (enabled)request timer: holddown: 5000 ms, max: 15000 ms, count 2switched chan: 0channel ( 0): Transparent4/3/0 (STANDBY - UP), Wave4/3 (UP): channel request: no-request: transmit request: no-request: receive request: no-requestchannel ( 1): Transparent2/3/0 (ACTIVE - UP), Wave2/3 (UP): channel request: no-request: switchover count: 0: last switchover: never
Configuring Splitter Protected Line Card Motherboards for Line Card Protection

Normally, you would use unprotected line card motherboards for line card protection configurations. However, you can use splitter protected line card motherboards instead by shutting down the wavepatch interfaces to one of the mux/demux motherboards.

To configure line card protection on splitter protected line card motherboards, use the following commands, beginning in global configuration mode:

Command

Purpose

Step 1

Switch(config)# interface wavepatch slot/subcard/port

Switch(config-if)#

Selects the wavepatch interface to configure and enters interface configuration mode.

Step 2

Switch(config-if)# shutdown

Disables the wavepatch interface.

Step 3

Switch(config-if)# exit

Switch(config)#

Returns to global configuration mode.

Repeat Step 1 through Step 3 for one wavepatch interface per wavepatch pair on splitter protected line card motherboards.

Examples

For the following examples, assume that the line card motherboards shown in Figure 5-2 have splitter protection.

The following example shows how to disable all wavepatch interfaces on the line card motherboard in slot 2 that connect to the mux/demux motherboard in slot 1:
Switch(config)# interface wavepatch 2/0/1Switch(config-if)# shutdownSwitch(config-if)# exitSwitch(config)# interface wavepatch 2/1/1Switch(config-if)# shutdownSwitch(config-if)# exitSwitch(config)# interface wavepatch 2/2/1Switch(config-if)# shutdownSwitch(config-if)# exitSwitch(config)# interface wavepatch 2/3/1Switch(config-if)# shutdownSwitch(config-if)# exitSwitch(config)#

The following example shows how to disable all wavepatch interfaces on the line card motherboard in slot 4 that connect to the mux/demux motherboard in slot 0:
Switch(config)# interface wavepatch 4/0/0Switch(config-if)# shutdownSwitch(config-if)# exitSwitch(config)# interface wavepatch 4/1/0Switch(config-if)# shutdownSwitch(config-if)# exitSwitch(config)# interface wavepatch 4/2/0Switch(config-if)# shutdownSwitch(config-if)# exitSwitch(config)# interface wavepatch 4/3/0Switch(config-if)# shutdownSwitch(config-if)# exitSwitch(config)#
About Path Switching

The Cisco ONS 15540 supports per-channel unidirectional and bidirectional 1+1 path switching. When a signal is protected and the signal fails, or in some cases degrades, on the active path, the system automatically switches from the active network path to the standby network path.

Signal failures can be total loss of light caused by laser failures, by fiber cuts between the Cisco ONS 15540 and the client equipment, or by other equipment failure. Loss of light failures cause switchovers for both splitter protected and y-cable protected signals.

For y-cable protected signals, you can also configure alarm thresholds to cause a switchover when the signal error rate reaches an unacceptable level. For information about configuring alarm thresholds, see the "Configuring Alarm Thresholds" section.

Note Both interfaces on both nodes must be configured with alarm thresholds for signal error rate switchovers to occur.

The Cisco ONS 15540 implements path switching using a APS Channel Protocol over the OSC (optical supervisory channel) on the protection path, or the IP management connection.

Note Bidirectional path switching operates only on Cisco ONS 15540 networks that have the OSC or the IP management connect. The patch connections between the OSC and the mux/demux module must be configured for bidirectional path switching to function if you are using the OSC.

Figure 5-3 shows a simple point-to-point configuration with splitter protection. The configured working path carries the active signal, and the configured protection path carries the standby signal.

Figure 5-3 Active and Standby Path Configuration Example

Figure 5-4 shows the behavior of unidirectional path switching when a loss of signal occurs. For the two node example network, unidirectional path switching operates as follows:

•Node 2 sends the channel signal over both the active and standby paths.

•Node 1 receives both signals and selects the signal on the active path.

•Node 1 detects a loss of signal light on its active path and switches over to the standby path.

•Node 2 does not switch over and continues to use its original active path.

Now the nodes are communicating along different paths.

Figure 5-4 Unidirectional Path Switching Example

Figure 5-5 shows the behavior of bidirectional path switching when a loss of signal occurs. For the two node example network, bidirectional path switching operates as follows:

•Node 2 sends the channel signal over both the active and standby paths.

•Node 1 receives both signals and selects the signal on the active path.

•Node 1 detects a loss of signal light on its active path and switches over to the standby path.

•Node 1 sends an APS switchover message to node 2 on the protection path.

•Node 2 switches from the active path to the standby path.

Both node 1 and node 2 communicate on the same path.

Figure 5-5 Bidirectional Path Switching Overview

Configuring Path Switching

To configure unidirectional or bidirectional path switching, use the following commands, beginning in global configuration mode:

Command

Purpose

Step 1

Switch(config)# redundancy

Switch(config-red)#

Enters redundancy configuration mode.

Step 2

Switch(config-red)# associate group name

Switch(config-red-aps)#

Selects the interfaces to associate and enters APS configuration mode.

Note The group name is case sensitive.

Step 3

Switch(config-red-aps)# aps disable

Disables APS activity between the interfaces.

Note For newly associated pairs, APS activity is disabled by default.

Step 4

Switch(config-red-aps)# aps direction {unidirectional | bidirectional}

Specifies the type of path switching. The default behavior is unidirectional.

Step 5

Switch(config-red-aps)# aps working {transparent slot/subcard/0 | wavepatch slot/subcard/port}

Configures the working path interface.

Step 6

Switch(config-red-aps)# aps protection {transparent slot/subcard/0 | wavepatch slot/subcard/port}

Configures the protection path interface.

Step 7

Switch(config-red-aps)# aps timer oscp holddown milliseconds count number

Changes the APS Channel Protocol holddown timer and message count values. The default is 5000 milliseconds and a count of 2

Step 8

Switch(config-red-aps)# aps timer oscp max-interval seconds

Changes the APS Channel Protocol maximum interval timer for waiting for a message. The default is 15 seconds.

Repeat Step 1 through Step 8 on the corresponding transparent interface on the other node that adds and drops, or terminates, the channel.

Step 9

Switch(config-red-aps)# aps enable

Enables APS activity between the interfaces.

Note Both nodes in the network that add and drop the channel must have the same APS configuration. Specifically, both must have the same path switching behavior, and working and protection paths.

Note For interfaces with either Sysplex ETR or Sysplex CLO protocol encapsulation, configure bidirectional path switching to ensure proper functioning of the protocol.

Examples

Figure 5-6 shows the active and standby paths between node 1 and node 2 with splitter protection.

Figure 5-6 Bidirectional Path Switching Example with Splitter Protection

The following example shows how to configure one channel in the example network for bidirectional path switching using the default working and protection path interfaces:
Node1# configure terminalNode1(config)# redundancyNode1(config-red)# associate group redNode1(config-red-aps)# aps working wavepatch 5/0/0Node1(config-red-aps)# aps protection wavepatch 5/0/1Node1(config-red-aps)# aps bidirectionalNode1(config-red-aps)# aps enable
Node2# configure terminalNode2(config)# redundancyNode2(config-red)# associate group blueNode2(config-red-aps)# aps working wavepatch 5/0/0Node2(config-red-aps)# aps protection wavepatch 5/0/1Node2(config-red-aps)# aps bidirectionalNode2(config-red-aps)# aps enable

Figure 5-7 shows the active and standby paths between node 1 and node 2 with y-cable protection.

Figure 5-7 Bidirectional Path Switching Example with Y-Cable Protection

The following example shows how to configure one channel in the example network for bidirectional path switching and configure the working and protection path interfaces:
Node1# configure terminalNode1(config)# redundancyNode1(config-red)# associate group alphaNode1(config-red-aps)# aps working transparent 5/0/0Node1(config-red-aps)# aps protection transparent 3/0/0Node1(config-red-aps)# aps direction bidirectionalNode1(config-red-aps)# aps y-cableNode1(config-red-aps)# aps enable
Node2# configure terminalNode2(config)# redundancyNode2(config-red)# associate group alphaNode2(config-red-aps)# aps working transparent 5/0/0Node2(config-red-aps)# aps protection transparent 3/0/0Node2(config-red-aps)# aps direction bidirectionalNode2(config-red-aps)# aps y-cableNode2(config-red-aps)# aps enable
Changing the Path Switching Direction for Y-Cable Protection

To change the path switching direction for a y-cable protection configuration, use the following commands:

Command

Purpose

Step 1

Switch# show aps group name

Displays the current standby interface in the APS group information.

Step 2

Switch# configure terminal

Switch(config)#

Enters global configuration mode.

Step 3

Switch(config)# interface transparent slot/subcard/0

Switch(config-if)#

Enters interface configuration mode for the standby interface.

Step 4

Switch(config-if)# shutdown

Disables the interface.

Step 5

Switch(config-if)# exit

Switch(config)#

Exits interface configuration mode.

Step 6

Switch(config)# redundancy

Switch(config-red)#

Enters redundancy configuration mode.

Step 7

Switch(config-red)# associate group name

Switch(config-red-aps)#

Selects the interfaces to associate and enters APS configuration mode.

Note The group name is case sensitive.

Step 8

Switch(config-red-aps)# aps disable

Disables APS activity between the interfaces.

Note For newly associated pairs, APS activity is disabled by default.

Step 9

Switch(config-red-aps)# aps direction {unidirectional | bidirectional}

Specifies the new path switching operation.

Step 10

Switch(config-red-aps)# aps enable

Enables APS activity between the interfaces.

Step 11

Switch(config-red-aps)# exit

Switch(config)#

Exits APS configuration mode.

Step 12

Switch(config-red)# exit

Switch(config)#

Exits redundancy configuration mode.

Step 13

Switch(config)# interface transparent slot/subcard/0

Switch(config-if)#

Enters interface configuration mode for the standby interface.

Step 14

Switch(config-if)# no shutdown

Disables the interface.

Step 15

Switch(config-if)# end

Switch#

Returns to privileged EXEC mode.

Repeat Step 1 through Step 15 on the corresponding transparent interface on the other node that adds and drops, or terminates, the channel.

Example

The following example shows how to change the path switching operation for a y-cable APS group from unidirectional to bidirectional:
Node1# show aps group Denver
APS Group Denver :
architecture.: 1+1, remote prov: 1+1span.........: end-to-end (client side y-cable)direction....: prov: uni, current: uni, remote prov: unirevertive....: nocreated......: 14 hours, 53 minutesaps state....: associated (enabled)request timer: holddown: 5000 ms, max: 15000 ms, count 2switched chan: 0   channel ( 0): Transparent4/3/0 (STANDBY - UP), Wave4/3 (UP): channel request: no-request: transmit request: no-request: receive request: no-requestchannel ( 1): Transparent2/3/0 (ACTIVE - UP), Wave2/3 (UP): channel request: no-request: switchover count: 0: last switchover: never
Node1# configure terminalNode1(config)# interface transparent 4/3/0Node1(config-if)# shutdownNode1(config-if)# exitNode1(config)# redundancyNode1(config-red)# associate group DenverNode1(config-red-aps)# aps disableNode1(config-red-aps)# aps direction bidirectionalNode1(config-red-aps)# aps enableNode1(config-red-aps)# exitNode1(config-red)# exitNode1(config)# interface transparent 4/3/0Node1(config-if)# no shutdownNode1(config-if)# endNode1#
Node2# show aps group Denver
APS Group Denver :
architecture.: 1+1, remote prov: 1+1span.........: end-to-end (client side y-cable)direction....: prov: uni, current: uni, remote prov: birevertive....: nocreated......: 14 hours, 53 minutesaps state....: associated (enabled)request timer: holddown: 5000 ms, max: 15000 ms, count 2switched chan: 0   channel ( 0): Transparent4/3/0 (STANDBY - UP), Wave4/3 (UP): channel request: no-request: transmit request: no-request: receive request: no-requestchannel ( 1): Transparent2/3/0 (ACTIVE - UP), Wave2/3 (UP): channel request: no-request: switchover count: 0: last switchover: never
Node2# configure terminalNode2(config)# interface transparent 4/3/0Node2(config-if)# shutdownNode2(config-if)# exitNode2(config)# redundancyNode2(config-red)# associate group DenverNode2(config-red-aps)# aps disableNode2(config-red-aps)# aps direction bidirectionalNode2(config-red-aps)# aps enableNode2(config-red-aps)# exitNode2(config-red)# exitNode2(config)# interface transparent 4/3/0Node2(config-if)# no shutdownNode2(config-if)# endNode2#
Displaying the Path Switching Configuration

To display the path switching configuration, use the following EXEC command:

Command

Purpose

show aps [detail | group name | interface {transparent slot/subcard/0 | wavepatch slot/subcard/port}]

Displays the APS configuration for interfaces and groups.

Note Group names are case sensitive.

Example

The following example shows how to display the path switching configuration for an APS group named blue:
Switch# show aps group blue
APS Group blue:
architecture.: 1+1, remote prov: 1+1span.........: end-to-end   direction....: prov: bi, current: bi, remote prov: birevertive....: nocreated......: 26 minutesaps state....: associatedrequest timer: holddown: 5000 ms, max: 15 secs, count 2switched chan: 0channel ( 0): Wavepatch8/0/1 (STANDBY - UP): channel request: no-request: transmit request: no-request: receive request: no-requestchannel ( 1): Wavepatch8/0/0 (ACTIVE - UP): channel request: no-request: switchover count: 0: last switchover: never
Switchovers and Lockouts

In APS, you can switch a channel signal from one path to another, or you can lockout a switchover altogether while performing system maintenance.

A switchover of the channel signal from the working path to protection path is useful when upgrading or maintaining the system, or in cases where a signal failure caused a switchover. In the case of splitter protection, once the cause of the problem has been corrected, the system does not automatically revert to using the original working path. The switchover to the formerly failed interface must be requested from the CLI. The interface originally configured as the working path might be preferred because of its link loss characteristics or because of its distance advantage. For example, some protocols, such as ESCON, experience lower data throughput at increasing distances, so moving the signal back to the shorter path might be advised.

A lockout prevents a switchover of the active signal from the working path to the protection path. This is useful when upgrading or maintaining the system, or when the signal on the protection path has degraded or failed.

Note Lockouts only prevent switchovers from the working path to the protection path. You cannot prevent switchovers from the protection path to the working path with a lockout request.

The Cisco ONS 15540 supports APS switchover and lockout requests from the CLI. These requests have priorities depending on the condition of the protection signal and the existence of other switchover requests. There are three types of switchover requests:

•Lockout requests—Have the highest priority and take effect regardless of the condition of the protection signal. A lockout prevents the signal from switching over from the working channel to the protection channel.

•Forced switchover requests—Have the next highest priority and are only prevented if there is an existing lockout on the protection interface, or the protection signal has failed.

•Manual switchover requests—Have the lowest priority and only occur if there is no existing lockout on the protection path, forced switchover request, or signal failure or degradation.

Note APS lockouts and switchovers do not persist across processor card switchovers or system reloads.

Y-Cable Protection APS Priority Scheme

For y-cable protected configurations, the transponder modules monitor both the active and standby interfaces.

The APS priority scheme for y-cable protected configurations is the following:

1. Lockout

2. Signal failure on the protection path

3. Forced switchover on the protection path (aps switch force protection-to-working command)

4. Forced switchover on the working path (aps switch force working-to-protection command)

5. Signal failure on the working path

6. Signal degrade on the protection path

7. Signal degrade on the working path

8. Manual switchover on the protection path (aps switch manual protection-to-working command)

9. Manual switchover on the working path (aps switch manual working-to-protection command)

If a request or condition of a higher priority is in effect, the system rejects lower priority requests.

Splitter Protection APS Priority Scheme

For splitter protected configurations, the transponder module cannot monitor the signal on the standby interface. Only the active signal is monitored. This limitation prevents APS switchovers due to signal degrade or signal failure when error thresholds are exceeded. Signal failure switchovers are only triggered by loss of light. Therefore, the APS priority scheme for splitter protected configurations differs slightly from y-cable protected configurations:

1. Lockout

2. Signal failure based on loss of light on the protection path

3. Signal failure based on loss of light on the working path

4. Forced switchover on the protection path (aps switch force protection-to-working command)

5. Forced switchover on the working path (aps switch force working-to-protection command)

6. Manual switchover on the protection path (aps switch manual protection-to-working command)

7. Manual switchover on the working path (aps switch manual working-to-protection command)

If a request or condition of a higher priority is in effect, the system rejects lower priority requests.

Requesting a Switchover

To request a signal switchover, use the following command in privileged EXEC mode:

Command

Purpose

aps switch group-name {force | manual} {protection-to-working | working-to-protection}

Requests a signal switchover of the active signal from the working path to the protection path, or vice versa, within an associated interface pair.

Example

The following example shows how to request a forced switchover from working to protection (unless a lockout request is in effect on the protection path or the protection path signal has failed):
Switch# aps switch blue force working-to-protection
Displaying Switchover Request Status

To display a pending switchover request, use the following command in privileged EXEC:

Command

Purpose

show aps [detail | group name | interface {transparent slot/subcard/0 | wavepatch slot/subcard/port}]

Displays the APS configuration for interfaces and groups.

Note Group names are case sensitive.

The following example shows how to display the switchover request status on an APS group:
Switch# show aps group blue
APS Group blue:
architecture.: 1+1, remote prov: 1+1span.........: end-to-end (client side y-cable)direction....: prov: uni, current: uni, remote prov: birevertive....: nocreated......: 15 hours, 1 minuteaps state....: associated (enabled)request timer: holddown: 5000 ms, max: 15000 ms, count 2switched chan: 0 channel ( 0): Transparent4/3/0 (ACTIVE - UP), Wave4/3 (UP)               : channel request: no-request                             : transmit request: no-request: receive request: no-request   channel ( 1): Transparent2/3/0 (STANDBY - UP), Wave2/3 (UP): channel request: no-request                             : switchover count: 1: last switchover: never

Requesting a Lockout

You can request a lockout on the protection channel from the CLI. Ensure that the protection path is not the active path by requesting a switchover from the CLI.

To lock out switchovers to the protection signal, use the following privileged EXEC commands:

Command

Purpose

Step 1

show aps [detail | group name | interface {transparent slot/subcard/0 | wavepatch slot/subcard/port}]

Verifies the active signal for the APS group.

Note Group names are case sensitive.

Step 2

aps switch group-name [force | manual] protection-to-working

Ensures that the working path is also the active path. Use the manual option if no forced switchover request is in effect. Otherwise, use the force option. (Optional)

Note All switchover requests are rejected if the working path signal has failed.

Step 3

aps lockout group-name

Locks out all switchovers to the protection path.

Examples

The following example shows how to lock out a switchover to the protection path when the protection path is the standby:
Switch# show aps group yellow
APS Group yellow:
architecture.: 1+1, remote prov: 1+1span.........: end-to-end (client side y-cable)direction....: prov: uni, current: uni, remote prov: birevertive....: nocreated......: 15 hours, 1 minuteaps state....: associated (enabled)request timer: holddown: 5000 ms, max: 15000 ms, count 2switched chan: 0   channel ( 0): Transparent4/3/0 (STANDBY - UP), Wave4/3 (UP)               : channel request: no-request                             : transmit request: no-request                             : receive request: no-request   channel ( 1): Transparent2/3/0 (ACTIVE - UP), Wave2/3 (UP): channel request: no-request: switchover count: 0: last switchover: never
Switch# aps lockout yellow

The following example shows how to switch the active signal from the protection path and lock out switchovers to the protection path:
Switch# show aps group blue
APS Group blue:
architecture.: 1+1, remote prov: 1+1span.........: end-to-end (client side y-cable)direction....: prov: uni, current: uni, remote prov: birevertive....: nocreated......: 15 hours, 1 minuteaps state....: associated (enabled)request timer: holddown: 5000 ms, max: 15000 ms, count 2switched chan: 0 channel ( 0): Transparent4/3/0 (ACTIVE - UP), Wave4/3 (UP)               : channel request: no-request                             : transmit request: no-request: receive request: no-request   channel ( 1): Transparent2/3/0 (STANDBY - UP), Wave2/3 (UP): channel request: no-request                             : switchover count: 1: last switchover: 1 hour, 22 minutes
Switch# aps switch blue force protection-to-workingSwitch# aps lockout blue
Displaying Lockout Request Status

To display a pending switchover request, use the following command in privileged EXEC mode:

Command

Purpose

show aps [detail | group name | interface {transparent slot/subcard/0 | wavepatch slot/subcard/port}]

Displays the APS configuration for interfaces and groups.

Note Group names are case sensitive.

The following example shows how to display the switchover request status on an APS group:
Switch# show aps group yellow
APS Group yellow:
architecture.: 1+1, remote prov: 1+1span.........: end-to-end (client side y-cable)direction....: prov: uni, current: uni, remote prov: birevertive....: nocreated......: 15 hours, 1 minuteaps state....: associated (enabled)request timer: holddown: 5000 ms, max: 15000 ms, count 2switched chan: 0channel ( 0): Transparent4/3/0 (STANDBY - UP), Wave4/3 (UP)               : channel request: lockout-of-protection                             : transmit request: lockout-of-protection: receive request: no-requestchannel ( 1): Transparent2/3/0 (ACTIVE - UP), Wave2/3 (UP): channel request: no-request: switchover count: 0: last switchover: never

Clearing Switchover and Lockout Requests

You can use the CLI to clear, or remove, any external (user-initiated) requests in effect on an APS group. External requests, which are not triggered by errors in the communication channel, include the following commands:

•aps lockout group-name

•aps switch group-name force protection-to-working

•aps switch group-name force working-to-protection

•aps switch group-name manual protection-to-working

•aps switch group-name manual working-to-protection

The aps clear command clears the external requests on the APS group and returns the interfaces to the initial default state, with the working interface active and no active requests in effect. However, if the working channel is defective, the protection channel could become the active channel after the working channel fails and a switchover occurs.

The aps clear command differs from y-cable revertive switching behavior. Where the aps clear command returns the interfaces to the initial default state and clears the current external request, y-cable revertive switching behavior switches the active signal back to the working channel after the expiration of the wait-to-restore timer (if no external switchover request occur during that interval).

Internal system-generated requests that cannot be cleared from the CLI include the following:

•no request

•reverse request wait-to-restore (during reversion)

•do-not-revert (when no reversion is configured)

•signal failure

•signal degrade

Note A lockout or a forced or manual switchover request stays in effect until the system reboots.

To clear an APS switchover or lockout, use the following privileged EXEC command:

Command

Purpose

aps clear group-name

Clears APS switch request or lockout on an associated interface pair.

Example

The following example shows how to clear the switchover requests on an associated interface pair using the default group name:
Switch# aps clear Wavepatch10/0/0
Displaying Switchover and Lockout Clear Status

To display a pending switchover request, use the following command in privileged EXEC mode:

Command

Purpose

show aps [detail | group name | interface {transparent slot/subcard/0 | wavepatch slot/subcard/port}]

Displays the APS configuration for interfaces and groups.

Note Group names are case sensitive.

The following example shows how to display the clear requests status on an APS group:
Switch# show aps group blue
APS Group blue :
architecture.: 1+1, remote prov: 1+1span.........: end-to-end (client side y-cable)direction....: prov: uni, current: uni, remote prov: birevertive....: nocreated......: 15 hours, 1 minuteaps state....: associated (enabled)request timer: holddown: 5000 ms, max: 15000 ms, count 2switched chan: 0channel ( 0): Transparent10/0/0 (STANDBY - UP)              : channel request: no-request              : transmit request: no-request: receive request: no-requestchannel ( 1): Transparent8/0/0 (ACTIVE - UP): channel request: no-request: switchover count: 0: last switchover: never

	Command	Purpose
Step 1	Switch(config)# redundancy Switch(config-red)#	Enters redundancy configuration mode.
Step 2	Switch(config-red)# associate interface wavepatch //working-interface wavepatch //protection-interface [enable \| disable] or Switch(config-red)# associate interface wavepatch slot//working-interface* wavepatch slot//protection-interface* [enable \| disable]	Configures APS splitter protection mode on the entire chassis. The default state is disabled. or Configures APS splitter protection mode on the interfaces in a slot. The default state is disabled. Note The prompt stays in redundancy mode when the interface identifiers contain wildcards. To configure an individual interface pair, continue to the next step.
Step 3	Switch(config-red)# associate group name Switch(config-red-aps)#	Specifies an APS group name and enters APS configuration mode. Note The group name is case sensitive.
Step 4	Switch(config-red-aps)# aps disable	Disables APS activity between the interfaces. Note For newly created APS groups, APS activity is disabled by default.
Step 5	Switch(config-red-aps)# aps working wavepatch slot/subcard/port	Configures the working path interface.
Step 6	Switch(config-red-aps)# aps protection wavepatch slot/subcard/port	Configures the protection path interface.
Step 7	Switch(config-red-aps)# aps timer search-for-up minimum maximum	Changes the interval times for the search-for-up timer. If both wavepatch interfaces are down, or the wave interface is down, the system first checks one wavepatch connection, starting at the minimum interval, then the other wavepatch connection, until one of the connections comes up. The default minimum starting interval is 2 seconds and the default maximum interval is 32 seconds.
Step 8	Switch(config-red-aps)# aps timer switchover min-interval seconds	Changes the interval times for the successive switchover timer. The default interval is 2 seconds.
Step 9	Switch(config-red-aps)# aps enable	Enables APS activity between the interfaces.

Command	Purpose
show aps	Displays the APS configuration summary.
show aps {detail \| group name \| interface wavepatch slot/subcard/port}	Displays detailed APS configuration information for groups and interfaces. Note Group names are case sensitive.

	Command	Purpose
Step 1	Switch(config)# interface wavepatch slot/subcard/port Switch(config-if)#	Selects the wavepatch interface to configure and enters interface configuration mode.
Step 2	Switch(config-if)# shutdown	Disables the wavepatch interface.
Step 3	Switch(config-if)# exit Switch(config)#	Returns to global configuration mode. Repeat Step 1 through Step 3 for one wavepatch interface per wavepatch pair on splitter protected line card motherboards.

	Command	Purpose
Step 1	Switch# show aps group name	Displays the current standby interface in the APS group information.
Step 2	Switch# configure terminal Switch(config)#	Enters global configuration mode.
Step 3	Switch(config)# interface transparent slot/subcard/0 Switch(config-if)#	Enters interface configuration mode for the standby interface.
Step 4	Switch(config-if)# shutdown	Disables the interface.
Step 5	Switch(config-if)# exit Switch(config)#	Exits interface configuration mode.
Step 6	Switch(config)# redundancy Switch(config-red)#	Enters redundancy configuration mode.
Step 7	Switch(config-red)# associate group name Switch(config-red-aps)#	Selects the interfaces to associate and enters APS configuration mode. Note The group name is case sensitive.
Step 8	Switch(config-red-aps)# aps disable	Disables APS activity between the interfaces. Note For newly associated pairs, APS activity is disabled by default.
Step 9	Switch(config-red-aps)# aps direction {unidirectional \| bidirectional}	Specifies the new path switching operation.
Step 10	Switch(config-red-aps)# aps enable	Enables APS activity between the interfaces.
Step 11	Switch(config-red-aps)# exit Switch(config)#	Exits APS configuration mode.
Step 12	Switch(config-red)# exit Switch(config)#	Exits redundancy configuration mode.
Step 13	Switch(config)# interface transparent slot/subcard/0 Switch(config-if)#	Enters interface configuration mode for the standby interface.
Step 14	Switch(config-if)# no shutdown	Disables the interface.
Step 15	Switch(config-if)# end Switch#	Returns to privileged EXEC mode. Repeat Step 1 through Step 15 on the corresponding transparent interface on the other node that adds and drops, or terminates, the channel.

	Command	Purpose
Step 1	show aps [detail \| group name \| interface {transparent slot/subcard/0 \| wavepatch slot/subcard/port}]	Verifies the active signal for the APS group. Note Group names are case sensitive.
Step 2	aps switch group-name [force \| manual] protection-to-working	Ensures that the working path is also the active path. Use the manual option if no forced switchover request is in effect. Otherwise, use the force option. (Optional) Note All switchover requests are rejected if the working path signal has failed.
Step 3	aps lockout group-name	Locks out all switchovers to the protection path.