Troubleshooting X.25

X.25 has been around for quite some time and is actually a suite of protocols. The first of these protocols originated sometime in the 1970s, shortly after the successful introduction of Telnet and TYMNET packet-switching networks (PSNs). The creators of the X.25 protocol suite had a goal of enabling data to be transmitted and received between two alphanumeric terminals through analog, plain old telephone system (POTS) phone lines. Early versions of X.25 enabled alphanumeric terminals to communicate remotely and access applications on servers and mainframes located on both ends of the analog telephone line.

One drawback existed, howevermodern desktop applications needed to connect two, sometimes dissimilar, LANs with a WAN. This meant that LAN-to-WAN-to-LAN data communications were necessary. Again, the designers went back and created newer forms of wide-area networking technology, such as Integrated Services Digital Network (ISDN) and Frame Relay. These newer WAN protocols complement or extend the features of the X.25 protocol suite in the network without replacing the need for the protocol.

Troubleshooting X.25 is similar to troubleshooting a serial line or a Frame Relay line. This section first looks at some of the steps you can use to resolve X.25 circuit issues, and then looks at some of the show and debug commands that can be useful to resolving and identifying the issues.

For the exam, you should have a good knowledge of X.25 and Frame-Relay configuration and hardware troubleshooting procedures. Particularly, you should know which problems are a result of a configuration problem and which problems are a result of a cabling or Physical Layer problem.

X.25 and Packet-Layer Protocol (PLP)

Many different Layer 3 protocols can be transmitted across X.25 VCs. The X.25 protocol is only the tunnel that enables Layer 3 protocol packets within the X.25 Layer 3 packets to find their way from one end of a VC to the other. X.25 is the protocol that keeps the addressing valid for each Layer 3 protocol, while the X.25 VC transports the packet through a circuit.

The Packet-Layer Protocol (PLP) is used by X.25 to manage packet exchanges within a VC. PLP can be used over Logical-Link Control 2 (LLC2) or Integrated Services Digital Network (ISDN) operating on interfaces running Link Access Procedure on D channel (LAPD). PLP operates in five different modes:

• Call Setup Mode Used to create an SVC between two DTE devices, using the X.121 addressing scheme (discussed in the following section) to create a VC.

• Data-transfer Mode Used to transfer the physical data between two DTE devices through an already established VC. This mode assists PLP with packet segmentation, packet reassembly, and error and flow control.

• Idle Mode Used when a VC is established and data transfer is not occurring. This mode is executed on a per-VC basis on SVCs.

• Call-clearing Mode Used by an SVC to end communication sessions between two DTE devices.

• Restarting Mode Used to restart a transmission between a DTE device and a DCE device located within the PSN.

Call setup and Call-clearing are used on SVCs only. PVCs are constant connections.

X.25 PLP packet headers are made up of three fields, as shown in Figure 10.2:

• GFI A 4-bit field used to indicate the general formatting of the packet header

• LCI A 12-bit field used to identify the VC information, and whether the packet is for a DTE or DCE interface

• PTI An 8-bit field used to identify individual packet types

Figure 10.2. The X.25 PLP packet header fields.

X.121 Address Format

The standard format defined for an X.25 VC is called X.121 and is an ITU-T standard. In a private X.25 network, each network is assigned a base address in decimal digits. These decimal digits, which are 1 to 15 digits, are defined for X.121 addresses to enable network protocols to connect across an X.25 link. The X.121 address enables the DTE end router to map the next -hop Layer 3 address to an X.121 address. These statements are logically equivalent to the Media Access Control (MAC) address. Maps are required for each protocol, because ARP is not supported in an X.25 network.

The first four digits of the X.121 address define the Data Network Identification Code (DNIC). The first three digits specify the country code. The fourth digit is the provider number assigned by the ITU-T. Countries that require more than 10 provider numbers are assigned multiple country codes. For example, the United States is assigned country codes 310 through 316. To view the complete listing of ITU-T country code assignments, visit ITU-T's Web site (www.itu.org) and refer to the ITU-T Recommendation X.121.

The remaining 8 to 11 digits specify the network terminal number (NTN) assigned by the PSN provider. You must contact your local service provider to get your individual DNIC code. Figure 10.3 shows an example of the X.121 used across a PVC.

Figure 10.3. The X.121 protocol used across a PVC.

Now that you have a basic overview, you are ready to look at some troubleshooting techniques.

X.25 Troubleshooting Problems

X.25 can experience a range of symptoms and potential problems. The sections that follow outline typical problems and some of their potential causes, including

• Faulty hardware or cabling

• LABP connect state failure

• Misconfigured interfaces or protocol

• X.25 connection failures

X.25 Connection Failure

When you have X.25 protocol connection failures, your link will show the protocol as down.

To troubleshoot this issue, follow these steps:

1. Check whether the link is down.

2. Check for faulty-hardware issues.

