Table of Contents

Cisco's Implementation of Protocol Translation

Number of Translation Sessions Supported
Support for Terminal Connections and Protocol Translation

Protocol Translation Configuration Task List
Configure One-Step Protocol Translation
Configure Two-Step Protocol Translation
Create X.29 Access Lists

Create an Access List
Apply an Access List to a Virtual Line

Create an X.29 Profile Script
Protocol Translation Application Configuration Examples

Basic Configuration Example
Local LAT-to-TCP Example
LAT-to-X.25 Host Example
X.25 PAD-to-LAT Example
X.25 PAD-to-TCP Example
LAT-to-LAT via X.25 Translation Example
LAT-to-TCP via X.25 Example
LAT-to-LAT over Frame Relay or SMDS Example
LAT-to-LAT over an IP WAN Example
Central Site Protocol Translation Example
Standalone LAT-to-TCP Translation Example
X.29 Access List Example
X.3 Profile Example

Configuring Protocol Translation

This chapter describes how to configure protocol translation connections. It assumes you understand how to use the configuration software. It provides procedures for specifying system-wide facilities, as well as application examples. Before continuing with this chapter, be sure that you are familiar with the information provided in the LAT, TN3270, and XRemote configuration chapters in this publication. For information on X.25 and TCP/IP (including TCP and Telnet), refer to the Router Products Configuration Guide and the Router Products Command Reference publications.

For more information about making connections and establishing translation sessions, see the Remote Access Server Connection Guide.

Cisco's Implementation of Protocol Translation

The protocol translation software attempts to provide transparent protocol translation between systems running disparate protocols. The software fully supports two-way virtual terminal protocol translation between nodes running X.25, Local Area Transport (LAT), and Telnet.

The software supports limited translation for XRemote (to X.25 PAD environments) and TN3270 (to LAT, X.25, and Telnet environments). However, there is no translation between other services such as file-transfer protocols. The protocol translator allows terminal users on one network to access hosts on another network, despite differences in the native protocol stacks associated with the originating device and the target host. You can use either of two methods to accomplish this:

• One-step method---This method provides full transparent protocol translation by means of the translate global configuration command.This command defines a connection and the translation protocols in the configuration file. Then you can make single-step connections to remote resources.

• Two-step method---Actual connections between devices are made by first establishing a connection to the protocol translator, then by establishing the outgoing connection to the remote destination.

Number of Translation Sessions Supported

The number of translation sessions supported depends on the hardware model and software version you are running. Table 5-1 summarizes the number of translation sessions supported in Internetwork Operating System (IOS) Release 10. Table 5-2 summarizes the number of translation sessions supported in Software Releases 9.0 through 9.21. Table 5-3 summarizes the number of sessions supported in Software Releases 8.3 and earlier.

Support for Terminal Connections and Protocol Translation

In the context of this discussion, a router set up to run protocol translation software is referred to as a protocol translator.

The protocol translator uses the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) Recommendation X.25 for transferring raw data over X.25 networks. The X.25 software supports both commercial and DDN versions. Protocol translators also support X.25 as a transport mechanism for IP packets, and X.3- and X.29-based PAD connections. This allows the protocol translators to connect to an X.25 public data network (PDN). This X.25 connection allows transport of TCP/IP packets across the X.25 packet-switching network in the same way as would occur on a protocol translator.

Routers without protocol translation do not support an X.25 PAD function, so they cannot communicate with hosts directly connected to the X.25 PDN. Routers encapsulate TCP/IP packets in X.25 packets for transfer over a packet-switching network. These packets can be received by routers, communication servers, and routers set up as protocol translators. Only protocol translators include PAD capabilities, but other servers can communicate with protocol translators using the TCP/IP or LAT protocols. Protocol translators can translate TCP/IP and LAT into X.25, and then communicate with X.25 hosts. Protocol translators support all PAD standards (X.28, X.29, and X.3). The connection to the packet-switching network is through a synchronous line.

