Terminal Services Configuration Guide, Cisco IOS XE Release 16.x

Definition of Protocol Translation

The protocol translation feature provides transparent protocol translation between systems running different protocols. It enables terminal users on one network to access hosts on another network, despite differences in the native protocol stacks associated with the originating device and targeted host.

Protocol translation is a resourceful facility for many business applications. For example, Figure 1 shows a remote PC dialing through an IP network and connecting to an X.25 host. The TCP packets on the PC undergo a TCP-to-X.25 protocol translation by the Cisco 4700-M router.

Figure 1 Protocol Translation Business Application

Definition of Tunneling

Unlike other protocols such as LAT, X.25, and TCP, which are actually translated when you use protocol translation, SLIP, PPP, and ARA are not translated to the destination protocol. Instead, they are carried inside a LAT, X.25, TCP, or Layer 2 Forwarding Protocol (L2F) tunnel specific to the device on the remote network. However, the protocol translation facility is used to enable tunneling of SLIP, PPP, or ARA.

Figure 2 shows a typical tunneling scenario.

Figure 2 Tunneling X.25 with PPP Across an IP Network

You can also tunnel PPP-IPX over X.25, TCP, or LAT to an Internetwork Packet Exchange (IPX) network when tunneling PPP on virtual terminal lines.

Deciding Whether to Use One-Step or Two-Step Protocol Translation

Cisco IOS software supports virtual terminal connections in both directions between the following protocols. You can configure the router to translate automatically between them. This translation method is called one-step translation, and is more popular than the two-step method.

• X.25 and LAT
• X.25 and Telnet sessions using the TCP
• LAT and TCP/Telnet

On outgoing connections, you can also use the one-step protocol translation facility to tunnel SLIP or PPP to IP and IPX networks, or ARA to AppleTalk networks across X.25, LAT, or IP (on outgoing connections only).

Cisco IOS software supports limited connections in both directions between the following protocols. Connecting between these protocols requires that you first connect to a router, and then to the host to which you want to connect. This translation method is called two-step translation, and is the less popular method.

• XRemote to SLIP/PPP and X.25 PAD environments (XRemote must use the two-step method)
• LAT, X.25, SLIP/PPP, and TCP (Telnet) to TN3270 (TN3270 must use the two-step method)

One-Step Protocol Translation

Use the one-step method when network users repeatedly log in to the same remote network hosts through a router. This connection is more efficient than the two-step method and enables the device to have more knowledge of the protocols in use because the router acts as a network connection rather than as a terminal. The one-step method provides transparent protocol conversion. When connecting to the remote network host, the user enters the connection command to the remote network host but does not need to specify protocol translation. The network administrator has already created a configuration that defines a connection and the protocols to be translated. The user performs only one step to connect with the host.

When you make a one-step connection to the router, the Cisco IOS software determines the host for the connection and the protocol the host is using. It then establishes a new network connection using the protocol required by that host.

A disadvantage of the one-step protocol translation method is that the initiating computer or user does not know that two networking protocols are being used. This limitation means that parameters of foreign network protocols cannot be changed after connections are established. The exception to this limitation is any set of parameters common to both networking protocols; any parameter common to both can be changed from the first host to the final destination.

To configure the one-step method of protocol translation, set up the following protocols and connection options in the configuration file:

• The incoming connection—The configuration includes the protocol to be used—LAT, X.25, or TCP/IP (Telnet)—the address, and any options such as reverse charging or binary mode that are supported for the incoming connection.
• The outgoing connection—The outgoing connection is defined in the same way as the incoming connection, except that SLIP, PPP (including IP and IPX on PPP sessions), and ARA are also supported.
• The connection features global options—You can specify additional features for the connection to allow, for example, incoming call addresses to match access list conditions or limit the number of users that can make the connection.

Refer to the “Protocol Translation Configuration Task List” section for configuration tasks.

Two-Step Protocol Translation

Use two-step protocol translation for one-time connections or when you use the router as a general-purpose gateway between two types of networks (for example, X.25 public data network (PDN) and TCP/IP). As with the one-step method, it is recommended that you configure virtual templates for this feature.

Note Use the two-step method for translations of TN3270 and XRemote.

