Troubleshooting ATM Switching Environments

Basic Port Checks

Checking Bit Rates

Performing Loopback Tests

Looping Trunk Ports

Looping Edge Ports

Using the ping Command

Trunk Does Not Come Up

Frame Relay Port Does Not Come Up

Virtual Circuit Fails To Be Created

Partial Data Delivered over Virtual Circuit

Troubleshooting ATM Switching Environments

This chapter presents troubleshooting information for connectivity and performance problems in ATM switching environments. The chapter begins with general information about checking ports, performing loopback tests, and using the ping command on a LightStream 2020 ATM switch.

The remaining sections describe specific ATM switching symptoms, the problems that are likely to cause each symptom, and the solutions to those problems.

Basic Port Checks

This procedure outlines the steps for performing basic port checks. Perform basic port checks to verify that a LightStream 2020 port is enabled and is functioning correctly.

Step 1 Use the show port port-number all command to display information about a port.

Step 2 Check the Admin Status field to make sure that the port is Up.

Step 3 Check for excessive line errors, packet drops, or a lack of receive data. If there is no receive data or if the error rate on the receive data is excessive, check the hardware, cabling, and other physical layer components.

For more information on troubleshooting hardware, refer to the "Troubleshooting Hardware and Booting Problems" chapter.

Step 4 If the port is directly connected to a host, ensure that one side of the connection is configured as DCE and the other side is configured as DTE.

If two ports are connected through a CSU, ensure that the ports on both sides of the connection are configured as DTE.

Step 5 If you are working with a low-speed line card (LSC) port, check the bit rate. Refer to the section "Checking Bit Rates" later in this chapter.

Step 6 If you are working with a medium-speed line card (MSC) port, check for mismatches in port configuration attributes such as cell payload scrambling, line type, and cable length.

Checking Bit Rates

This procedure outlines the steps for determining if the bit rate for a port is correctly configured. This procedure applies only to low-speed line cards.

Step 1 Use the show port port-number all command to display information about a port.

Step 2 Check the Measured Bit Rate field to ensure that the specified bit rate is legal. If the bit rate is not legal, use the set port c.p characteristics dce-bitrate-bps or set port c.p characteristics dte-bitrate-bps command, as appropriate, to configure a legal bit rate for the port.

Step 3 Compare the Measured Bit Rate with the Admin DCE Rcv Bit Rate field. If the value shown in the Measured Bit Rate field is significantly different from that shown in the Admin DCE Rcv Bit Rate field, a problem exists.

Step 4 If the port is DCE, it provides the clocking function. Make sure that the cabling is correct and that the configured bit rate is valid. If an attempt is made to activate the port when an invalid bit rate is configured, problems will occur.

Step 5 If the port is DTE, it uses the clock supplied by the attached device (such as a CSU/DSU or a router). If the correct clock is not being detected, make sure that the correct cable type is used to connect the port to the attached device and that the attached device is providing a clock function.

Performing Loopback Tests

Loopback tests can help you pinpoint faults by looping a signal at various points in the network. The LightStream 2020 ATM switch provides the following two types of loopback tests:

Remote loopback test---The remote loopback test loops data from an external device through the I/O module and back. This test verifies that the data sent from the remote end can cross the telephone company line or cable, pass through the I/O module, and return to the remote end.
Internal loopback test---The internal loopback test loops data from the line card to the line chip or to the physical layer protocol processor (PLPP) I/O module to see if the I/O module is able to receive data intact.

If the test is successful, data is reaching the I/O module properly. However, a successful test does not verify whether the I/O module correctly encodes the data that will be sent onto the line.

The following sections provide the procedures used to perform loopback tests:

Note You can loop any port. However, only trunk ports and Frame Relay ports have active port management protocols that automatically verify the port's ability to process data.

Looping Trunk Ports

This procedure outlines the steps for looping data through a trunk between two LightStream 2020 trunk ports. If you know that data is not passing on a trunk between two trunk ports, follow these steps to set up a remote loop on one of the trunk ports.

