Networking

Running X.25 over TCP/IP on Cisco routers

Although having fiber almost negates the need for the X.25 protocol, there may be a situation (budgetary, etc.) that would dictate the need for using the X.25 protocol over TCP/IP. Alexander Prohorenko is here to tell you how to work this cheap magic.


In this Daily Drill Down, I'm going to discuss a very specific problem: running the X.25 protocol encapsulation over TCP/IP networks. This technology isn't very widely used, but it holds a high position in banking structures, since the most popular ATMs use the X.25 protocol to communicate with billing and processing centers. Encapsulating X.25 over TCP/IP networks allows you to save a lot of money. How? Simple—you use existing IP backbones and links, so you don’t have to waste money on building quite different X.25 links. You can then encrypt the X.25 traffic through the IP networks using any brain-cracking method, and this will guarantee security for you and your customers. And you can use a processing center somewhere overseas rather than pay the high cost of renting channels.

The technology
Okay, now let’s turn to the technical side. In my sample configuration, I have two points that should be connected to each other running X.25 traffic. I'm going to use two Cisco routers: one 1720 (from the X.25 switch/concentrator side) and one 805 (from the ATM side). The model and type of X.25 switch and ATM don't matter, since we’re not going to use specific hardware.
Just for your information, in my lab, I have a concentrator from Case Technologies (model 8295) and a Diebold ATM (bank machine) running IBM OS/2 Warp. I have also successfully tried the same configuration on a few NCR and Olivetti bank machines, so the hardware is not really an issue.
I'm going to use the XOT (X25 Over TCP) technology from Cisco for running X.25 over TCP/IP on Cisco routers. This allows X.25 packets to be sent over a TCP/IP network instead of a LAPB (Link Access Procedure, Balanced) link. In essence, we’ll tunnel X.25 traffic through an IP cloud. For example, we’ll connect two X.25 clouds that have no physical connection with a virtual TCP tunnel across the IP cloud. For more detailed technical information on the protocol, you might look at RFC 1613 or at Cisco's press-release site.

Choosing the correct IOS
Now it's time for a few words about the Internetworking Operating System (IOS). Choosing the correct IOS is a headache for Cisco's engineers. For the 1720 router, I'm going to use the c1700-y-mz.120-5.T1 image. This particular image is the IOS 12.0(3)T image with no additional feature set and with the X.25 software (version 3.0.0). For the 805 router, I’ll use the c805-sy6-mw.121-3.XG image, which is the IOS 12.1.3XG.
The above image is the only IOS I know of right now that has XOT support for the 805 platform! I’ve spent a lot of time playing with the c805-sy6-mw.120-4.XM image and even with the c805-sy6-mw.121-5 image, but I couldn't run the X.25 encapsulation. The reason was that these images include support for XOT syntax and debugging but no functionality! So the only thing that you'll be able to see is never-ending error messages. (You may ask how I came to this conclusion. It wasn’t easy. To figure out the reason for these errors, I built up the same scheme but used only the 1720 routers, and it worked! After that, I started investigating the problem in 805 routers and found it isolated in the IOS image.)
Cisco's configuration
It looks like we're ready to start our Cisco configuration. Our Cisco 805, which is placed near the ATM, will be named atm1-1, which stands for “ATM 1 linked to concentrator 1.” To connect this Cisco device to the ATM, we’ll use a CAB-SS-232FC Smart-Serial cable, DCE. Since the ATM is also a DTE (Data Terminal Equipment) device, our Cisco router can be the DCE (Data Circuit terminating Equipment). We also need to coordinate a few parameters for the concentrator. As a rule, you should know the following parameters:
  • clockrate: A port's clocking rate. The following special standard values are not subject to rounding: 1200, 2400, 4800, 9600, 14400, 19200, 28800, 38400, 56000, 64000, 128000, 2015232. Accepted clockrates will be rounded to the nearest value supportable by the hardware. We'll use 9600 in the port.
  • x25 htc: X.25 highest two-way channel. Set to 16.
  • x25 ltc: X.25 lowest two-way channel. Set to 1 (default).
  • x25 win: X.25 input window (maximum unacknowledged packets). Set to 3.
  • x25 wout: X.25 output window (maximum unacknowledged packets). Set to 3.
  • x25 ips: X.25 maximum input packet size. Set to 256.
  • x25 ops: X.25 maximum output packet size. Set to 256.
  • x25 facility windowsize: X.25 windowsize (in/out) facilities to be held in Call. Set to 3 3.
  • x25 facility packetsize: X.25 packetsize (in/out) facilities to be held in Call. Set to 256 256.