With the two-step connection process, you can modify the parameters of either network connection, even while a session is in process. This process is similar to connecting a group of terminal lines from a PAD to a group of terminal lines from a TCP server. The difference is that you do not encounter the wiring complexity, unreliability, management problems, and performance bottlenecks that occur when two devices are connected via asynchronous serial lines.

Refer to the “Protocol Translation Configuration Task List” section for configuration tasks.

Tunneling SLIP, PPP, and ARA

Unlike other protocols such as LAT, X.25, and TCP, which actually are translated when you use one-step protocol translation, SLIP, PPP, and ARA are not translated to the destination protocol. Instead, they are carried inside a LAT, X.25, or TCP tunnel specific to the device on the remote network. However, you can use the protocol translation facility to enable tunneling of SLIP, PPP, or ARA.

You can also tunnel IPX-PPP over X.25, TCP, or LAT, to an IPX network when tunneling PPP on virtual terminal lines. Refer to the “Configuring X.29 Access Lists” section for configuration tasks.

Configuring One-Step Protocol Translation

To create one-step protocol translation connection specifications, use the following command in global configuration mode:

For incoming PAD connections, the router uses a default PAD profile to set the remote X.3 PAD parameters unless a profile script is defined in the translate command. To override the default PAD profile that the router uses, you must create a PAD profile script using the x29 profile global configuration command. In the following example, default is the name of the default PAD profile script and parameter:value is the X.3 PAD parameter number and value separated by a colon.

Note If the X.29 profile is named default, it is applied to all incoming X.25 PAD calls, including the calls used with protocol translation.

Configuring a Virtual Template for Two-Step Protocol Translation

If you are tunneling PPP or SLIP using two-step protocol translation with virtual interface templates, you will still use the vty-async command before implementing virtual templates. However, virtual asynchronous interfaces are created dynamically when a tunnel connection is established.

To create and configure a virtual interface template and apply it to a two-step protocol translation session, use the following commands in global configuration mode:

Other asynchronous configuration commands can be added to the virtual template configuration. For example, you can enter the ppp authentication chap command. It is recommended that you include security on your virtual interface template.

Configuring X.29 Access Lists

Cisco IOS software provides access lists to limit access to a router 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 tasks described in these sections:

• Creating an X.29 Access List (required)
• Applying an Access List to a Virtual Line (required)

Note 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.

Creating an X.29 Access List

To specify the access conditions, use the following command in global configuration mode:

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.

Applying an Access List to a Virtual Line

To apply an access list to a virtual line, use the following command in line configuration mode:

The access list number is used for incoming TCP and PAD accesses. For TCP access, the access server or router using protocol translation uses the defined IP access lists. For incoming PAD connections, the same X.29 access list is used. If you want to apply access restrictions on only one of the protocols, create an access list that permits all addresses for the other protocol.

Note For an example of including an access list in a translate command.

Background Definitions and Terms

X.29 encodes the PAD Call User Data (CUD) field in the call packet to indicate that the call request signifies a PAD-to-DTE device interaction.The CUD field is 16 bytes long and can be up to 128 bytes long when the “Select” facility is applied. The first 4 bytes of the CUD field represent the protocol identifier (PID).

When a PAD calls a host DTE device, X.29 ensures that the encoding of the PID field contains a standard PAD PID “0x01000000,” which informs the host that a PAD is calling. The remainder of the CUD field contains the user data that could signify a login message or a password for the host.

The x25 map pad interface command specifies the other end of a connection and how to interact with that host. For incoming calls, the PAD checks for a matching SOURCE address in the map entry. For outgoing calls, the PAD checks for a matching DESTINATION address in the map entry.

The x25 map pad commands are used to configure PAD and protocol translation accesses. They are also used to override the configuration of the interface on a per-destination basis.

The following example shows how to configure an X.25 interface to restrict incoming PAD access to a single mapped host. This example requires that both incoming and outgoing PAD accesses use the Network User Identification (NUID) to authenticate the user.

Accepting a PAD Call

An incoming PAD call is accepted by a Cisco router if the destination address matches the following criteria:

• A translation entry.
• The interface address.
• An alias of an interface.
• The address of the interface with trailing zeros.
• An interface subaddress.
• A NULL address.
• The address for the router set by the x25 host command.