Step 1 Enter the set port port-number loop remote command. The port is set to testing mode and the loopback test begins automatically.

Step 2 If the remote loop succeeds, the trunk port comes up at the remote end. If the local port displays an Operational Status of down during the loopback test, there is probably a problem with the local port. Proceed to Step 3.

If the remote loop fails and the trunk does not come up, then a problem exists somewhere between the local access card and the remote system.

Step 3 To run an internal loop on the port, enter the set port port-number loop internal command. The port is set to testing mode and the loopback test begins automatically.

Step 4 If the internal loop succeeds and the local trunk comes up, the problem is the local access card.

Step 5 To stop the loopback test, enter the set port port-number unloop command.

Looping Edge Ports

This procedure outlines the steps for looping data through an edge port. The line from the port connects a LightStream 2020 ATM switch to third-party external device. If you suspect that data is not passing between the LightStream 2020 edge port and the host, or that the line is unreliable, use this looping procedure to isolate the problem.

Step 1 If the port is a Frame Relay UNI port, enter the set port port-number framerelay netinterfacetype nni command to set the netinterfacetype attribute to NNI.

Internal loopback tests do not work on Frame Relay ports with the LMI type set to UNI.

Step 2 Run a remote loop on the LightStream 2020 edge port by entering the set port port-number loop remote command. The port is set to testing mode and the loopback test begins automatically.

Step 3 If the internal loop fails and the line does not come up, the problem is in the line or access card.

Step 4 To stop the loopback test, enter the set port port-number unloop command.

Step 5 If you changed a Frame Relay UNI port to NNI for the loopback test, reset the port to the UNI network interface type by entering the set port port-number framerelay netinterfacetype uni command.

Using the ping Command

The ping command is useful for determining if communication is possible over a particular IP connection. The ping command sends an ICMP echo packet to the specified IP address. If communication with that address is possible, the host replies with an ICMP-echo-reply message.

The following procedure describes how to perform a ping test from a LightStream 2020 ATM switch:

Step 1 Log in as root on the LightStream 2020 switch from which you want to send ICMP echo packets.

Step 2 Enter the ping [packet-size] hostname command (where packet-size is the size of the packets to send and hostname is the name or IP address of the host). The packet size argument is optional. The default packet size is 64 bytes.

Step 3 To stop the ping and display a summary of the results, press ^C.

Trunk Does Not Come Up

Symptom: An ATM trunk does not come up properly and connections cannot be made.

Table 19-1 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 19-1 : ATM Switching: Trunk Does Not Come Up

Possible Problem Solution

Card not configured as a trunk card Step 1 Check the port at each end of the trunk with the show port port-number statistics command. Make sure that both ports are periodically sending cells.
Step 2 Check the Octets Sent field to verify that it is incrementing.
Step 3 If one port never sends Trunk-Up-Down messages, make sure the card is correctly configured as a trunk card.
Step 4 Make sure that a trunk is configured on port 0. The trunk can be configured as inactive if desired.
Step 5 If both sides of the trunk show that they are sending cells, find out which side is not receiving cells. Perform a basic port check as described in the section "Basic Port Checks" earlier in this chapter.

Incorrect line type Make sure that the line type parameter (dsx3Linetype) is correctly configured. Check with your carrier for the correct line type for your connection.

Framing type mismatch Step 1 Check to see if both ends of the trunk are configured to use the same framing type (PLCP, HEC, or G.804). Enter the show port command. If there is a mismatch, the display for both ports will indicate "DS3_other_failure."
Step 2 Change the framing type on one of the ports, as appropriate, using the set port c.p characteristics framing type {plcp | t3-hec | q-804} command.

