Troubleshooting ESCON Aggregation Card Problems

Table Of Contents

Troubleshooting ESCON Aggregation Card Problems

4.1  Overview

4.2  Initial Troubleshooting Checklist

4.3  Troubleshooting ESCON Aggregation Card Interface Problems

4.3.1  Removing an SFP Optics Causes Alarms on Other Esconphy Interfaces

4.3.2  Shutting Down One Esconphy Interface Raises Alarms on Other Esconphy Interfaces

4.3.3  Reenabling an Esconphy Interface Clears Alarms on Other Esconphy Interfaces

4.3.4  All Client Side Lasers Shut Down When Traffic to One Esconphy Interface Falls Below a Threshold

4.3.5  Client Side Laser Unexpectedly Shuts Down

4.3.6  Client Traffic Does Not Flow End-to-End

4.3.7  Portgroup Interface Shows Continuous Errors

4.3.8  Esconphy Interface Not Created

4.4  Troubleshooting ESCON Aggregation Card Problems Using Loopbacks

4.4.1  Client Signal Loopbacks

Troubleshooting ESCON Aggregation Card Problems

This chapter describes how to troubleshoot ESCON aggregation card problems. This chapter includes the following sections:

• Overview

• Initial Troubleshooting Checklist

• Troubleshooting ESCON Aggregation Card Interface Problems

• Troubleshooting ESCON Aggregation Card Problems Using Loopbacks

4.1  Overview

The ESCON aggregation card aggregates up to ten ESCON data streams into a single 2.5-Gbps signal, which is transmitted through the switch fabric to a 2.5-Gbps ITU trunk card, 10-Gbps ITU trunk card, 10-Gbps ITU tunable trunk card, or 10-Gbps uplink card. The ESCON aggregation card can be populated with up to ten SFP (small form-factor pluggable) optics.

Figure 4-1 shows an example path of an ESCON signal through the Cisco ONS 15530 and the associated interfaces.

Figure 4-1 Interface Model for ESCON Aggregation

4.2  Initial Troubleshooting Checklist

Follow this initial checklist before proceeding with the troubleshooting procedures:

•Check that the receive signal power level from the switch fabric is between -22 dBm and -6 dBm if the ESCON aggregation card is connected to a 10-Gbps ITU trunk card or a 10-Gbps ITU tunable trunk card, between -12.5 dBm and 0.5 dBm for a 10-Gbps uplink card, or between -28 dBm and -8 dBm for a 2.5-Gbps ITU trunk card.

•Check that the client receive signal power level is between -33 dBm and -14 dBm. If the receive signal power is not within this range, adjust the attenuation.

•Issue show interfaces commands to ensure that the esconphy, waveethernetphy, wavepatch, and tengigethernetphy interfaces are administratively up and that there are no errors on the interfaces.

•Issue a show connect command to verify the status of the cross connections between the ESCON aggregation card and the ITU trunk card or uplink card.

•Check that the LEDs on the card and SFP optics show the proper state.

•Issue a show facility-alarm status command to display the alarms on the interfaces.

•If ITU cards are present, check that the ITU cards are patched to the correct OADM ports. Issue a show patch command to verify that there are no frequency mismatches.

•Ensure that all optical connectors are clean. Refer to the Cisco ONS 15530 Cleaning Procedures for Fiber Optic Connections document.

4.3  Troubleshooting ESCON Aggregation Card Interface Problems

This section contains troubleshooting procedures for ESCON aggregation card interface problems.

4.3.1  Removing an SFP Optics Causes Alarms on Other Esconphy Interfaces

Symptom    You removed one of the SFP optics on an ESCON aggregation card and alarm messages appear on the console for other interfaces on the same card.
Table 4-1 describes the potential cause of the symptom and the solution.

Table 4-1 Removing an SFP Optics Causes Alarms on Other Esconphy Interfaces

Possible Problem

Solution

The decrease in signal power caused forward laser control to shut down the interfaces.

Reinsert the SFP optics.

4.3.2  Shutting Down One Esconphy Interface Raises Alarms on Other Esconphy Interfaces

