Troubleshooting X.25 Connections

Table Of Contents

Troubleshooting X.25 Connections

X.25 Technology Basics

X.25 Frame Format

Layer 3

Layer 2

Layer 1

Troubleshooting X.25

Using the show interfaces serial Command

X.25: No Connections over X.25 Link

X.25: Excess Serial Errors on X.25 Link

Troubleshooting X.25 Connections

---

In the 1970s, a set of protocols was needed to provide users with wide-area network (WAN) connectivity across public data networks (PDNs). PDNs such as TYMNET had achieved remarkable success, but it was felt that protocol standardization would increase subscriptions to PDNs by providing improved equipment compatibility and lower cost. The result of the ensuing development effort was a group of protocols, the most popular of which is X.25.

X.25 was developed by the common carriers (telephone companies, essentially) rather than any single commercial enterprise. The specification, therefore, designed to work well regardless of a user's system type or manufacturer. Users contract with the common carriers to use their packet-switched networks (PSNs) and are charged based on PSN use. Services offered (and charges levied) are regulated by the Federal Communications Commission (FCC).

One of X.25's unique attributes is its international nature. X.25 and related protocols are administered by an agency of the United Nations called the International Telecommunications Union (ITU). The ITU Telecommunication Standardization Sector (ITU-T; formerly CCITT, the Consultative Committee for International Telegraph and Telephone) is the ITU committee responsible for voice and data communications. ITU-T members include the FCC, the European Postal Telephone and Telegraph organizations, the common carriers, and many computer and data communications companies. As a result, X.25 is truly a global standard.

X.25 Technology Basics

X.25 defines a telephone network for data communications. To begin communication, one computer calls another to request a communication session. The called computer can accept or refuse the connection. If the call is accepted, the two systems can begin full-duplex information transfer. Either side can terminate the connection at any time.

The X.25 specification defines a point-to-point interaction between data terminal equipment (DTE) and data circuit-terminating equipment (DCE). DTEs (terminals and hosts in the user's facilities) connect to DCEs (modems, packet switches, and other ports into the PDN, generally located in the carrier's facilities), which connect to packet-switching exchanges (PSEs, or switches) and other DCEs inside a PSN and, ultimately, to another DTE. The relationship between the entities in an X.25 network is shown in Figure 19-1.

Figure 19-1 The X.25 Model

A DTE can be a terminal that does not implement the complete X.25 functionality. A DTE is connected to a DCE through a translation device called a packet assembler/disassembler (PAD). The operation of the terminal-to-PAD interface, the services offered by the PAD, and the interaction between the PAD and the host are defined by ITU-T Recommendations X.28, X.3, and X.29, respectively.

The X.25 specification maps to Layers 1 through 3 of the OSI reference model. Layer 3 X.25 describes packet formats and packet exchange procedures between peer Layer 3 entities. Layer 2 X.25 is implemented by Link Access Procedure, Balanced (LAPB). LAPB defines packet framing for the DTE/DCE link. Layer 1 X.25 defines the electrical and mechanical procedures for activating and deactivating the physical medium connecting the DTE and the DCE. This relationship is shown in Figure 19-2. Note that Layers 2 and 3 are also referred to as the ISO standards ISO 7776 (LAPB) and ISO 8208 (X.25 packet layer).

Figure 19-2 X.25 and the OSI Reference Model

End-to-end communication between DTEs is accomplished through a bidirectional association called a virtual circuit. Virtual circuits permit communication between distinct network elements through any number of intermediate nodes without the dedication of portions of the physical medium that characterizes physical circuits. Virtual circuits can be either permanent or switched (temporary). Permanent virtual circuits (PVCs) are typically used for the most often used data transfers, whereas switched virtual circuits (SVCs) are used for sporadic data transfers. Layer 3 X.25 is concerned with end-to-end communication involving both PVCs and SVCs.

When a virtual circuit is established, the DTE sends a packet to the other end of the connection by sending it to the DCE using the proper virtual circuit. The DCE looks at the virtual circuit number to determine how to route the packet through the X.25 network. The Layer 3 X.25 protocol multiplexes among all the DTEs served by the DCE on the destination side of the network, and the packet is delivered to the destination DTE.