Cell payload scrambling mismatch If there is a cell payload scrambling mismatch, the TUD protocol will fail because the payload of the cells is scrambled at one end and not unscrambled at the other end. The trunks will never come up. However, packets will appear to be received and transmitted without error in the port statistics display.
Step 1 Check to see if one end of a trunk has cell payload scrambling enabled and the other end has cell payload scrambling disabled.
Step 2 Reconfigure the trunk ports using the set port c.p characteristics cell-scrambling {enable | disable} command so that cell payload scrambling is either enabled or disabled on both ends of the trunk.

Telephone company network problem Isolate the problem by running the loopback tests described in the section "Performing Loopback Tests" earlier in this chapter. If you determine that the problem is occurring in the telephone company network, contact your carrier to solve the problem.

Hardware or cabling problem Step 1 Check all cabling and connections to make sure there are no worn cables or loose connections.
Step 2 Make sure that cable lengths are within specification and that the cable length port attribute is properly configured. Use the set port c.p characteristics cable len length command to change the cable length attribute.
Step 3 Check all hardware for problems. For more information on troubleshooting hardware, refer to the "Troubleshooting Hardware and Booting Problems" chapter.

Possible Problem	Solution
Card not configured as a trunk card	Step 1 Check the port at each end of the trunk with the show port port-number statistics command. Make sure that both ports are periodically sending cells. Step 2 Check the Octets Sent field to verify that it is incrementing. Step 3 If one port never sends Trunk-Up-Down messages, make sure the card is correctly configured as a trunk card. Step 4 Make sure that a trunk is configured on port 0. The trunk can be configured as inactive if desired. Step 5 If both sides of the trunk show that they are sending cells, find out which side is not receiving cells. Perform a basic port check as described in the section "Basic Port Checks" earlier in this chapter.
Incorrect line type	Make sure that the line type parameter (dsx3Linetype) is correctly configured. Check with your carrier for the correct line type for your connection.
Framing type mismatch	Step 1 Check to see if both ends of the trunk are configured to use the same framing type (PLCP, HEC, or G.804). Enter the show port command. If there is a mismatch, the display for both ports will indicate "DS3_other_failure." Step 2 Change the framing type on one of the ports, as appropriate, using the set port c.p characteristics framing type {plcp \| t3-hec \| q-804} command.
Cell payload scrambling mismatch	If there is a cell payload scrambling mismatch, the TUD protocol will fail because the payload of the cells is scrambled at one end and not unscrambled at the other end. The trunks will never come up. However, packets will appear to be received and transmitted without error in the port statistics display. Step 1 Check to see if one end of a trunk has cell payload scrambling enabled and the other end has cell payload scrambling disabled. Step 2 Reconfigure the trunk ports using the set port c.p characteristics cell-scrambling {enable \| disable} command so that cell payload scrambling is either enabled or disabled on both ends of the trunk.
Telephone company network problem	Isolate the problem by running the loopback tests described in the section "Performing Loopback Tests" earlier in this chapter. If you determine that the problem is occurring in the telephone company network, contact your carrier to solve the problem.
Hardware or cabling problem	Step 1 Check all cabling and connections to make sure there are no worn cables or loose connections. Step 2 Make sure that cable lengths are within specification and that the cable length port attribute is properly configured. Use the set port c.p characteristics cable len length command to change the cable length attribute. Step 3 Check all hardware for problems. For more information on troubleshooting hardware, refer to the "Troubleshooting Hardware and Booting Problems" chapter.

Frame Relay Port Does Not Come Up

Symptom: A Frame Relay port on a LightStream 2020 ATM switch does not come up properly. Data cannot be transmitted out the port.

Table 19-2 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 19-2 : ATM Switching: Frame Relay Port Does Not Come Up

Possible Problem Solution