Symptom    You shut down one esconphy interface and alarm messages appear on the console for other esconphy interfaces on the same ESCON aggregation card.
Table 4-2 describes the potential cause of the symptom and the solution.

Table 4-2 Shutting Down One Esconphy Interface Raises Alarms on Other Esconphy Interfaces

Possible Problem

Solution

The decrease in signal power caused forward laser control to raise the alarms.

Reenable the interface with a no shutdown command.

4.3.3  Reenabling an Esconphy Interface Clears Alarms on Other Esconphy Interfaces

Symptom    You issued a no shutdown command on one esconphy interface and alarm messages appear on the console for other esconphy interfaces on the same ESCON aggregation card.
Table 4-3 describes the potential cause of the symptom and the solution.

Table 4-3 Reenabling an Esconphy Interface Clears Alarms on Other Esconphy Interfaces

Possible Problem

Solution

The increase in signal power caused forward laser control to clear the alarms.

None. This is normal behavior.

4.3.4  All Client Side Lasers Shut Down When Traffic to One Esconphy Interface Falls Below a Threshold

Symptom    The client signal to one esconphy interface fell below an alarm threshold value which caused all client side lasers to shut down.
Table 4-4 describes the potential cause of the symptom and the solution.

Table 4-4 All Client Side Lasers Shut Down When Traffic to One Esconphy Interface Falls Below a Threshold

Possible Problem

Solution

The decrease in signal power caused forward laser control to shut down the interfaces.

1. Check the signal from the client equipment and resolve the transmission problem.

2. Issue no shutdown commands on the shut down esconphy interfaces.

4.3.5  Client Side Laser Unexpectedly Shuts Down

Symptom    A client side laser unexpectedly shuts down without affecting other client side lasers on the ESCON aggregation card.
Table 4-5 describes the potential causes of the symptom and the solutions.

Table 4-5 Client Side Laser Unexpectedly Shuts Down

Possible Problem

Solution

The interface at the remote end detects loss of light or is administratively shut down.

Correct the failure at the remote end.

The rate of traffic received from the remote end caused forward laser control to shut down the laser.

Correct the failure at the remote end.

4.3.6  Client Traffic Does Not Flow End-to-End

Symptom    The client traffic does not reach the remote system.
Table 4-6 describes the potential causes of the symptom and the solutions.

Table 4-6 Client Traffic Does Not Flow End-to-End

Possible Problem

Solution

An interface in the path is administratively shut down.

Issue a show interfaces command for each interface on the signal path. If an interface is administratively shut down, use the no shutdown command on the interface.

The client receive signal power is not strong enough.

Check the Rx LED. If it is not on, make sure that the client receive signal power level is between -33 dBm and -14 dBm. Adjust the attenuation if the signal power is too low.

The cross connection is not properly configured.

Issue a show connect command to verify the configured cross connections. Correct any problems with the connect command.

The remote esconphy interface is not up.

1. Check the Tx LED.

2. If the LED is not on, issue a show interfaces command on the remote system for the peer esconphy interface.

3. If the interface is not up, issue a no shutdown command on the remote esconphy interface.

The client laser is shut down by forward laser control.

Issue a show interfaces command for the esconphy interface to verify the status of the client side laser and the forward laser control configuration status. If forward laser control has shut down the laser, issue a show interfaces command on the remote system to verify the status of the peer esconphy interface and resolve any problems.

Flow identifiers are not configured for all the esconphy interfaces and the ESCON traffic is mixing with GE traffic on a 10-Gbps ITU trunk card or a 10-Gbps ITU tunable trunk card.

1. Issue a cdl flow identifier reserve command to reserve flow identifiers for all esconphy interfaces on the ESCON aggregation card, whether SFP optics is present for the interface or not.

2. Issue no shutdown commands on the esconphy interface present on card.

Note All existing flow identifiers take precedence over the reserve flow identifiers.

Different CDL flow identifiers are configured on the esconphy interfaces.

Configure the same CDL flow identifiers on the corresponding esconphy interfaces on the two nodes.

4.3.7  Portgroup Interface Shows Continuous Errors

Symptom    A portgroup interface reports continuous errors to the system console.
Table 4-7 describes the potential causes of the symptom and the solutions.

Table 4-7 Portgroup Interface Shows Continuous Errors