The entire port configuration should look like this:
atm1-1#show running-conf interface serial 0
Building configuration...

Current configuration:
!
interface Serial0
 description DIEBOLD ATM
 no ip address
 no ip directed-broadcast
 encapsulation x25 dce
 x25 htc 16
 x25 ips 256
 x25 ops 256
 x25 default pad
 x25 facility windowsize 3 3
 x25 facility packetsize 256 256
 clockrate 9600
!


Now, let's look at the port. Is everything okay here?
atm1-1#show interface serial 0
Serial0 is up, line protocol is up
 Hardware is PowerQUICC Serial
 Description: DIEBOLD ATM
 MTU 1500 bytes, BW 2048 Kbit, DLY 20000 usec,
  reliability 255/255, txload 1/255, rxload 1/255
 Encapsulation X25, loopback not set
 X.25 DCE, address <none>, state R1, modulo 8, timer 0
  Defaults: idle VC timeout 0
  cisco encapsulation
  input/output window sizes 2/2, packet sizes 256/256
  Timers: T10 60, T11 180, T12 60, T13 60
  Channels: Incoming-only none, Two-way 1-16, Outgoing-only none
  RESTARTs 9/0 CALLs 0+0/0+0/0+0 DIAGs 0/0
 LAPB DCE, state CONNECT, modulo 8, k 7, N1 12056, N2 20
  T1 3000, T2 0, interface outage (partial T3) 0, T4 0
  VS 6, VR 6, tx NR 6, Remote VR 6, Retransmissions 0
  Queues: U/S frames 0, I frames 0, unack. 0, reTx 0
  IFRAMEs 1024/884 RNRs 0/0 REJs 0/0 SABM/Es 1/3 FRMRs 0/0 DISCs 0/0
 Last input never, output 00:01:36, output hang never
 Last clearing of "show interface" counters 01:32:00
 Queueing strategy: fifo
 Output queue 0/40, 0 drops; input queue 0/75, 0 drops
 5 minute input rate 0 bits/sec, 0 packets/sec
 5 minute output rate 0 bits/sec, 0 packets/sec
  1915 packets input, 22112 bytes, 0 no buffer
  Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
  1 input errors, 1 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
  1912 packets output, 29572 bytes, 0 underruns
  0 output errors, 0 collisions, 4 interface resets
  0 output buffer failures, 0 output buffers swapped out
  2 carrier transitions
  DCD=up DSR=up DTR=up RTS=up CTS=up


For more detailed monitoring of the port, you can use the show controller serial 0 command. In our case, everything looks great, so we can proceed. Now we must enable debug for the X.25 process. We simply need to see the processes taking place on the Serial 0 interface:
atm1-1#show debug
X.25 (filtered for X.25 on Serial0):
 X.25 packet debugging is on


And don’t forget to enable buffered logging on the Cisco router. From my experience, I suggest that you not enable logging console on the Cisco router until you have more than two consoles connected. Numerous logging messages on a console make it work really hard.

Now it's time to go to the Cisco router, which is placed near our concentrator:
ct1#show running-conf interface serial 0
Building configuration...

Current configuration:
!
interface Serial0
 description CASE SWITCH
 no ip address
 no ip directed-broadcast
 encapsulation x25
 x25 htc 16
 x25 win 3
 x25 wout 3
 x25 ips 256
 x25 ops 256
 x25 facility packetsize 256 256
 clockrate 9600
end