X.25 Frame Format

An X.25 frame is composed of a series of fields, as shown in Figure 19-3. Layer 3 X.25 fields make up an X.25 packet and include a header and user data. Layer 2 X.25 (LAPB) fields include frame-level control and addressing fields, the embedded Layer 3 packet, and a frame check sequence (FCS).

Figure 19-3 LAPB Structure

Layer 3

The Layer 3 X.25 header is made up of a general format identifier (GFI), a logical channel identifier (LCI), and a packet type identifier (PTI). The GFI is a 4-bit field that indicates the general format of the packet header. The LCI is a 12-bit field that identifies the virtual circuit. The LCI is locally significant at the DTE/DCE interface. In other words, the PDN connects two logical channels, each with an independent LCI, on two DTE/DCE interfaces to establish a virtual circuit. The PTI field identifies 1 of X.25's 17 packet types.

Addressing fields in call setup packets provide source and destination DTE addresses. These are used to establish the virtual circuits that constitute X.25 communication. ITU-T Recommendation X.121 specifies the source and destination address formats. X.121 addresses (also referred to as international data numbers, or IDNs) vary in length and can be up to 14 decimal digits long. Byte four in the call setup packet specifies the source DTE and destination DTE address lengths. The first four digits of an IDN are called the data network identification code (DNIC). The DNIC is divided into two parts, with the first three digits specifying the country and the last digit specifying the PSN itself. The remaining digits are called the national terminal number (NTN) and are used to identify the specific DTE on the PSN. The X.121 address format is shown in Figure 19-4.

Figure 19-4 The X.121 Address Format

The addressing fields that make up the X.121 address are necessary only when an SVC is used, and then only during call setup. After the call is established, the PSN uses the LCI field of the data packet header to specify the particular virtual circuit to the remote DTE.

Layer 3 X.25 uses three virtual circuit operational procedures: call setup, data transfer, and call clearing. Execution of these procedures depends on the virtual circuit type being used. For a PVC, Layer 3 X.25 is always in data transfer mode because the circuit has been permanently established. If an SVC is used, all three procedures are used.

Packets are used to transfer data. Layer 3 X.25 segments and reassembles user messages if they are too long for the maximum packet size of the circuit. Each data packet is given a sequence number, so error and flow control can occur across the DTE/DCE interface.

Layer 2

Layer 2 X.25 is implemented by LAPB, which allows each side (the DTE and the DCE) to initiate communication with the other. During information transfer, LAPB checks that the frames arrive at the receiver in the correct sequence and free of errors.

As with similar link layer protocols, LAPB uses three frame format types:

•Information (I) frames—These frames carry upper-layer information and some control information (necessary for full-duplex operations). Send and receive sequence numbers and the poll final (P/F) bit perform flow control and error recovery. The send sequence number refers to the number of the current frame. The receive sequence number records the number of the frame to be received next. In full-duplex conversation, both the sender and the receiver keep send and receive sequence numbers. The poll bit is used to force a final bit message in response; this is used for error detection and recovery.

•Supervisory (S) frames—These frames provide control information. They request and suspend transmission, report on status, and acknowledge the receipt of I frames. They do not have an information field.

•Unnumbered (U) frames—These frames, as the name suggests, are not sequenced. They are used for control purposes. For example, they can initiate a connection using standard or extended windowing (module 8 versus 128), disconnect the link, report a protocol error, or carry out similar functions.

The LAPB frame is shown in Figure 19-5.

Figure 19-5 The LAPB Frame

The fields of an LAPB frame are as follows:

•Flag—Delimits the LAPB frame. Bit stuffing is used to ensure that the flag pattern does not occur within the body of the frame.

•Address—Indicates whether the frame carries a command or a response.

•Control—Provides further qualifications of command and response frames, and also indicates the frame format (I, S, or U), frame function (for example, receiver ready or disconnect), and the send/receive sequence number.

•Data—Carries upper-layer data. Its size and format vary, depending on the Layer 3 packet type. The maximum length of this field is set by agreement between a PSN administrator and the subscriber at subscription time.

