TROUBLESHOOTING ATM

TROUBLESHOOTING ATM
SWITCHING
ENVIRONMENTS
Table of Contents
Troubleshooting ATM Switching Environments
Cell Relay Packet Handling
Technologies Compared
Fitting ATM into the OSI Model
Placing User Data into ATM Cells
ATM Label Switching
Virtual Channel Connections and Virtual Paths
The ATM Cell
The ATM Adaptation Layer
The ATM Layer
Placing Cells on a Physical Transport Medium
Troubleshooting ATM Switching Environments
Basic Port Checks
Checking Bit Rates
Performing Loopback Tests
Looping Trunk Ports
Looping Edge Ports
Using the ping Command
ATM Switching: Trunk Does Not Come Up
ATM Switching: Frame Relay Port Does Not Come Up
ATM Switching: Virtual Circuit Fails to Be Created
ATM Switching: Partial Data Delivered over Virtual Circuit
Troubleshooting ATM Switching
Environments
This chapter describes the Asynchronous Transfer Mode (ATM) technology on which the Light
Stream 2020 multiservice ATM switch (LS2020 switch) is based. ATM is a communications
standard based on cell relay techniques. The next sections discuss cell relay and ATM
technology. They also contrast ATM techniques with time-division multiplexing (TDM) and
other packet-handling technologies.
Cell Relay Packet Handling
Cell relay is a flexible and responsive method for multiplexing all forms of digital traffic (data,
voice, image, and video). Cell relay can handle rapid changes in the quantity and pattern of the
traffic in the network. All traffic is placed in fixed-length packets of information (cells) and
switched at high speeds. Cell relay is generally acknowledged as the best multiplexing
technology for modern communication applications because it combines the strengths of TDM
and conventional packet switching. Using cell relay packet-handling techniques, a mixture of
burst and delay-sensitive traffic can be processed simultaneously, while at the same time
providing the services required by each traffic type.
Also, because cell relay processing is based on the use of small packets, the process technology
is adaptable and cost-effective for a wide range of interface speeds.
Technologies Compared
ATM technology first appeared in the Broadband Integrated Services Digital Network (BISDN).
However, ATM is now recognized as a useful technology in and of itself and is based on the
specifications and standards being developed by ITU-T (International Telecommunications
Union Telecommunication Standardization Sector), ANSI (American National Standards
Institute), and the ATM Forum.
Note ITU-T carries out the functions of the former Consultative Committee for International
Telegraph and Telephone (CCITT).
Each ATM cell contains a header and the data to be transferred. Cells are switched in the
network based on routing information contained in the cell headers. ATM transports all types of
traffic (data, voice, image, and video) using the same cell format.
ATM contrasts with TDM in the way it allocates communications channels. In TDM,
communications channels are divided into fixed periods of time called frames. The frames are
divided into a fixed number of time slots of equal duration (see Figure 21-1). Each user is
assigned certain time slots within each frame. As Figure 21-1 indicates, a user can be given more
than one time slot in a frame.
Figure 21-1: User Assignments on Communications Channel Using TDM
The time slots allocated for each user occur at precisely the same time in every frame. Because
the time slots are synchronous, TDM is sometimes referred to as synchronous transfer mode
(STM).
Users can access the communications channel only when a time slot that has been allocated to
them is available. For example, User A can send messages over the communications channel
only during the time slot(s) designated for User A. If no traffic is ready to send when the
designated time slot occurs, that time slot is unused. If a user has a burst of traffic that exceeds
the capacity of the -designated time slots, additional slots cannot be used, even if they are idle.
As a result, a long delay could result before the burst of traffic is transferred over the TDM
network.
In ATM, access to the communications channel is more flexible. Any user needing the
communications channel can use it whenever it is available. In contrast to TDM, ATM imposes
no regular pattern on the way users are given access to the communications channel. ATM is
also described as providing bandwidth on demand.
In other packet-handling technologies, such as High-Level Data Link Control (HDLC), any user
can gain access to the communications channel, but a user who has a long message to send can
prevent other users from gaining access to the channel until the entire message has been passed.
However, with ATM, every message is divided into small, fixed-length cells. Thus, no single
user can monopolize access to the communications channel while other users have messages to
send (see Figure 21-2).
Figure 21-2: User Assignments on ATM Communications Channel
Fitting ATM into the OSI Model
ATM standards define protocols that operate at Layer 2 (the data link layer) of the International
Organization for Standardization (ISO) seven-layer Open Systems Interconnection (OSI)
reference model. Figure 21-3 shows the layered architecture of the OSI model.
Figure 21-3: The OSI Reference Model
The data link layer is concerned with data transmission between two network switches. This
layer is not concerned with the transmission of an entire message between a source and a
destination switch---this responsibility belongs to Layer 3 (the network layer). Rather, the data
link layer transports portions of messages (cells, in the case of ATM) between two points in the
network. These points may be the source and the destination of the message, or they may be only
intermediate hops between the source and the destination.
The data link layer may divide higher-level data into smaller units (cells, in this case), whose
sizes are compatible with overall network requirements. Layer 2 data units contain a cell header,
an information field, and some method of checking for transmission errors.
Placing User Data into ATM Cells
Before frames can be transported across an ATM network, they must be divided into ATM cells.
The processes that divide the frames into cells occur at Layer 2. Layer 2 is divided into two
parts: the ATM adaptation layer (AAL) and the ATM layer. After frames are divided into ATM
cells, the cells can be transferred to Layer 1 (see Figure 21-4).
Figure 21-4: Layer 2---The Data Link Layer
ATM Label Switching
ATM uses label switching, a technique in which a simple label is placed in the header of each
cell. The label provides information used in transporting the cell across the next hop in the
network. Networks that do not use label switching usually require each packet (or cell) to contain
the explicit address of the final destination. ATM uses label switching because it is simpler,
thereby making faster switching possible.
Here is how label switching works:
1. A switching unit reads an incoming cell from a particular port. The incoming cell has a
routing label.
2. The switching unit uses the combination of the input port on which the cell was
received and the information in the label to determine where the cell should go next. It
does this by referring to a routing table that correlates the incoming port and label with an
outgoing port and label.
3. The switch replaces the incoming label with a new outgoing label and sends the cell
through the outgoing port, which is connected to another switching device. (The new
outgoing label is taken from the routing table.)
4. This process is repeated until the cell reaches its final destination in the ATM network.
For example, suppose your network includes a switching unit called Boston. A number of data
paths go through the Boston switch. When those data paths are created, a routing table is set up
within the Boston switch. The table in the Boston switch has one entry for each data path that
goes through the switch. The entries in the table map the incoming port and label to an outgoing
port and label for each data path, as shown in Table 21-1 .
Table 21-1: A Sample Routing Table for a Boston Switch
Port In Label In Port Out Label Out
1 L 6 Z
1 M 7 X
2 N 7 Y
When the Boston switch receives an incoming cell on port 1 with label M, it consults the routing
table and finds that label M should be replaced with label X and that the cell should be passed
out of the Boston switch on port 7. The cell is then transported to the switch in the network that
is connected to port 7 of the Boston switch, as shown in Figure 21-5.
Figure 21-5: Cell Passing Through a Boston Switch
In all cases, transporting cells through the use of label switching requires a connection.
Information about the connections is provided in the routing tables (sometimes called lookup
tables) of switching and multiplexing units. ATM uses virtual channel connections and virtual
paths to accomplish routing functions.
Virtual Channel Connections and Virtual Paths
A virtual channel connection (VCC) is a series of virtual channel links (VCLs) between two
ATM points. A VCL is a means of bidirectional transport of ATM cells between a point where a
virtual channel identifier (VCI) value is assigned and the point where the same value is either
reassigned or terminated. The VCI identifies the VCL to which a cell belongs and determines
where the cell should go next. Figure 21-6 shows the relationship between VCLs and VCCs in an
ATM network.
Figure 21-6: The Relationship Between VCLs and VCCs in an ATM Network
VCCs are sometimes transported within virtual paths (VPs). A VP is identified by its virtual path
identifier (VPI). VPs provide a convenient way of bundling traffic directed to the same
destination or traffic requiring the same Quality of Service (QoS) in the network (see Figure 21-
7).
Figure 21-7: VCCs Transported Within VPs
The ATM Cell
The ATM cell is the fixed-length transmission unit defined by the ATM standard. An ATM cell
contains two major types of information: the payload and the header. The payload is the
information to be transferred through an ATM network. It can include data, voice, image, or
video. The header is the information used to route the cell through the network and to ensure that
the cell is forwarded to its destination.
Every ATM cell is 53 bytes long. The first 5 bytes contain header information, and the remaining
48 bytes contain the payload (see Figure 21-8).
Figure 21-8: An ATM Cell
The 5-byte header (see Figure 21-9) contains several different fields (see Table 21-2). The 48
bytes following the header (the payload) contain user data.
Figure 21-9: The User-Network Interface ATM Cell Header Format
Table 21-2: Fields in an ATM Cell Header
Header
Field
Name
Location in
Header
Description
GFC1 First 4 bits of
Byte 1
Controls the flow of traffic across the user network interface
and thus into the ATM network.
VPI2 Second 4 bits of
Byte 1 and the
first 4 bits of
Byte 2
Identifies a particular VPC3. A VPC is a group of virtual
connections carried between two points and may involve
several ATM links. VPIs provide a way to bundle traffic
heading to the same destination.
VCI4 Second 4 bits of
Byte 2, Byte 3,
and the first 4
bits of Byte 4
Identifies a particular VCC5. A VCC is a connection between
two active, communicating ATM entities. The VCI consists of
a concatenation of several ATM links.
PT6 The fifth, sixth, Indicates the type of information in the payload field. ATM
and seventh bits
of Byte 4
cells carry different types of information that may require
different handling by the network or terminating equipment.
CLP7 The eighth bit of
Byte 4
Indicates the cell loss priority set by the user. This bit
indicates the eligibility of the cell for discard by the network
under congested conditions. If the bit is set to 1, the cell may
be discarded by the network if congestion occurs.
HEC8 Byte 5 Contains an error-correcting code calculated across the
previous four bytes of the header. The HEC detects multiplebit
header errors and can be used to correct single-bit errors.
The HEC provides protection against incorrect delivery of
messages caused by address errors. The HEC does not provide
any protection for the payload field itself.
1GFC = generic flow control. For a network-to-node (NNN) interface, there is no GFC field.
These 4 bits are part of the VPI field.
2VPI = virtual path identifier
3VPC = virtual path connection
4VCI = virtual channel identifier
5VCC = virtual channel connection
6PT = payload type
7CLP = cell loss priority
8HEC = header error control
The ATM Adaptation Layer
The AAL accepts frames from higher OSI layers and adapts them to the 48-byte segments that
are placed into the Payload field of ATM cells. The ATM layer accepts the 48-byte segments,
adds the 5-byte header, and produces ATM cells to be transferred to the physical layer, as
illustrated in Figure 21-10.
Figure 21-10: ATM Adaptation Layer Functions
When ATM cells are transferred through a network, each cell is processed in isolation from all
other cells. All processing decisions are made based on the cell header; no processing of the data
in the payload field occurs.
Figure 21-11 shows some examples of AAL processing.
Figure 21-11: AAL Processing Examples
Hosts A and C are connected to the network through ATM interfaces, so they do all their AAL
processing internally. The network does not do any processing for hosts A and C. Hosts B and D
are connected to native Ethernet interfaces on Nodes 1 and 2. Therefore, Node 2 does all the
AAL processing for Host D. Node 3 does no AAL processing.
Depending on the type of traffic entering the ATM network, the AAL uses one of four different
AAL types to divide the traffic into small segments. These types are classified according to the
timing -relationship between the source and destination, the constant or variable bit rate, and the
mode (connection-oriented or connectionless). The AAL types defined in the ATM standard are
listed in Table 21-3 .
Table 21-3: AAL Types
AAL
Type
Examples of Traffic Type
1 Circuit emulation, constant bit rate video
2 Variable bit rate video and audio
3/4 Connection-oriented or connectionless data transfer (AAL 3/4 has cell-by-cell error
checking and multiplexing)
5 Connectionless data transfer (AAL 5 has lower overhead than AAL 3/4)
The AAL is divided into two sublayers: the convergence sublayer (CS) and the segmentation and
reassembly sublayer (SAR; see Figure 21-12).
Figure 21-12: Information Flow Through AAL
The convergence sublayer (CS) accepts higher-layer traffic for transmission across the network.
Depending on the AAL type, header and/or trailer fields are added to the packet. The packet is
then segmented by the SAR sublayer to form 48-byte payloads (also known collectively as SARPDUs).
Upon receipt of cell payloads, the AAL removes any AAL-specific information from each
payload and reassembles the entire packet before passing it to a higher layer (see Figure 21-13).
Figure 21-13: The SAR Portion of the AAL Process
The ATM Layer
The ATM layer accepts the 48-byte SAR-PDUs from the SAR process, adds a 5-byte header to
each, and produces ATM cells for transfer to the physical layer (see Figure 21-14).
Figure 21-14: The ATM Layer Process
Placing Cells on a Physical Transport Medium
After the data is packaged into 53-byte ATM cells, the cells are transferred to the physical layer,
where they are placed on a physical transport medium, such as fiber optic cable or coaxial cable.
The process of placing cells on the physical medium takes place in two sublayers: the physical
medium dependent (PMD) sublayer and the transmission convergence (TC) sublayer.
Each PMD is specific to a particular physical medium and includes definitions of proper cabling
as well as bit timing. The TC sublayer generates and receives transmission frames and performs
all overhead functions associated with the transmission frame. The TC sublayer performs a
convergence function by receiving a bit stream from the PMD and extracting cells.
Although PMD operation depends on the physical medium, the following TC functions remain
common to all physical layers:
• Cell delineation---Extraction of cells from the bit stream received from the PMD
• Cell rate decoupling---Adaptation of the speed of the ATM layer cell stream to the rate of
the physical interface
• Header error control (HEC) generation and checking---Performed when the TC sublayer
checks where each received cell starts and ends by calculating the HEC for that cell
• Various operation and maintenance (OAM) functions---ATM Forum specification for
cells used to monitor virtual circuits. OAM cells provide a virtual circuit-level loopback
in which a router responds to the cells, demonstrating that the circuit is up and the router
is operational.
Troubleshooting ATM Switching Environments
This section 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.
• ATM Switching: Trunk Does Not Come Up
• ATM Switching: Frame Relay Port Does Not Come Up
• ATM Switching: Virtual Circuit Fails to Be Created
• ATM Switching: Partial Data Delivered over Virtual Circuit
Basic Port Checks
The following steps outline the procedure for performing basic port checks. It is important to
perform basic port checks to verify that a LightStream 2020 port is enabled and 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 "Troubleshooting Hardware and
Booting Problems."
Step 4 If the port is directly connected to a host, ensure that one side of the connection is
configured as data communications equipment (DCE) and the other side is configured as data
circuit-terminating equipment (DTE).
If two ports are connected through a channel service unit (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 whether 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. The following is the syntax for the set port command:
characteristics {dce-bitrate Kbits | dte-bitrate bits}
Set the DCE or DTE bit rate for the specified port, depending on the dce-dte-type value
described below. The value of Kbits for the DCE bit rate may be 56, 64, 128, 192, 256, 384, 448,
512, 768, 896, 1344, 1536, 1792, 2688, 3584, 4000, or 5376. The value of bits for the DTE bit
rate is unrestricted in the range of decimal integers 9,000---6,000,000.
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. The value of Kbits for the DCE bit rate may be 56,
64, 128, 192, 256, 384, 448, 512, 768, 896, 1344, 1536, 1792, 2688, 3584, 4000, or 5376.
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 whether
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.
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, the physical and logical
connections 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 a 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 User-Network Interface (UNI) port, enter the set port portnumber
framerelay netinterfacetype nni command to set the netinterfacetype attribute to
Network-to-Network Interface (NNI).
Internal loopback tests do not work on Frame Relay ports with the Local Management Interface
(LMI) type set to UNI.
Step 2 Run a remote loop on the LightStream 2020 edge port by entering the set port portnumber
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 whether communication is possible over a
particular Internet Protocol (IP) connection. The ping command sends an Internet Control
Message Protocol (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 steps describe 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.
ATM Switching: Trunk Does Not Come Up
Symptom: An ATM trunk does not come up properly and connections cannot be made.
Table 21-4 outlines the problems that might cause this symptom and describes solutions to those
problems.
Table 21-4: 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 portnumber
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. Use the show port physical command to display the line type as
well as the following information:
• Port type
• Operational and administrative CSU type
• Operational and administrative DCE receive bit rate
• Operational transmit bit rate
• Measured bit rate
• Link transmit utilization rate (data plus control)
• Administrative expected dte rate and operational and administrative
net interface type (dte/dce; these are for low-speed line cards only)
• Operational and administrative protocol
• LC auto enable state and debug level
• Data cell capacity and available capacity
• Call setup retry and backoff times
• Operational maximum frame size
• Modem status (DCD, DSR)
Framing type
mismatch
Step 1 Check to see whether 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 trunk-up-down (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 whether one end of a trunk has cell payload scrambling
enabled and the other end has cell payload scrambling disabled. Use the
show port c.p physical command to verify the status of the payload
scrambling.
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 "Troubleshooting Hardware and Booting
Problems."
ATM Switching: 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 21-5 outlines the problems that might cause this symptom and describes solutions to those
problems.
Table 21-5: ATM Switching: Frame Relay Port Does Not Come Up
Possible
Problem
Solution
LMI1 type
mismatch
Step 1 Use the show port port-number all command to see whether 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 DLCI2. 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 whether 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 UNI3 port or an NNI4 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 whether 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.
1LMI = Local Management Interface
2DLCI = Data Link Connection Identifier
3UNI = User-Network Interface
4NNI = Network-to-Network Interface
ATM Switching: Virtual Circuit Fails to Be Created
Symptom: A Frame Relay, frame forwarding, UNI, or constant bit rate (CBR) virtual circuit
fails to be created.
Table 21-6 outlines the problems that might cause this symptom and describes solutions to those
problems.
Table 21-6: ATM Switching: Virtual Circuit Fails to Be Created
Possible Problem Solution
Virtual circuit not
configured on both
Step 1 Use the show port command to verify that the virtual circuit is
configured on both endpoints. The virtual circuit must be configured on
endpoints both endpoints for the circuit to be created.
Step 2 If one endpoint does not have the virtual circuit configured,
reconfigure the endpoint. 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.
Port in inactive
mode
Step 1 Check to see whether 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. The following switchwide
attribute may be configured only in expert mode in the configuration tool:
• Max VCs for this card---setsnmp cardMaxVCs.card# nnn
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. Use the following
commands to review the settings:
• Use the show port c.p vci VCI# command to display, for the
specified ATM UNI port, the following attributes of the PVC1
with the specified VCI2:
o Source node, port, and VCI
o Source insured rate, insured burst, maximum rate, and
maximum burst (operational and administrative)
o Destination operational node, port, VCI, insured rate,
insured burst, maximum rate, and maximum burst
o To-net and from-net circuit ID and circuit state, last error
reported by ATM management, and cells required
o Counts of cells to the switch with CLP= 0 or 1, a count of
cells to the switch with CLP = 0 upon arrival at the port,
but forwarded with CLP = 1, and a count of discarded cells
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.
• Use the set port c.p vci vci# insured-rate cells/sec command to
set the insured rate to cells/sec for the specified ATM UNI PVC.
The insured rate is the upper bound on the non-sharable bandwidth
that the connection may use in a sustained way. The range is 0-
100,000,000 bits per second. The default for ATM UNI circuits is
0 cells per second.
• Use the set port c.p vci vci# max-rate cells/sec command to set
the maximum rate to cells/sec for the specified ATM UNI PVC.
The maximum rate is the upper bound on the rate of all traffic
(insured and noninsured) allowed to enter the LightStream 2020
network, congestion permitting. The default rate is the line rate for
all cards except the CLC3, for which the default rate is 218
cells/sec.
Refer to the LightStream 2020 Configuration Guide for more information.
Not enough Step 1 If there is not enough bandwidth available to support the virtual
bandwidth 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). Use the show port c.p all
command to display all port attributes (name, status, statistics, physical,
frameforward, framerelay, DLCI, VCI, PVC, VPI). This is the default,
with show port c.p followed by no arguments.
Step 2 Check the cells required attribute to see how many cells of
bandwidth are needed to carry the virtual circuit over a trunk. Use the
show port c.p vci VCI# command to display, for the specified ATM UNI
port, the following attributes of the PVC with the specified VCI:
• Source node, port, and VCI
• Source insured rate, insured burst, maximum rate, and maximum
burst (operational and administrative)
• Destination operational node, port, VCI, insured rate, insured
burst, maximum rate, and maximum burst
• To-net and from-net circuit ID and circuit state, last error reported
by ATM management, and cells required
• Counts of cells to the switch with CLP= 0 or 1, a count of cells to
the switch with CLP = 0 upon arrival at the port, but forwarded
with CLP = 1, and a count of discarded cells
Trunk down Make sure that any trunks in the path between the endpoints are active.
For more information, see the section "ATM Switching: Trunk Does Not
Come Up" earlier in this chapter.
1PVC = permanent virtual circuit
2VCI = virtual channel identifier
3CLC = cell line card
ATM Switching: Partial Data Delivered over Virtual Circuit
Symptom: Partial data is delivered over a Frame Relay, frame forwarding, UNI, or CBR virtual
-circuit.
Table 21-7 outlines the problems that might cause this symptom and describes solutions to those
problems.
Table 21-7: ATM Switching: Partial Data Delivered over Virtual Circuit
Possible Problem Solution
Network congestion Check whether the network is congested. Check your traffic
management configuration and make adjustments as appropriate.
Use the show chassis congestion command to display the maximum
and minimum intervals between permit limit updates and the
minimum interval between CA updates.
For detailed information, refer to the LightStream 2020 System
Overview.
Target depth and
maximum depth
parameters
misconfigured (CBR1
only)
Use the set port c.p cbrpvc PVC# {targetdepth | maxdepth} bytes
command to control the reassembly buffer at the point where input
cells are converted back into a CBR stream. An adaptive control
loop maintains data in the buffer close to the level specified by
targetdepth bytes. Data in excess of maxdepth bytes is discarded.
The default values of the targetdepth and maxdepth attributes are
usually best left unchanged. If the target depth is set too high or if
the maximum depth is set too far above the target, end-to-end delay
for the entire circuit increases. With voice traffic, such delay can
cause annoying echo. If the target depth is set too low or if the
maximum depth is set too close to the target depth, random CDV2
may cause the circuit to overflow or underflow sporadically, causing
data errors and reframe events for equipment downstream. For
certain applications, such as video and phone, where some
discarding of overflow data is an acceptable cost of maintaining a
constant bit rate, it may be preferable to set these two parameters
closer together.
1CBR = constant bit rate
2CDV = cell delay variation



 





 !"#$%&'()*+&&#&'