LMI type mismatch Step 1 Use the show port port-number all command to see if the Normal Packets Received counter is incrementing. A packet should be received every 10 seconds from the Frame Relay host.
Step 2 If the counter is not incrementing, check the Discarded Received Packets statistic. If the Discarded Received Packets entry is incrementing, the packets are coming in but on a different DLCI. This occurs when there is an LMI type mismatch.
Step 3 Make sure that both the Frame Relay port and the Frame Relay host are configured to use the same LMI protocol (FRIF, ANSI T1 617D, or Q933A). Use the show port c.p framerelay command to check the LightStream 2020 port. For information on checking and configuring the LMI type on the Frame Relay host, refer to the vendor documentation.
Step 4 Change the LMI type on the port using the set port c.p framerelay lmiconfig {none | frif | ansi_t1_617d | q933a} command and see if the port becomes active. If the LMI does not come up, make sure that packets are being received on the LMI DLCI. The FRIF LMI uses DLCI 1023. The ANSI and Q933A LMIs use DLCI 0.

Port protocol incorrect Step 1 Use the show port c.p framerelay command to make sure that the LightStream 2020 port is correctly configured as a UNI port or an NNI port.

In general, ports should be configured to use the UNI protocol. The NNI protocol is designed for network device-to-network device connection and is rarely used.

Step 2 If the port protocol is incorrect, use the set port port-number framerelay netinterfacetype {nni | uni} command to reconfigure it.

DLCI is not activated Step 1 Use the show port c.p listdlci command to see if the Frame Relay DLCI is deactivated. The output will show an uppercase I in front of the DLCI entry if it has been manually deactivated.
Step 2 If the DLCI is deactivated, use the set port port-number dlci dlci-number activate command to activate the DLCI.

Possible Problem	Solution
LMI type mismatch	Step 1 Use the show port port-number all command to see if the Normal Packets Received counter is incrementing. A packet should be received every 10 seconds from the Frame Relay host. Step 2 If the counter is not incrementing, check the Discarded Received Packets statistic. If the Discarded Received Packets entry is incrementing, the packets are coming in but on a different DLCI. This occurs when there is an LMI type mismatch. Step 3 Make sure that both the Frame Relay port and the Frame Relay host are configured to use the same LMI protocol (FRIF, ANSI T1 617D, or Q933A). Use the show port c.p framerelay command to check the LightStream 2020 port. For information on checking and configuring the LMI type on the Frame Relay host, refer to the vendor documentation. Step 4 Change the LMI type on the port using the set port c.p framerelay lmiconfig {none \| frif \| ansi_t1_617d \| q933a} command and see if the port becomes active. If the LMI does not come up, make sure that packets are being received on the LMI DLCI. The FRIF LMI uses DLCI 1023. The ANSI and Q933A LMIs use DLCI 0.
Port protocol incorrect	Step 1 Use the show port c.p framerelay command to make sure that the LightStream 2020 port is correctly configured as a UNI port or an NNI port. In general, ports should be configured to use the UNI protocol. The NNI protocol is designed for network device-to-network device connection and is rarely used. Step 2 If the port protocol is incorrect, use the set port port-number framerelay netinterfacetype {nni \| uni} command to reconfigure it.
DLCI is not activated	Step 1 Use the show port c.p listdlci command to see if the Frame Relay DLCI is deactivated. The output will show an uppercase I in front of the DLCI entry if it has been manually deactivated. Step 2 If the DLCI is deactivated, use the set port port-number dlci dlci-number activate command to activate the DLCI.

Virtual Circuit Fails To Be Created

Symptom: A Frame Relay, frame forwarding, UNI, or CBR virtual circuit fails to be created.

Table 19-3 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 19-3 : ATM Switching: Virtual Circuit Fails To Be Created

Possible Problem Solution

Virtual circuit not configured on both end points Step 1 Use the show port command to verify that the virtual circuit is configured on both end points. The virtual circuit must be configured on both end points for the circuit to be created.
Step 2 If one end point does not have the virtual circuit configured, reconfigure the end point. For each virtual circuit you must specify the node, card, and port at each end and the required bandwidth.
For detailed information on configuring virtual circuits, refer to the LightStream 2020 Configuration Guide publication.