•FCS—Ensures the integrity of the transmitted data.

Layer 1

Layer 1 X.25 uses the X.21 bis physical layer protocol, which is roughly equivalent to EIA/TIA-232-C (formerly RS-232-C). X.21 bis was derived from ITU-T Recommendations V.24 and V.28, which identify the interchange circuits and electrical characteristics, respectively, of a DTE-to-DCE interface. X.21 bis supports point-to-point connections, speeds up to 19.2 kbps, and synchronous, full-duplex transmission over four-wire media. The maximum distance between DTE and DCE is 15 meters.

Troubleshooting X.25

This section presents troubleshooting information relating to X.25 connectivity. The "Using the show interfaces serial Command" section discusses the use of the show interfaces serial command in an X.25 environment and describes some of the key fields of the command output.

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

Using the show interfaces serial Command

This section describes the information provided by the show interfaces serial exec command in an X.25 environment. For additional information about the output of the show interfaces serial exec command, refer to Chapter 15, "Troubleshooting Serial Lines," and the Cisco IOS Configuration Fundamentals Command Reference.

The show interfaces serial command provides important information useful for identifying problems in X.25 internetworks. The following fields provide especially important information:

•REJs—Number of rejects

•SABMs—Number of set asynchronous balance mode requests

•RNRs—Number of receiver not ready events

•FRMRs—Number of protocol frame errors

•RESTARTs—Number of restarts

•DISCs—Number of disconnects

All but the RESTARTs count are LAPB events. Because X.25 requires a stable data link, LAPB problems commonly cause an X.25 restart event that implicitly clears all virtual connections. If unexplained X.25 restarts occur, examine the underlying LAPB connection for problems. Use the debug lapb exec command to display all traffic for interfaces using LAPB encapsulation. The no form of this command disables debugging output:

[no] debug lapb

The [no] debug lapb command displays information on the X.25 Layer 2 protocol. It is useful to users who are familiar with LAPB. You can use the debug lapb command to determine why X.25 interfaces or LAPB connections are going up and down. It is also useful for identifying link problems, as evidenced when the show interfaces command displays a large number of rejects or frame errors over the X.25 link.

---

Caution Exercise care when using debug commands. Many debug commands are processor-intensive and can cause serious network problems (such as degraded performance or loss of connectivity) if they are enabled on an already heavily loaded router. When you finish using a debug command, remember to disable it with its specific no debug command (or use the no debug all command to turn off all debugging).

---

Figure 19-6 shows the output of the X.25 version of the show interfaces serial exec command and indicates the important fields.

Figure 19-6 Output from the X.25 Version of the show interfaces serial Command

X.25: No Connections over X.25 Link

Symptom: Connections over an X.25 link fail.

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

Table 19-1 X.25: No Connections over X.25 Link 