Protocol Translation Configuration Task List

Perform the tasks in one of the following sections when setting up the use of protocol translation:

• Configure One-Step Protocol Translation

• Configure Two-Step Protocol Translation

Perform the tasks in the following sections to apply X.29 PAD connections under X.25:

• Create X.29 Access Lists

• Create an X.29 Profile Script

See the end of this chapter for protocol translation application examples.

Configure One-Step Protocol Translation

The one-step method of protocol translation invokes a translation session process to provide fully transparent protocol conversion. In this method, the protocol translator masquerades as two or more hosts on the same network. When a connection is made to the protocol translator, the protocol translator determines which host the connection is for and what protocol that host is using. The protocol translator then establishes a new network connection using the networking protocol required by that host. This network connection is more efficient and allows the protocol translator to act upon greater knowledge of the protocols in use because the protocol translator acts as a network connection rather than a terminal.

To create one-step protocol translation connection specifications, perform the following global configuration task:

For examples of using the one-step method, see the section "Protocol Translation Application Configuration Examples" later in this chapter.

Configure Two-Step Protocol Translation

In the two-step method, perform the following two steps:

In general, you use the two-step method when you want to use a protocol translator as a general-purpose gateway between two types of networks (for example, X.25 PDN and TCP/IP). Instead of configuring every possible connection via embedded translate commands, the two-step method allows you greater flexibility in terms of connecting to network resources accessible via the protocol translator.

The two-step method also allows additional security when TACACS and password protection is enabled. These security features are described in Router Products Configuration Guide, in the chapter "Configuring the System." Additionally, if you use the two-step method to connect, you can change X.25 PAD and local terminal parameters dynamically during a session.

Create X.29 Access Lists

The protocol translation software provides access lists, which make it possible to limit access to the protocol translator from certain X.25 hosts. Access lists take advantage of the message field defined by Recommendation X.29, which describes procedures for exchanging data between two PADs or between a PAD and a DTE device.

To define X.29 access lists, perform the following tasks:

Step 1 Create an access list.

Step 2 Apply an access list to a virtual line or to a translate command.

These tasks are described in the following sections.

When configuring protocol translation, you can specify an access list number with each translate command. In the case of translation sessions that result from incoming PAD connections, the corresponding X.29 access list is used.

Create an Access List

To specify the access conditions, perform the following global configuration task:

An access list can contain any number of lines. The lists are processed in the order in which you type the entries. The first match causes the permit or deny condition. If an X.121 address does not match any of the entries in the access list, access will be denied.

Apply an Access List to a Virtual Line

To apply an access list to a virtual line, perform the following tasks:

The access-list number is used both for incoming TCP access and for incoming PAD access. For TCP access, the protocol translator uses the defined IP access lists. For incoming PAD connections, the same X.29 access list is used. If you want to have access restrictions on only one of the protocols, you can create an access list that permits all addresses for the other protocol.

Create an X.29 Profile Script

You can create an X.29 profile script for use by the translate command. When an X.25 connection is established, the protocol translator then acts as if an X.29 SET PARAMETER packet had been sent that contained the parameters and values set by this command.

To create an X.29 profile script, perform the following global configuration task:

Protocol Translation Application Configuration Examples

The following sections describe examples of configuring protocol translation applications. The environment used in these examples is illustrated in Figure 5-1. The application environment described focuses on Cisco 3000 implementations. However, in applications featuring only protocol translation, any of the protocol translator products can be used.

• Basic Configuration Example

• Local LAT-to-TCP Example

• LAT-to-X.25 Host Example

• X.25 PAD-to-LAT Example

• X.25 PAD-to-TCP Example

• LAT-to-LAT via X.25 Translation Example

• LAT-to-TCP via X.25 Example

• LAT-to-LAT over Frame Relay or SMDS Example

• LAT-to-LAT over an IP WAN Example

• Central Site Protocol Translation Example

• Standalone LAT-to-TCP Translation Example