When a Cisco router receives a call that requires protocol translation, the protocol translator searches the translation table for an entry with a regular expression in the X.121 address and the CUD field that matches the incoming X.121 address and the user data part of the CUD (the default PAD PID is not included).

If the PID is a nonstandard value (not equal to 0x01000000), the protocol translator searches the translation table for an entry with a regular expression in the X.121 address and the CUD field that matches the entire CUD (PID and user data).

For example, an incoming call to destination 417262510195 with a standard PAD PID of 0x01000000 and no user data will match the following translation entry:

An incoming call to destination 417262510195 with an unknown PID of 1234 and user data zayna will match the following translation entry:

An incoming call to destination 417262510195 with a standard PAD PID of 0x01000000 and user data zayna will match the following translation entry:

Note Using the translate command, you can specify the CUD field in ASCII, octal, or hexadecimal format. You cannot enter CUD values in hexadecimal format using the pad command. However, you can enter the octal equivalents of CUD hexadecimal values using the following command syntax:

pad x121-address /cud \307\021

In the following example, the regular expression CUD field allows an incoming call to destination 31200100994301 with a standard PAD PID of 0x01000000 and User Data 0xD0< whatever > to match the following translation entry:

Note The PID cannot be eliminated. The entire CUD field cannot be 0. The PAD uses the PID length to determine if a PID was entered. Therefore, using the characters "" or \000 will be interpreted as if no PID was given.

Processing Outgoing PAD Calls Initiated by Protocol Translation

Specifying the use-map Option on Outgoing PAD and Protocol Translation Connections

Specifying the use-map option on the pad EXEC command or the translate global configuration command (as an outgoing protocol option) allows the optional PID, CUD, and facilities to be applied on a per-PAD connection or protocol-translation basis. If you specify the use-map option on the PAD connection or on the translate command, the DESTINATION address and (optional) PID and CUD are checked against a list of entries configured with the x25 map pad command.

When a match is found and the corresponding interface is available (up), the call is placed on that interface and the x25 map options, including facilities, are applied on the outgoing call. Otherwise, the PAD call is refused.

Note The use-map option is not supported on outgoing protocol translation PVCs.

For example, entering the use-map option on the pad EXEC command returns the following:

The interface in this example is configured for a window size of 7 and a packet size of 256.

The following example specifies the use-map option so that the outgoing PAD connection will override the interface facilities and apply a window size of 2, a packet size of 1024, and reverse charging on the outgoing PAD call:

The following example specifies the use-map option so that a translation of the following outgoing PAD connection will cause the Call Request to be sent with a standard PAD PID and the user data to be sent in hexadecimal format:

The following example specifies the use-map options so that this outgoing PAD connection will cause the Call Request to be sent with a nonstandard PAD PID of 0x0E and user data hello :

Applying the X.25 Route Table on Outgoing PAD and Protocol Translation Connections

When the use-map option is not specified on the pad EXEC command or the translate global configuration command as an outgoing protocol option, the PAD or the protocol translator locates the X.121 destination address in the X.25 route table to determine the interface on which to establish the outgoing switched virtual circuits (SVC) or permanent virtual circuits (PVCs). The destination address and optional CUD are checked against the configured list of X.25 route entries. If a matching route entry is found and the corresponding interface is operational, the call is placed on that interface. If the interface is not operational or out of available virtual circuits, the lookup for the next matching route is continued.

If the route disposition is clear, the PAD call is refused. If the route lookup does not match any valid entry, the call is placed on the first configured X.25 interface. If the default interface (that is, the first configured X.25 interface, which may or may not be up or available) is not operational or out of available virtual circuits, the PAD call is refused.

Monitoring and Maintaining a Virtual Access Interface

When a virtual interface template is applied to a protocol translation session, a virtual access interface is created dynamically. This is the only way a virtual access interface can be created. To display or clear a specific virtual access interface, use any of the following commands in user EXEC mode:

Displaying a Virtual Asynchronous Interface

To view information about the vty when the configuration of a virtual interface template is cloned to a vty configured as a virtual access interface for two-step protocol translation, use the following command in EXEC mode:

Troubleshooting Virtual Asynchronous Interfaces

The following example shows the debug command output for the router redmount. It also shows the output for a specific vty-async interface. The vty-async command configures all virtual terminal lines on a router to support asynchronous protocol features.