3. Check whether the cables are seated correctly.

4. Check to see whether a cable may be faulty by checking connections and the cables throughput.

5. Check whether the interface is configured properly.

Unwarranted Errors

Many times your error counters will increase for no apparent reason, even though the configuration and routers appear to be functioning correctly.

To troubleshoot this issue, follow these steps:

1. Check for faulty hardware. Refer to Chapter 7, " Troubleshooting the Physical Layer," for more information on troubleshooting the physical hardware.

2. Check for incorrect cabling.

3. Consider faulty cabling.

LABP CONNECT State Failure

When LABP will not go into the CONNECT state, the problem can be difficult to troubleshoot. There can be many possible causes for LABP CONNECT state failures. The troubleshooting steps below only help to identify the problem. If the problem results from a configuration issue, you may need to do some more research to correct the problem. To troubleshoot this issue, follow these steps:

1. Check the interface to verify that the LAPB is in a CONNECT state.

2. Use the debug lapb command to determine why the interface is failing to go into the CONNECT state.

3. Replace the faulty equipment.

Misconfigured Interfaces or Protocol

This is typically the problem with new, reconfigured, moved, or replaced equipment. Unless there is a hardware change, a good configuration on a router typically will not change on its own. To troubleshoot this issue, follow these steps:

1. Use the show running-config command to verify the configuration.

2. Use the debug labp command to see whether Set Asynchronous Balance Mode (SABMs) requests are being sent.

3. If no SABMs are being sent, use the debug x25 events command to learn more about why they are not being sent.

4. Observe the output of the debugging commands for RESTART messages.

5. Check the LAPB configuration on the interface.

X.25 Troubleshooting Commands

As discussed earlier in the chapter with respect to troubleshooting Frame Relay and serial links, certain debug and show commands can be used to obtain more information about the troubleshooting issues you are facing . This section looks at the following X.25 troubleshooting commands:

• debug x25 events

• debug lapb

• show interface serial

The debug x25 events Command

The debug x25 events command can be used to detect events and obtain diagnostic information on X.25-configured interfaces. Note that when using this command, due to the large amount of output generated by calls and other data such as Receive Ready (RR) flow control packets, these events are not displayed by the router.

The debug lapb Command

The debug lapb command debugs the events at Layer 2 of the X.25 circuits. This command should be used when an X.25 interface experiences frequent restarts. Because X.25 relies on LAPB to maintain stability, if problems arise with the LAPB configuration, it affects the X.25 protocol and the participating X.25 interfaces.

The show interface serial Command

When a serial interface is configured to use X.25, the show interface serial command provides information specific to the X.25 protocol. Here is a sample of the show interface serial command's output when X.25 is configured on the interface:

 Sean2514#  show interfaces serial 0  1d03h: %CLEAR-5-COUNTERS: Clear counter on interface Serial0 by console Serial0 is up, line protocol is up   Hardware is HD64570   Internet address is 207.212.77.174/24     Hardware is HD64570   Internet address is 172.16.30.5/30   MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/  255, load 51/255   Encapsulation X25, loopback not set LAPB DTE, state CONNECT, modulo 8, k 7, N1 12043, N2 10 T1 3000, interface outage (partial T3) 0, T4 0 VS 1, VR 1, Remote VR 1, Retransmissions 0    IFRAMEs 1/1 RNRs 0/0 REJs 0/0 SABM/Es 1/0 FRMRs 0/0 DISCs 0/0 X25 DTE, address 190118, state R1, modulo 8, timer 0 Defaults: cisco encapsulation, idle 0, nvc 1 Input/output window sizes 2/2, packet sizes 128/128 Timers: T20 180, T21 200, T22 180, T23 180, TH 0 Channels: Incoming-only none, Two-way 5-1024, Outgoing-only none RESTARTs 1/1 CALLs 0+0/0+0/0+0 DIAGs 0/0   Last input 00:00:00, output 00:00:00, output hang never   Last clearing of "show interface" counters 00:48:96   Input queue: 1/75/0 (size/max/drops); Total output drops: 0   Queueing strategy: weighted fair   Output queue: 0/1000/64/0 (size/max total/threshold/drops)      Conversations  0/2/256 (active/max active/max total)      Reserved Conversations 0/0 (allocated/max allocated)   5 minute input rate 0 bits/sec, 0 packets/sec   5 minute output rate 0 bits/sec, 0 packets/sec      0 packets input, 0 bytes, 0 no buffer      Received 0 broadcasts, 0 runts, 0 giants, 0 throttles      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort      0 packets output, 0 bytes, 0 underruns      0 output errors, 0 collisions, 0 interface resets      0 output buffer failures, 0 output buffers swapped out      0 carrier transitions      DCD=up  DSR=up  DTR=up  RTS=up  CTS=up Sean2514# 

The preceding output shows an X.25 serial interface that has just come up operating properly.