Possible Problem

Solution

A fault occurred in the switch fabric.

Issue a redundancy switch-activity command to switch over to the standby CPU switch module. If the switchover corrects the problem, replace the faulty CPU switch module.

A fault occurred in the ESCON aggregation card.

Perform signal loopbacks as described in the "Troubleshooting ESCON Aggregation Card Problems Using Loopbacks" section.

4.3.8  Esconphy Interface Not Created

Symptom    A esconphy interface does not appear in the configuration and is not recognized by the system.
Table 4-8 describes the potential cause of the symptom and the solution.

Table 4-8 Esconphy interface not created

Possible Problem

Solution

Wrong SFP optics is installed.

Issue a show interfaces command for the esconphy interface and verify that the Optical Transceiver field shows a valid value. If not, replace the SFP optics with the correct part.

4.4  Troubleshooting ESCON Aggregation Card Problems Using Loopbacks

This section describes how to use software loopbacks to perform fault isolation for signals on ESCON aggregation cards.

To perform further loopback operations, see the "8.4  Troubleshooting 2.5-Gbps ITU Trunk Card Problems Using Loopbacks" section on page 8-5, "10.4  Troubleshooting 10-Gbps ITU Tunable Trunk Card Problems Using Loopbacks" section on page 10-6, and the "9.4  Troubleshooting 10-Gbps ITU Trunk Card Problems Using Loopbacks" section on page 9-5.

4.4.1  Client Signal Loopbacks

Client signal loopbacks on ESCON aggregation cards verify the functioning of the SFP optics (see Figure 4-2).

Figure 4-2 Client Signal Loopback Example

Procedure: Create a Client Signal Loopback

Step 1 Issue a loopback command on the esconphy interface.

Step 2 Check that the traffic is reaching the client equipment.

Step 3 If the signal does not reach the client equipment, check the optical cables for breaks. If there are no breaks, replace the SFP optics.

Possible Problem	Solution
The interface at the remote end detects loss of light or is administratively shut down.	Correct the failure at the remote end.
The rate of traffic received from the remote end caused forward laser control to shut down the laser.	Correct the failure at the remote end.

Possible Problem	Solution
An interface in the path is administratively shut down.	Issue a show interfaces command for each interface on the signal path. If an interface is administratively shut down, use the no shutdown command on the interface.
The client receive signal power is not strong enough.	Check the Rx LED. If it is not on, make sure that the client receive signal power level is between -33 dBm and -14 dBm. Adjust the attenuation if the signal power is too low.
The cross connection is not properly configured.	Issue a show connect command to verify the configured cross connections. Correct any problems with the connect command.
The remote esconphy interface is not up.	1. Check the Tx LED. 2. If the LED is not on, issue a show interfaces command on the remote system for the peer esconphy interface. 3. If the interface is not up, issue a no shutdown command on the remote esconphy interface.
The client laser is shut down by forward laser control.	Issue a show interfaces command for the esconphy interface to verify the status of the client side laser and the forward laser control configuration status. If forward laser control has shut down the laser, issue a show interfaces command on the remote system to verify the status of the peer esconphy interface and resolve any problems.
Flow identifiers are not configured for all the esconphy interfaces and the ESCON traffic is mixing with GE traffic on a 10-Gbps ITU trunk card or a 10-Gbps ITU tunable trunk card.	1. Issue a cdl flow identifier reserve command to reserve flow identifiers for all esconphy interfaces on the ESCON aggregation card, whether SFP optics is present for the interface or not. 2. Issue no shutdown commands on the esconphy interface present on card. Note All existing flow identifiers take precedence over the reserve flow identifiers.
Different CDL flow identifiers are configured on the esconphy interfaces.	Configure the same CDL flow identifiers on the corresponding esconphy interfaces on the two nodes.

Possible Problem	Solution
A fault occurred in the switch fabric.	Issue a redundancy switch-activity command to switch over to the standby CPU switch module. If the switchover corrects the problem, replace the faulty CPU switch module.
A fault occurred in the ESCON aggregation card.	Perform signal loopbacks as described in the "Troubleshooting ESCON Aggregation Card Problems Using Loopbacks" section.