Logging vty-Asynchronous Authentication Information to the Console Terminal

To log significant vty-asynchronous authentication information to the console terminal, use the following command in global configuration mode:

Logging vty-Asynchronous Authentication Information to a Buffer

To log significant vty-asynchronous authentication information to a buffer, use the following commands in global configuration mode as needed:

Logging vty-Asynchronous Authentication Information to a UNIX Syslog Server

To log significant vty-asynchronous authentication information to a UNIX syslog server, use the following commands in global configuration mode as needed:

One-Step Examples

• Tunnel PPP Across X.25: Example
• Tunnel SLIP Across X.25: Example
• Tunnel PPP Across X.25 and Specify CHAP and Access List Security: Example
• Tunnel PPP with Header Compression On: Example
• Tunnel IPX-PPP Across X.25: Example

Tunnel PPP Across X.25: Example

The following example shows a virtual interface template that specifies a peer IP address of 172.18.2.131, which is the IP address of the PC in Figure 3. The virtual interface template explicitly specifies PPP encapsulation. The translation is from X.25 to PPP, which enables tunneling of PPP across an X.25 network, as shown in Figure 3.

Figure 3 Tunneling PPP Across an X.25 Network

Tunnel SLIP Across X.25: Example

The following example uses SLIP encapsulation instead of PPP encapsulation on the virtual interface:

Tunnel PPP Across X.25 and Specify CHAP and Access List Security: Example

The following example uses PPP encapsulation on the virtual terminal interface, although it is not explicitly specified. It also uses CHAP authentication and an X.29 access list.

Tunnel PPP with Header Compression On: Example

The following example uses TCP header compression when tunneling PPP across X.25:

Tunnel IPX-PPP Across X.25: Example

The following example shows how to tunnel IPX-PPP across the X.25 network. It creates an internal IPX network number on a loopback interface, and then assigns that loopback interface to the virtual interface template.

Two-Step Examples

• Two-Step Tunneling of PPP with Dynamic Routing and Header Compression: Example
• Two-Step Tunneling of PPP with Dynamic Routing, TACACS, and CHAP: Example

Two-Step Tunneling of PPP with Dynamic Routing and Header Compression: Example

The following example uses the default PPP encapsulation on the virtual template.

After users connect to the router (in this example, named waffler), they invoke the ppp command to complete the two-step connection:

Two-Step Tunneling of PPP with Dynamic Routing, TACACS, and CHAP: Example

The virtual template interface in the following example uses the default encapsulation of PPP and applies CHAP authentication with TACACS+:

X.25 PAD-to-TCP Configuration: Example

Making a translated connection from an X.25 PAD to a TCP device is analogous to the preceding X.25 PAD-to-LAT example. (See Figure 4.) Instead of translating to LAT, the configuration for Router-A includes a statement to translate to TCP (Telnet). Note that a router with the protocol translation software option can include statements supporting both translations (X.25 PAD to LAT and X.25 PAD to TCP). Different users on the same PAD can communicate with X.25, LAT, or TCP devices.

Figure 4 X.25 PAD-to-TCP Translation

The following example shows how to use the translate global configuration command to translate from an X.25 PAD to a TCP device on Network A. It is applied to Router-A.

One-Step Method for TCP-to-X.25 Host Connections: Example

This example demonstrates one-step protocol translation featuring a UNIX workstation user making a connection to a remote X.25 host named host1 over an X.25 PDN. The router automatically converts the Telnet connection request to an X.25 connection request and sends the request as specified in the system configuration.

A connection is established when you enter the telnet EXEC command at the UNIX workstation system prompt, as follows:

Note This example implicitly assumes that the name host1 is known to the UNIX host (obtained via DNS, IEN116, or a static table) and is mapped to the IP address used in a translate command.

The router accepts the Telnet connection and immediately forms an outgoing connection with remote host1 as defined in a translate command.

Next, host1 sets several X.3 parameters, including local echo. Because the Telnet connection is already set to local echo (at the UNIX host), no changes are made on the TCP connection.

The host1 connection prompts for a username, then host1 sets the X.3 parameters to cause remote echo (the same process as setting X.3 PAD parameter 2:0), and prompts for a password. Cisco IOS software converts this request to a Telnet option request on the UNIX host, which then stops the local echo mode.