• X.29 Access List Example

• X.3 Profile Example

In these examples, a LAT device can be a LAT terminal server or LAT host, and a TCP device can be either a TCP terminal server or TCP host.

Basic Configuration Example

The following examples illustrate the basic global configuration commands and interface configuration commands for setting up 3000-A (connected to Network A) and 3000-B (connected to Network B), as illustrated in Figure 5-1. Refer to the chapter "Configuring LAT" in this publication, for more information on LAT. For information on configuring X.25, refer to the Router Products Configuration Guide.

The following partial configuration for device 3000-A outlines a baseline configuration for the device's Ethernet and serial interfaces and configures support for IP, LAT, and X.25:

The following partial configuration for device 3000-B outlines a baseline configuration for the device's Ethernet and serial interfaces and configures support for IP, LAT, and X.25:

Local LAT-to-TCP Example

A protocol translator such as the Cisco 3000 can translate between LAT and TCP (Telnet) traffic to allow communication among resources in these protocol environments. In Figure 5-2, the LAT device on Network A (LAT-A) is shown connecting to a TCP device (TCP-A).

This is only a partial example. The commands in this example would be only part of the complete configuration file for an individual protocol translator or router.

LAT-to-X.25 Host Example

The Cisco 3000 protocol translation option allows LAT devices to communicate with X.25 hosts through an X.25 PDN. In the application illustrated in Figure 5-3, LAT-A is a LAT device that is communicating with X25-C, an X.25 host. The LAT traffic from LAT-A is translated to X.25.

X.25 PAD-to-LAT Example

The Cisco 3000 protocol translation option allows terminals connected to X.25 PADs to communicate with LAT devices on a remote LAN (Figure 5-4). X.25 PAD terminals make a call using an X.121 address, which is translated to a LAT node. To the PAD terminal user, the connection appears to be a direct connection to a host on the X.25 PDN. The Cisco 3000 also supports X.29 access lists, which allow you to restrict LAN resources (LAT or TCP) available to the PAD user.

This configuration example typifies the use of access lists in Cisco internetworking systems. The first two lines define the scope of access-list 1. The first line specifies that access list 1 will permit all calls from X.121 address 44444. The caret symbol (^) specifies that the first number 4 is the beginning of the address number. Refer to the appendix "Regular Expressions" later in this publication for details concerning the use of special characters in defining X.121 addresses. The second line of the definition explicitly denies calls from any other number.

This access list is then applied to all incoming traffic on the serial port for 3000-A (X.121 address 1111101) with the third configuration line in the example. However, it applies only to the translate command at the end of this example. This translate command specifies that incoming X.25 packets on the serial line (with address 1111101) are translated to LAT and sent to LAT-A if they pass the restrictions of the access list.

If you define multiple X.25 translate commands, each must contain a unique X.121 address. It is also important that the ITU-T protocol used in transferring packets match among X.121 addresses. This is specified in the protocol identification field of call-user data. This field specifies whether a packet is routed, translated, or handled as a virtual terminal connection.

X.25 PAD-to-TCP Example

Making a translated connection from an X.25 PAD to a TCP device (Figure 5-5) is analogous to the preceding X.25 PAD-to-LAT example. Instead of translating to LAT, the 3000-A configuration includes a statement to translate to TCP (Telnet). Note that a protocol translator can include statements supporting both translations (X.25 PAD-to-LAT and X.25 PAD-to-TCP). Different users on the same PAD can talk to X.25, LAT, or TCP devices.

LAT-to-LAT via X.25 Translation Example

You can use protocol translators to provide transparent connectivity between LAT devices on different networks via an X.25 PDN. In Figure 5-6, which illustrates this application, the LAT device on Network A (LAT-A) first makes a virtual connection to the Cisco 3000 on Network A using the LAT protocol. The Cisco 3000 then translates the LAT packets into X.25 packets and sends them through the X.25 network to the Cisco 3000 on Network B. This second Cisco 3000 translates the X.25 packets back to LAT packets and establishes a virtual connection to the LAT device on Network B (LAT-B). These handoffs are handled transparently when the protocol translator is configured for a one-step translation.