Port in inactive mode Step 1 Check to see if the virtual circuit is configured on an inactive port. Use the show port command to check the status of the port.
Step 2 If the port is in inactive or testing mode, bring the port up using the set port port-number active command.

cardMaxVCs attribute set too low If the cardMaxVCs attribute is set too low on a line card, there might be insufficient resources available for creating a virtual circuit. Increase the value of this attribute and reboot the line card.

Bandwidth or other circuit attributes misconfigured If the virtual circuit has illegal attributes set the circuit will not be created. Review the bandwidth values in particular.
A virtual circuit cannot have a MaxRate larger than the port. Also, certain combinations of parameters are illegal. If a virtual circuit uses guaranteed bandwidth, it cannot have any excess bandwidth. The insured rate must equal the max rate.
Refer to the LightStream 2020 Configuration Guide for more information.

Not enough bandwidth Step 1 If there is not enough bandwidth available to support the virtual circuit, the circuit cannot be created. Check the Cells Available attribute to determine how much bandwidth is available (that is, how much has not been allocated to other virtual circuits).
Step 2 Check the Cells Required attribute to see how many cells of bandwidth are needed to carry the virtual circuit over a trunk.

Trunk down Make sure that any trunks in the path between the end points are active. For more information, see the section "Trunk Does Not Come Up" earlier in this chapter.

Possible Problem	Solution
Virtual circuit not configured on both end points	Step 1 Use the show port command to verify that the virtual circuit is configured on both end points. The virtual circuit must be configured on both end points for the circuit to be created. Step 2 If one end point does not have the virtual circuit configured, reconfigure the end point. For each virtual circuit you must specify the node, card, and port at each end and the required bandwidth. For detailed information on configuring virtual circuits, refer to the LightStream 2020 Configuration Guide publication.
Port in inactive mode	Step 1 Check to see if the virtual circuit is configured on an inactive port. Use the show port command to check the status of the port. Step 2 If the port is in inactive or testing mode, bring the port up using the set port port-number active command.
cardMaxVCs attribute set too low	If the cardMaxVCs attribute is set too low on a line card, there might be insufficient resources available for creating a virtual circuit. Increase the value of this attribute and reboot the line card.
Bandwidth or other circuit attributes misconfigured	If the virtual circuit has illegal attributes set the circuit will not be created. Review the bandwidth values in particular. A virtual circuit cannot have a MaxRate larger than the port. Also, certain combinations of parameters are illegal. If a virtual circuit uses guaranteed bandwidth, it cannot have any excess bandwidth. The insured rate must equal the max rate. Refer to the LightStream 2020 Configuration Guide for more information.
Not enough bandwidth	Step 1 If there is not enough bandwidth available to support the virtual circuit, the circuit cannot be created. Check the Cells Available attribute to determine how much bandwidth is available (that is, how much has not been allocated to other virtual circuits). Step 2 Check the Cells Required attribute to see how many cells of bandwidth are needed to carry the virtual circuit over a trunk.
Trunk down	Make sure that any trunks in the path between the end points are active. For more information, see the section "Trunk Does Not Come Up" earlier in this chapter.

Partial Data Delivered over Virtual Circuit

Symptom: Partial data is delivered over a Frame Relay, frame forwarding, UNI, or CBR virtual circuit.

Table 19-4 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 19-4 : ATM Switching: Partial Data Delivered over Virtual Circuit

Possible Problem Solution

Network congestion Check to see if the network is congested. Check your traffic management configuration and make adjustments as appropriate.
For detailed information, refer to the LightStream 2020 System Overview publication.

Target depth and maximum depth parameters misconfigured (CBR only) Reconfigure the target depth and maximum depth parameters to compensate for random cell delay variation (CDV). Use the set port c.p cbrpvc pvc-number {targetdepth | maxdepth} command to change these parameters.
If the target depth is set too low or if the maximum depth is set too close to the target depth, random CDV can cause the circuit to overflow or underflow sporadically, causing data errors and reframe events for equipment downstream.

Table of Contents