At this point, the user is connected to the PAD application and the application will set the X.3 PAD parameters (although they can always be overridden by the user). When finished with the connection, the user escapes back to the host connection, and then enters the appropriate command to close the connection.

The host named host1 immediately closes the X.25 connection. The Cisco IOS software then drops the TCP connection, leaving the user back at the UNIX system prompt.

Using the Two-Step Method for TCP-to-PAD Connections: Example

To use the two-step method for making connections, perform the following steps:

Step 1 Connect directly from a terminal or workstation to a router.

For example, you might make the following connection requests at a UNIX workstation as a first step to logging in to the database named Information Place on an X.25 PDN:

If the router named orion is accessible, it returns a login message, and you can enter your login name and password.

Step 2 Connect from the router to Information Place, which is on an X.25 host. You connect to an X.25 host using the pad EXEC command followed by the service address:

Once the connection is established, the router immediately sets the PAD to single-character mode with local echoing, because these are the settings the router expects. The PAD responds with its login messages and a prompt for a password:

Because the password should not echo on your terminal, the PAD requests remote echoing so that characters will be exchanged between the PAD and the router, but not echoed locally or displayed. After the password is verified, the PAD again requests local echoing from the router, which it does from then on.

To complete this sample session, log out to return to the router system EXEC prompt and enter the EXEC quit command; the router drops the network connection to the PAD.

Two-Step Protocol Translation for TCP-to-PAD Connections: Example

The following example shows a connection from a local UNIX host named host1 to a router named router1 as the first step in a two-step translation process:

The following sample session shows a connection from Router1 to a host named ibm3278 as the second step in a two-step translation process:

Next, connect directly from a terminal or workstation on a TCP/IP network to a router, and then to a database named Information Place on an X.25 packet data network. The database has a service address of 71330.

To complete the two-step translation connection, perform the following steps:

Step 1 Make the following connection requests at a UNIX workstation as a first step to logging in to the database Information Place:

If the router named router1 is accessible, it returns a login message and you can enter your login name and password.

Step 2 Connect from the router to the Information Place, which is on an X.25 host. You connect to an X.25 host using the pad EXEC command followed by the service address:

Once the connection is established, the router immediately sets the PAD to single-character mode with local echoing, because these are the settings that the router expects. The PAD responds with its login messages and a prompt for a password.

Because the password should not echo on your terminal, the PAD requests remote echoing so that characters will be exchanged between the PAD and the router, but not echoed locally or displayed. After the password is verified, the PAD again requests local echoing from the router.

Step 3 Complete the session by logging out, which returns you to the router system EXEC prompt.

Step 4 Enter the quit EXEC command; the router drops the network connection to the PAD.

Changing Parameters and Settings Dynamically: Example

The following sample session shows how to make a dynamic change during a protocol translation session. In this sample, you will edit information on the remote host named Information Place. To change the X.3 PAD parameters that define the editing characters from the default Delete key setting to the Ctrl-D sequence, perform the following steps:

Step 1 Enter the escape sequence to return to the system EXEC prompt:

Step 2 Enter the resume command with the /set keyword and the desired X.3 parameters. X.3 parameter 16 sets the Delete function. ASCII character 4 is the Ctrl-D sequence.

The session resumes with the new settings, but the information is not displayed correctly. You may want to set the / debug switch to check that your parameter setting has not been changed by the host PAD.

Step 3 Enter the escape sequence to return to the system EXEC prompt, and then enter the resume command with the / debug switch.

The / debug switch provides helpful information about the connection.

You can also set a packet dispatch character or sequence using the terminal dispatch-character command. The following example shows how to set ESC (ASCII character 27) as a dispatch character:

To return to the PAD connection, enter the resume command:

Monitoring Protocol Translation Connections: Example

The following example shows how to log significant virtual terminal-asynchronous authentication information, such as the X.121 calling address, CUD, and IP address assigned to a virtual terminal-asynchronous connection, to a UNIX syslog server named alice:

Two-Step Protocol Translation for Virtual Terminal Asynchronous Interfaces: Example

Caution The following example shows how to configure the vty-async command for PPP over X.25 using the router named redmount:

---

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2011 Cisco Systems, Inc. All rights reserved.