To configure 3000-B to send information back from LAT-B to LAT-A, use commands symmetrical to the prior configuration (this path is not shown in Figure 5-6):

LAT-to-TCP via X.25 Example

You can use protocol translators to provide transparent connectivity between LAT and TCP devices on different networks via an X.25 PDN. In the application illustrated in Figure 5-7, the LAT device on Network A is communicating with the TCP device on Network B. There are two ways to provide this connectivity: the LAT traffic from Network A can be translated into either X.25 packets or TCP/IP packets to be sent out on the X.25 PDN.

If the traffic is translated from LAT directly into X.25 frames by 3000-A, then 3000-B on Network B translates incoming packets intended for device TCP-B into TCP. If 3000-A converts LAT to TCP, then the TCP traffic is being encapsulated in X.25 and sent on the X.25 network; the Cisco 3000 on Network B strips off the encapsulation and routes the TCP packet. In this case, protocol translation is not needed on 3000-B.

If the traffic is translated to TCP by 3000-A, the packets are encapsulated within X.25 frames. In general, translating the traffic directly to X.25 is more efficient in this application because no encapsulation is necessary. X.25 packets have only 5 bytes of header information, while TCP over X.25 has 45 bytes of header information.

LAT-to-LAT over Frame Relay or SMDS Example

To transport LAT traffic over a Frame Relay or an SMDS network, LAT must first be translated to TCP. The TCP traffic is routed over the Frame Relay network and then translated back to LAT on the Cisco 3000 on Network B. See Figure 5-8.

LAT-to-LAT over an IP WAN Example

The Cisco 3000 with protocol translation can be used to connect LAT devices over a WAN backbone that only allows routable protocols (see Figure 5-9). This configuration exists when LAT networks are either isolated or on their own internetwork.

With the Cisco 3000, LAT traffic can be translated to TCP and then routed on the WAN as TCP traffic. The LAT connections stay local between the LAT device and the Cisco 3000. Thus, connections are not susceptible to delays on the WAN. This reduces the amount of traffic on the WAN because only the data from specific LAT sessions is forwarded on the WAN rather than all the LAT protocol status information packets.

Central Site Protocol Translation Example

If you require the translation of protocols among multiple remote sites over an X.25 network, with retranslation at a central site, a Cisco 3000 might be required. The Cisco 3000 in this configuration allows more than 64 concurrent translation sessions.

To support this application, a Cisco 3000 is directly connected back-to-back (Figure 5-10) to another Cisco router. This second router acts as an X.25 switch, by sending X.25 packets to the Cisco 3000 while concurrently routing and bridging other protocols.

Because the Cisco 3000 is operating only as a protocol translator, it can support 100 concurrent protocol translation sessions compared to the 64 that are supported when the Cisco 3000 is routing, bridging, and translating protocols.

Standalone LAT-to-TCP Translation Example

If you need a large number of local LAT-to-TCP translation sessions, you can set up the Cisco 3000 to use only an Ethernet port. This application allows 100 concurrent translation sessions. In the applications illustrated in Figure 5-11, any other Cisco router, including a Cisco 3000, can be used to interconnect network segments performing bridging or routing.

X.29 Access List Example

The following example illustrates an X.29 access list. Incoming permit conditions are set for all IP hosts and LAT nodes that have specific characters in their names. All X.25 connections to a printer are denied. Outgoing connections are restricted.

X.3 Profile Example

The following profile script turns local edit mode on when the connection is made and establishes local echo and line termination upon receipt of a Return. The name "linemode" is used with the translate command to effect use of this script.

The X.3 PAD parameters are described in the appendix "X.3 PAD Parameters" later in this publication, and in the Remote Access Server Connection Guide.

Posted: Wed May 12 14:51:54 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.