Next, let's look at the port:
ct1#show interface serial 0
Serial0 is up, line protocol is up
 Hardware is PowerQUICC Serial
 Description: CASE SWITCH
 MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec,
  reliability 255/255, txload 1/255, rxload 1/255
 Encapsulation X25, loopback not set
 X.25 DTE, address <none>, state R1, modulo 8, timer 0
  Defaults: idle VC timeout 0
  cisco encapsulation
  input/output window sizes 3/3, packet sizes 256/256
  Timers: T20 180, T21 200, T22 180, T23 180
  Channels: Incoming-only none, Two-way 1-16, Outgoing-only none
  RESTARTs 4/0 CALLs 0+0/0+0/0+0 DIAGs 0/0
 LAPB DTE, state CONNECT, modulo 8, k 7, N1 12056, N2 20
  T1 3000, T2 0, interface outage (partial T3) 0, T4 0
  VS 0, VR 4, tx NR 4, Remote VR 0, Retransmissions 0
  Queues: U/S frames 0, I frames 0, unack. 0, reTx 0
  IFRAMEs 35/52 RNRs 0/0 REJs 0/0 SABM/Es 2/2 FRMRs 0/0 DISCs 0/1
 Last input never, output 00:00:12, output hang never
 Last clearing of "show interface" counters never
 Queueing strategy: fifo
 Output queue 0/40, 0 drops; input queue 0/75, 0 drops
 5 minute input rate 0 bits/sec, 0 packets/sec
 5 minute output rate 0 bits/sec, 0 packets/sec
  140 packets input, 1033 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
  167 packets output, 1869 bytes, 0 underruns
  0 output errors, 0 collisions, 6 interface resets
  0 output buffer failures, 0 output buffers swapped out
  8 carrier transitions
  DCD=up DSR=up DTR=up RTS=up CTS=up


Now we must repeat the same operations for enabling logging on the Cisco router, and then we'll be ready to start the XOT process.

Let's suppose that we already have a TCP/IP link between these two routers and that they are visible to each other. The atm1-1 uses IP 10.1.0.1 and ct1 uses IP 10.0.0.1.

The bank machine's X.121 address is 1122334455667 (13 digits), and the processing center's address is 11223344559 (11 digits). The bank machine should act as a caller, which means that the ATM will initiate the connection to the processing center.
I'm not using exact definitions. Our bank machine actually has no X.121 address, but the port on the concentrator does. And our ATM, being an end device on the port, is accessible by this address. To simplify the explanation, however, it's acceptable to say that the ATM has an X.121 address.
XOT configuration
The XOT configuration is pretty much like the IP configuration. You must set the correct routing tables for X.121 addresses. We'll start from the atm1-1 setup. First, we need to create the correct routing table. What should it be? To access 11223344559, we have to route packets through the IP network to 10.0.0.1 (the IP address of the concentrator's Cisco router). To access 1122334455667 (the ATM), we have to route packets to the serial port. Okay, let’s write this down:
atm1-1#configure terminal
atm1-1(config)#x25 route 1122334455667 interface Serial0
atm1-1(config)#x25 route 11223344559 xot 10.0.0.1
atm1-1(config)#exit


Now we can give a shot to the logs on ct1:
ct1#show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
 Console logging: disabled
 Monitor logging: level debugging, 0 messages logged
 Buffer logging: level debugging, 6386 messages logged
 Trap logging: level informational, 25 message lines logged

Log Buffer (4096 bytes):
00:20:25: Serial0: X.25 O R/Inactive Restart (5) 8 lci 0
00:20:25: Cause 0, Diag 0 (DTE originated/No additional information)
00:20:25: Serial0: X.25 I R2 Restart (5) 8 lci 0
00:20:25: Cause 7, Diag 0 (Network operational/No additional information)
00:20:25: Serial0: X.25 O R1 Call (20) 8 lci 16
00:20:25: From(13): 1122334455667 To(11): 11223344559
00:20:25: Facilities: (3)
00:20:25:  Window sizes: 2 2
00:20:25: Serial0: X.25 I R1 Clear (5) 8 lci 16
00:20:25: Cause 9, Diag 0 (Out of order/No additional information)