Possible Problem	Solution
Link is down.	Use the show interfaces serial exec command to determine whether the link is down. If the link is down, refer to Chapter 15.
Cabling is incorrect, or the router hardware is bad.	1. Use the show interfaces serial exec command to determine the status of the interface. 2. If the interface is down, refer to Chapter 15. If the interface is up but the line protocol is down, check the LAPB1 state in the output of the show interfaces serial command. 3. If the LAPB state is not CONNECT, use the debug lapb privileged exec command (or attach a serial analyzer) to look for SABMs being sent and for UA2 packets being sent in reply to SABMs3 . If UAs are not being sent, one of the other possible problems described in this table is the likely cause. Caution: Exercise care when using debug commands. Many debug commands are processor-intensive and can cause serious network problems (such as degraded performance or loss of connectivity) if they are enabled on an already heavily loaded router. When you finish using a debug command, remember to disable it with its specific no debug command (or use the no debug all command to turn off all debugging). Use debug commands to isolate problems, not to monitor normal network operation. Because the high processor overhead of debug commands can disrupt router operation, you should use debug commands only when you are looking for specific types of traffic or problems and have narrowed your problems to a likely subset of causes. 4. If the show interfaces serial exec command indicates that the interface and line protocol are up but no connections can be made, there is probably a router or switch misconfiguration. Refer to the other possible problems outlined in this table. 5. Check all cabling and hardware for damage or wear. Replace cabling or hardware as required. For more information, refer to Chapter 3, "Troubleshooting Hardware and Booting Problems."
Protocol parameters are misconfigured.	1. Enable the debug lapb privileged exec command and look for SABMs being sent. If no SABMs are being sent, disable the debug lapb command and enable the debug x25 events privileged exec command. 2. Look for RESTART messages (for PVCs4 ) or CLEAR REQUESTS with nonzero cause codes (for SVCs5 ).
Protocol parameters are misconfigured. (continued)	1. Enable the debug lapb privileged exec command and look for SABMs being sent. If no SABMs are being sent, disable the debug lapb command and enable the debug x25 events privileged exec command. 2. Look for RESTART messages (for PVCs6 ) or CLEAR REQUESTS with nonzero cause codes (for SVCs7 ). To interpret X.25 cause and diagnostic codes provided in the debug x25 events output, refer to the Debug Command Reference. 3. Verify that all critical LAPB parameters (modulo, T1, N1, N2, and k) and the critical X.25 parameters (modulo, X.121 addresses, SVC ranges, PVC definitions, and default window and packet sizes) match the parameters required by the service provider.
The x25 map command is misconfigured.	1. Use the show running-config privileged exec command to view the router configuration. Look for x25 map interface configuration command entries. 2. Make sure that x25 map commands specify the correct address mappings. To retract a prior mapping, use the no form of the x25 map command with the appropriate network protocol(s) and X.121 address argument: no x25 map protocol address x121-address To set up the LAN protocols-to-remote host mapping, use the x25 map interface configuration command: x25 map protocol address [protocol2 address2[...[protocol9 address9]]] x121-address [option] Syntax Description: •protocol—Protocol type, entered by keyword. Supported protocols are entered by keyword. As many as nine protocol and address pairs can be specified in one command line. •address—Protocol address. •x121-address—X.121 address of the remote host. •option—(Optional) Additional functionality that can be specified for originated calls.
The x25 map command is misconfigured. (continued)	3. Ensure that all router X.25 configuration options match the settings of attached switches. Reconfigure the router or switch as necessary. 4. Enable the debug x25 events command and look for RESTART messages (for PVCs) or CLEAR REQUESTs with nonzero cause codes (for SVCs). To interpret X.25 cause and diagnostic codes provided in the debug x25 events output, refer to the Debug Command Reference.

1 LAPB = Link Access Procedure, Balanced 2 UA = Unnumbered acknowledgment 3 SAMB = Set Asynchronous Balance Mode 4 PVC = permanent virtual circuit 5 SVC = switched virtual circuit 6 PVC = permanent virtual circuit 7 SVC = switched virtual circuit

X.25: Excess Serial Errors on X.25 Link

Symptom: The output of the show interfaces serial command shows REJs, RNRs, FRMRs, RESTARTs, or DISCs in excess of 0.5 percent of information frames (IFRAMEs).

---

Note If any of these fields are increasing and represent more than 0.5 percent of the number of IFRAMEs, there is probably a problem somewhere in the X.25 network. There should always be at least one SABM. However, if there are more than 10, the packet switch probably is not responding.

---

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

Table 19-2 X.25: Excess Serial Errors on X.25 Link

Possible Problem

Solution

Incorrect cabling or bad router hardware

1. Use the show interfaces serial exec command to determine the status of the interface. 2. If the interface is down, refer to Chapter 15. If the interface is up but the line protocol is down, check the LAPB state in the output of the show interfaces serial command. 3. If the LAPB state is not CONNECT, use the debug lapb privileged exec command (or attach a serial analyzer) to look for SABMs being sent and for UA packets being sent in reply to SABMs. 4. If the show interfaces serial exec command indicates that the interface and line protocol are up but no connections can be made, there is probably a router or switch misconfiguration. 5. Check all cabling and hardware for damage or wear. Replace cabling or hardware as required. For more information, refer to Chapter 3.