The log is clear. The ct1 got the call through the XOT from atm1-1, but since it has no routing table for these addresses, it sends a Clear back.

Let's set up the XOT routing table here. The scheme is very simple. To access 11223344559 (the processing center), we have to route packets to the port of the concentrator. To access 1122334455667 (the ATM), we have to route packets through the IP bone to 10.1.0.1 (the IP address of the ATM's Cisco router):
ct1#configure terminal
ct1(config)#x25 route 1122334455667 xot 10.1.0.1
ct1(config)#x25 route 11223344559 interface Serial0
ct1(config)#exit


How does it look now?
ct1#show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
 Console logging: disabled
 Monitor logging: level debugging, 0 messages logged
 Buffer logging: level debugging, 6386 messages logged
 Trap logging: level informational, 25 message lines logged

Log Buffer (4096 bytes):
00:20:33: Serial0: X.25 O R1 Call (20) 8 lci 14
00:20:33: From(13): 1122334455667 To(11): 11223344559
00:20:33: Facilities: (3)
00:20:33:  Window sizes: 2 2
00:20:33: Serial0: X.25 I R1 Call Confirm (17) 8 lci 14
00:20:33: From(0): To(11): 11223344559
00:20:33: Facilities: (6)
00:20:33:  Packet sizes: 256 256
00:20:33:  Window sizes: 2 2
00:20:35: Serial0: X.25 I D1 Data (17) 8 lci 14 PS 0 PR 0
00:20:36: Serial0: X.25 O D1 Data (31) 8 lci 14 PS 0 PR 1
00:20:36: Serial0: X.25 I D1 RR (3) 8 lci 14 PR 1
00:20:37: Serial0: X.25 I D1 Data (17) 8 lci 14 PS 1 PR 1
00:20:41: Serial0: X.25 O D1 Data (94) 8 lci 14 PS 1 PR 2
00:20:41: Serial0: X.25 I D1 RR (3) 8 lci 14 PR 2


Bingo! We have Call Confirm after the Call and Data circuits run. It looks like we did it! But, to be sure, let's look at the X.25 virtual circuit state on the ATM's Cisco router (atm1-1):
atm1-1#show x25 vc
SVC 16, State: D1, Interface: Serial0
 Started 00:00:12, last input 00:00:03, output 00:00:00
 Connects 1122334455667 <—> 11223344559 to
 XOT between 10.1.0.1, 11245 and 10.0.0.1, 1998
 Window size input: 2, output: 2
 Packet size input: 256, output: 256
 PS: 3 PR: 2 ACK: 2 Remote PR: 2 RCNT: 0 RNR: no
 P/D state timeouts: 0 timer (secs): 0
 data bytes 42/119 packets 3/2 Resets 0/0 RNRs 0/0 REJs 0/0 INTs 0/0
SVC 1, State: D1, Interface: [10.0.0.1,1998/10.1.0.1,11245]
 Started 00:00:12, last input 00:00:00, output 00:00:03
 Connects 1122334455667 <—> 11223344559 from Serial0 SVC 16
 Window size input: 2, output: 2
 Packet size input: 256, output: 256
 PS: 2 PR: 3 ACK: 2 Remote PR: 2 RCNT: 1 RNR: no
 P/D state timeouts: 0 timer (secs): 0
 data bytes 119/42 packets 2/3 Resets 0/0 RNRs 0/0 REJs 0/0 INTs 0/0


Yes, everything works great. The VCs were successfully set up and are running. That's it! We can now save the Cisco configurations to the NVRAM and begin taking credit card transactions using our new ATM.

Conclusion
To crown it all, I would like to say that this setup was easy enough. The most important thing you have to remember is to keep the parameters synchronized on the Cisco concentrator and ATM. Everything else is just routine. I hope that the technique in this Daily Drill Down will help you, or your company, save a good deal of money. The best of luck to you.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks