- Cisco IOS Dial Services Configuration Guide: Terminal Services, Release 12.1
Table Of Contents
Configuring Protocol Translation and Virtual Asynchronous Devices
Definition of Protocol Translation
Deciding Whether to Use One-Step or Two-Step Protocol Translation
One-Step Tunneling of SLIP, PPP, and ARA
Two-Step Tunneling of PPP and SLIP
Setting Up Virtual Templates for Protocol Translation
Protocol Translation Configuration Task List
Configuring One-Step Protocol Translation
Configuring a Virtual Template for One-Step Protocol Translation
Configuring Two-Step Protocol Translation
Configuring a Virtual Template for Two-Step Protocol Translation
Changing the Number of Supported Translation Sessions
Configuring Tunneling of SLIP, PPP, or ARA
Configuring One-Step Tunneling of SLIP or PPP
Configuring One-Step Tunneling of ARA
Configuring Two-Step Tunneling of SLIP or PPP
Enabling Dynamic Address Assignment for Outgoing PPP and SLIP on Virtual Terminal Lines
Assigning IP Addresses Using DHCP
Assigning IP Addresses Using Local IP Address Pooling
Applying an Access List to a Virtual Line
Creating an X.29 Profile Script
Protocol Translation and Processing PAD Calls
Background Definitions and Terms
Accepting Incoming PAD Protocol Translation Calls
Processing Outgoing PAD Calls Initiated by Protocol Translation
Increasing or Decreasing the Number of Virtual Terminal Lines
Enabling Asynchronous Functions on Virtual Terminal Lines
Creating Virtual Asynchronous Interfaces
Enabling Protocol Translation of PPP and SLIP on Virtual Asynchronous Interfaces
Enabling IPX-PPP over X.25 to an IPX Network on Virtual Terminal Lines
Enabling Dynamic Routing on Virtual Asynchronous Interfaces
Enabling TCP/IP Header Compression on Virtual Asynchronous Interfaces
Enabling Keepalive Updates on Virtual Asynchronous Interfaces
Setting an MTU on Virtual Asynchronous Interfaces
Enabling PPP Authentication on Virtual Asynchronous Interfaces
Enabling PPP Authentication via TACACS on Virtual Asynchronous Interfaces
Maintaining Virtual Interfaces
Monitoring and Maintaining a Virtual Access Interface
Displaying a Virtual Asynchronous Interface
Troubleshooting Virtual Asynchronous Interfaces
Monitoring Protocol Translation Connections
Logging vty-Async Authentication Information to the Console Terminal
Logging vty-Async Authentication Information to a Buffer
Logging vty-Async Authentication Information to a UNIX Syslog Server
Troubleshooting Protocol Translation
Virtual Template for Protocol Translation Examples
Tunnel PPP Across X.25, and Specifying CHAP and Access List Security
Tunnel PPP with Header Compression On
Two-Step Tunneling of PPP with Dynamic Routing and Header Compression
Two-Step Tunneling of PPP with Dynamic Routing, TACACS, and CHAP
Protocol Translation Application Examples
Central Site Protocol Translation
Decreasing the Number of Translation Sessions
Increasing the Number of Translation Sessions
LAT-to-LAT over Frame Relay or SMDS
LAT-to-LAT Translation over a WAN
LAT-to-LAT over an X.25 Translation
LAT-to-TCP Translation over a WAN
LAT-to-X.25 Host Configuration
Local LAT-to-TCP Configuration
Standalone LAT-to-TCP Translation
Assigning Addresses Dynamically for PPP
Protocol Translation Session Examples
One-Step Method for TCP-to-X.25 Host Connections
Using the Two-Step Method for TCP-to-PAD Connections
Two-Step Protocol Translation for TCP-to-PAD Connections
Changing Parameters and Settings Dynamically
Monitoring Protocol Translation Connections
Two-Step Protocol Translation for Virtual Terminal Asynchronous Interfaces
Configuring Protocol Translation and Virtual Asynchronous Devices
This chapter describes how to configure protocol translation and virtual asynchronous connections using Cisco IOS software. These tasks are described in the following sections describing the process of tunneling and protocol translation, and the two-step and the one-step translation methods:
•
Protocol Translation Overview
•
•
•
•
•
•
•
•
•
•
•
•
•
The X.3 packet assembler/disassembler (PAD) parameters are described in the "X.3 PAD Parameters" appendix in the Cisco IOS Dial Services Command Reference publication.
The protocol translation facility assumes that you understand how to use the configuration software. Before using this chapter, you should be familiar with configuring the protocols for which you want to translate: X.25, Telnet, local-area transport (LAT), TN3270, AppleTalk Remote Access (ARA), Point-to-Point Protocol (PPP), Serial Line Internet Protocol (SLIP), and XRemote.
Note
For a complete description of the commands in this chapter, see the Cisco IOS Dial Services Command Reference publication. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
Protocol Translation Overview
This section describes the additional tasks required to perform protocol translation from one host to another host or to a router. It includes the following sections:
•
•
•
•
•
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 the targeted host.
Protocol translation is a resourceful facility for many business applications. For example, Figure 81 shows a remote personal computer (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 81 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 82 shows a typical tunneling scenario.
Figure 82 Tunneling X.25 with PPP Across an IP Network
You can also tunnel IPX-PPP over X.25, TCP, or LAT to an Internet Protocol Exchange (IPX) network when tunneling PPP on virtual terminal lines.
Deciding Whether to Use One-Step or Two-Step Protocol Translation
The Cisco IOS software supports virtual terminal connections in both directions between the protocols in the following list. You can configure the router to translate automatically between them. This translation method is called one-step translation, and is the more popular method.
•
•
•
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, then to the host to which you want to connect. This translation method is called two-step translation, and is the less popular 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 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 which host the connection is for and which protocol that 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 the 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:
•
•
•
See the section "Protocol Translation Configuration Task List" later in this chapter 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, We recommend that you configure virtual templates for this feature.
Note
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.
See the section "Protocol Translation Configuration Task List" later in this chapter for configuration tasks.
Tunneling SLIP, PPP, and ARA
Unlike other protocols, such as LAT, X.25, and TCP, which are actually 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 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. See the section "Configuring Tunneling of SLIP, PPP, or ARA" later in this chapter for configuration tasks.
One-Step Tunneling of SLIP, PPP, and ARA
To use one-step protocol translation to tunnel SLIP, PPP (or IPX-PPP), or ARA, you need not enter any preliminary commands. Simply use the translate command with the slip or ppp keywords for one-step SLIP or PPP connections or autocommand arap for one-step ARA connections. Because ARA does not use addressing, you must specify the autocommand keyword, then specify the string arap to tunnel ARA to an AppleTalk network.
If you are tunneling PPP, SLIP, or ARA across X.25, you must also set up your X.3 profile correctly using the x29 profile command, as described in the section "Configuring One-Step Tunneling of SLIP or PPP" later in this chapter.
Two-Step Tunneling of PPP and SLIP
To tunnel SLIP or PPP across an X.25 WAN to an IP network using the two-step protocol translation method, use the vty-async command, which enables you to run PPP and SLIP on virtual terminal lines. Normally, PPP and SLIP function only on physical asynchronous interfaces. The vty-async command enables you to run PPP and SLIP on virtual terminal lines, which permits you to tunnel from an incoming protocol to SLIP or PPP and then to an IP network (or IPX-PPP to an IPX network).
If you make a PAD connection to a router running protocol translation and then issue the ppp definitions command to connect across an X.25 network, you also must set up your X.3 profile using the pad [/profile name] command.
Two-Step Tunneling of ARA
To tunnel ARA using the two-step method, you configure ARA on one or more virtual terminal lines and then configure automatic protocol startup. When a user connects to the virtual terminal line and receives an EXEC prompt, ARA starts up automatically on the outgoing virtual terminal line.
Setting Up Virtual Templates for Protocol Translation
The Cisco IOS software simplifies the process of configuring protocol translation to tunnel PPP or SLIP across X.25, TCP, and LAT networks. It does so by providing virtual interface templates that you can configure independently and apply to any protocol translation session. You can configure virtual interface templates for one-step and two-step protocol translation.
A virtual interface template is an interface that exists just inside the router (it is not a physical interface). You can configure virtual interface templates just as you do regular asynchronous serial interfaces. You then apply these virtual interface templates for one-step and two-step protocol translation (the process is described in detail in the section "Protocol Translation Configuration Task List" in this chapter). When a user dials in through a virtual terminal line and a tunnel connection is established, the router clones the attributes of the virtual interface template onto a virtual access interface. This virtual access interface is a temporary interface that supports the asynchronous protocol configuration specified in the virtual interface template. This virtual access interface is created dynamically and lasts only as long as the tunnel session is active.
Before virtual templates were implemented, you enabled asynchronous protocol functions on virtual terminal lines by creating virtual asynchronous interfaces rather than virtual access interfaces. (For one-step translation, you did so by specifying ppp or slip as outgoing options in the translate command. For two-step translation, you did so by specifying the vty-async command.) The differences between virtual asynchronous interfaces and virtual access interfaces are as follows:
•
•
Virtual access interfaces replace virtual asynchronous interfaces for both one-step and two-step translation.
You can configure up to 25 virtual interface templates and have up to 300 virtual access interfaces per router (300 is the hardware limit on the router, based on the number of IDBs).
Note
Figure 83 shows a typical network diagram for a tunnel session from a PC across an X.25 network, through a router set up with a virtual interface template for protocol translation, and to a corporate intranet.
Figure 83 PPP Tunnel Session Across an X.25 Network
Figure 84 shows a typical network diagram for a tunnel session from a PC across a TCP or LAT WAN, through a router set up with a virtual interface template for protocol translation, and to a corporate intranet.
Figure 84 PPP Tunnel Session Across a TCP or LAT WAN
The virtual interface template service for protocol translation provides the following benefits:
•
•
•
Virtual Templates and L2F
L2F tunneling technology is used in virtual private dialup networks (VPDN). VPDN allows separate and autonomous protocol domains to share common access infrastructure including modems, access servers, and ISDN routers by the tunneling of link level frames.
L2F/VPDN over protocol translation virtual template interfaces allows services with multiple X.25 dial POPs to expand their current L2F services. This ability can be accomplished by terminating the PPP virtual-async connections over X.25 at the Cisco protocol translation/router and setting up the L2F tunnel to the home gateway. This allows protocol-level packets to pass through the virtual tunnel between endpoints of a point-to-point connection.
Typical L2F tunneling use includes Internet service providers (ISPs) or other access service creating virtual tunnels to link to the remote sites of a customer or remote users with corporate home networks. In particular, a network access server at the POP for the ISP exchanges PPP messages with the remote users, and communicates by L2F requests and responses with the home gateway of the customer to set up tunnels.
Frames from the remote users are accepted by the POP, stripped of any linked framing or transparency bytes, encapsulated in L2F, and forwarded over the appropriate tunnel. The home gateway of the customer accepts these L2F frames, strips the L2F encapsulation, and processes the incoming frames for the appropriate interface.
Note
For more information on VPDNs, see the chapters in the part "Virtual Private Networks" in the Cisco IOS Dial Services Configuration Guide: Network Services publication.
Protocol Translation Configuration Task List
To configure protocol translation, perform the tasks in the following sections, as required:
•
•
•
•
See the sections "Virtual Template for Protocol Translation Examples," "Protocol Translation Application Examples," and "Protocol Translation Session Examples" later in this chapter for examples of protocol translation sessions and configurations.
Configuring One-Step Protocol Translation
To create one-step protocol translation connection specifications, use the following command in global configuration mode:
translate protocol incoming-address
Creates the connection specifications for one-step protocol translation.
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 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.
x29 profile default parameter:value [parameter:value]
Note
Configuring a Virtual Template for One-Step Protocol Translation
To configure a virtual interface template to enable tunneling of PPP or SLIP across an X.25, TCP, or LAT WAN, first create and configure a virtual interface template, then apply it as the single outgoing option to the translate command.
Virtual interface templates in general support all commands available on any serial interface, because virtual templates are used for purposes other than protocol translation. However, a virtual access interface—which clones the configuration of the corresponding virtual interface template when created for protocol translation—supports only asynchronous protocol commands.
To enable tunneling of PPP or SLIP across an X.25, TCP, or LAT WAN by using one-step protocol translation, use the following commands beginning in global configuration mode:
Step 1
interface virtual-template number
Creates a virtual interface template, and enters interface configuration mode.
Step 2
ip unnumbered ethernet 01
Assigns an IP address to the virtual interface template.
Step 3
encapsulation {ppp | slip}2
Enables encapsulation on the virtual interface template.
Step 4
peer default ip address {ip-address | dhcp | pool [pool-name-list]}
Assigns an IP address from a pool to the device connecting to the virtual access interface (such as the PC in Figure 83).
Step 5
exit
Exits to global configuration mode.
Step 6
translate {lat | tcp | x25} incoming-address [in-options] virtual-template number [global-options]
Assigns the virtual interface template to a protocol translation session.
.1 You can also assign a specific IP address by using the ip address address command, though assigning the IP address of the Ethernet 0 interface as shown is most common.
.2 Virtual interface templates use PPP encapsulation by default, so you need not specify encapsulation ppp. However, to use SLIP encapsulation, you must explicitly specify encapsulation slip.
Rather than specify outgoing translation options in the translate command, configure these options as interface configuration commands under the virtual interface template, then apply the virtual interface template to the translate command. Table 23 maps outgoing translate command options to interface commands you can configure in the virtual interface template.
Configuring Two-Step Protocol Translation
To translate using the two-step method, use the following commands beginning in global configuration mode. The first step is required only if you are tunneling SLIP or PPP using the two-step protocol translation facility:
The Cisco IOS software supports the two-step method in both directions for protocols other than PPP and SLIP (for example, from Telnet to PAD, and vice versa).
Note
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 still use the vty-async command, just as before implementation of virtual templates. However, virtual asynchronous interfaces are not created as they were before virtual interface templates. Virtual access 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 beginning in global configuration mode:
Step 1
interface virtual-template number
Creates a virtual interface template, and enters interface configuration mode.
Step 2
ip unnumbered ethernet 01
Assigns an IP address to the virtual interface template.
Step 3
encapsulation {ppp | slip}2
Enables encapsulation on the virtual interface template.
Step 4
peer default ip address {dhcp | pool [pool-name-list]}
Assigns an IP address from a pool to the device connecting to the virtual access interface (such as the PC in Figure 83).
Step 5
exit
Exits to global configuration mode.
Step 6
vty-async
Creates a virtual asynchronous interface.
Step 7
vty-async virtual-template number
Applies the virtual template to the virtual asynchronous interface.
.1 You can also assign a specific IP address by using the ip address address command, though assigning the IP address of the Ethernet0 interface as shown is most common.
.2 Virtual interface templates use PPP encapsulation by default, so you need not specify encapsulation ppp. However, to use SLIP encapsulation, you must explicitly specify encapsulation slip.
Other asynchronous configuration commands can be added to the virtual template configuration. We recommend that you include security on your virtual interface template. For example, you can enter the ppp authentication chap command.
Changing the Number of Supported Translation Sessions
There is a one-to-one relationship between protocol translation sessions and virtual terminal lines. For every session, you need a virtual terminal line. Therefore, if you need to increase the number of protocol translation sessions, you need to increase the number of virtual terminal lines. That is, if your router has ten virtual terminal lines, you can have up to ten protocol translation sessions. The default number of virtual terminal lines is 5 (lines 0 through 4). To increase the number of lines, and thus the maximum number of protocol translation sessions, use the following commands, as appropriate, beginning in global configuration mode:
Protocol translation is a CPU-intensive task. Increasing the number of protocol translation sessions while routing is enabled can impact available memory. The amount of memory available depends on the platform type, the amount of DRAM available, the activity of each translation session, and the speed of the link. If you are using the maximum number of sessions and have problems with memory, you might need to decrease the number of protocol translation sessions.
Configuring Tunneling of SLIP, PPP, or ARA
This section describes how to use perform the tasks in the following sections:
•
•
•
•
You can also enable IPX over tunneled PPP sessions.
Configuring One-Step Tunneling of SLIP or PPP
To tunnel SLIP or PPP using the one-step protocol translation facility, use the following commands in global configuration mode:
If you are configuring PPP over X.25 and do not know which X.3 profile parameters to use, try the following (these parameters do not function in all cases; they are simply a place from which to start):
1:0, 2:0, 3:2, 4:1, 5:0, 6:0, 7:21, 8:0, 9:0, 10:0, 11:14, 12:0, 13:0, 14:0, 15:0, 16:127, 17:24, 18:18, 19:0, 20:0, 21:0, 22:0
For more information about creating an X.29 profile script, see the section "Creating an X.29 Profile Script" later in this chapter. For an example of configuring PPP over X.25, refer to the section "Tunneling PPP over X.25" at the end of this chapter.
To configure an outgoing session for IPX-PPP, use the ipx loopback number option for the outgoing session.
To tunnel SLIP or PPP across X.25, LAT, or Telnet using the one-step method, you need not enter any additional commands, as you do when you tunnel SLIP or PPP using the two-step method. The translate command enables asynchronous protocol features on one virtual terminal line at a time.
PPP and SLIP, including IPX-PPP, can be tunnelled on outgoing connections only.
Configuring One-Step Tunneling of ARA
To tunnel ARA using the one-step protocol translation facility, use the following commands beginning in global configuration mode. The first four steps are required; steps 5 through 11 are optional:
Configuring Two-Step Tunneling of SLIP or PPP
To tunnel SLIP or PPP using the two-step protocol translation facility, use the following commands beginning in global configuration mode:
If you want to configure IPX over your PPP sessions on virtual terminal lines, see the chapter "Configuring Asynchronous PPP and SLIP" in this publication.
Enabling Dynamic Address Assignment for Outgoing PPP and SLIP on Virtual Terminal Lines
You can specify IP addresses dynamically from a Dynamic Host Configuration Protocol (DHCP) proxy client or a local IP address pool on outgoing PPP and SLIP sessions on virtual terminal lines.
Assigning IP Addresses Using DHCP
The DHCP client-proxy feature manages a pool of IP addresses available to PPP or SLIP dial-in clients who need not know an IP address to be able to access a system. This feature allows a finite number of IP addresses to be reused quickly and efficiently by many clients. Additional benefits include the ability to maintain sessions, such as Telnet, even when a modem line fails. When the client is autodialed back into the access server or router, the session can be resumed because the same IP address is reissued to the client by the access server or router.
A DHCP proxy client is a Cisco access server or router configured to arbitrate DHCP calls between a DHCP server and a DHCP client. For more information about DHCP proxy clients, refer to the Cisco IOS IP and IP Routing Configuration Guide.
To assign IP addresses using DHCP, use the following commands in global configuration mode:
The name argument is the name of the DHCP proxy client specified with the ip address-pool dhcp-proxy-client command.
Assigning IP Addresses Using Local IP Address Pooling
To make temporary IP addresses available for outgoing PPP and SLIP clients on outgoing sessions, you must first specify that the Cisco IOS software use a local IP address pool on all asynchronous interfaces and create one or more local IP address pools. You then assign local pooling as part of the translate command. To assign IP addresses dynamically on a virtual asynchronous connection, use the following commands beginning in global configuration mode:
The scope-name option takes the name of any local IP address pool that has been defined using the ip local pool command.
Creating 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 these tasks:
•
•
These tasks are described in the following sections.
Note
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:
access-class number in
Restricts incoming and outgoing connections between a particular virtual terminal line (into a router) and the addresses in an access list.
The access list number is used for incoming TCP access and incoming PAD access. 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 have access restrictions on only one of the protocols, you can create an access list that permits all addresses for the other protocol.
Note
Creating an X.29 Profile Script
You can create an X.29 profile script for the translate command to use. An X.29 profile script uses X.3 PAD parameters. When an X.25 connection is established, the Cisco IOS software configured for protocol translation functions similar to an X.29 SET PARAMETER packet, which contains the parameters and values set by this command.
To create an X.29 profile script, use the following command in global configuration mode:
x29 profile {default | name} parameter:value [parameter:value]
Creates an X.29 profile script.
For incoming PAD connections, the router running protocol translation 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 the router uses, you must create a PAD profile script named default by using the x29 profile {default | name} parameter:value [parameter:value] global configuration command, where 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. For more information about X.3 PAD parameters, refer to the appendix "X.3 PAD Parameters" in the Cisco IOS Dial Services Command Reference publication.
Note
You can also create an X.29 profile script when connecting to a PAD using the pad [/profile name] EXEC command, which is described in the Cisco IOS Dial Services Command Reference publication.
Defining X.25 Host Names
This section describes how to define symbolic host names, which means that instead of remembering a long numeric address for an X.25 host, you can refer to the X.25 host using a symbolic host name. To define a symbolic host name, use the following command in global configuration mode:
Protocol Translation and Processing PAD Calls
This section explains how Cisco routers initiate and accept PAD calls using protocol translation.
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 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 are 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 subcommand 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 subcommands normally are used to configure PAD and protocol translation access. They are also used to override the configuration of the interface on a per-destination basis.
The following example configures an X.25 interface to restrict incoming PAD access to a single mapped host. This example requires that both incoming and outgoing PAD access use the Network User Identification (NUID) to authenticate the user:
interface serial 0x25 pad-accessx25 map pad 219104 nuid johndoe secretAccepting a PAD Call
An incoming PAD call is accepted by a Cisco router if the destination address matches the following:
•
•
•
•
•
•
Address/subaddress matches the address for the router set by the x25 host command.
Accepting Incoming PAD Protocol Translation Calls
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 X121 address and CUD field that pattern matches the incoming x121 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 X121 and 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:
translate x25 417262510195 tcp 170.51.186.54An incoming call to destination 417262510195 with an unknown PID 1234 and user data zayna will match the following translation entry:
translate x25 417262510195 cud 1234zayna tcp 170.51.186.54An incoming call to destination 417262510195 with a standard PAD PID 0x01000000 and user data zayna will match the following translation entry:
translate x25 417262510195 cud zayna tcp 170.51.186.54
Note
pad <x121 address> /cud \307\021
or
translate x25 <x121 address> cud \307\021 tcp <ip address>In the following example, the regular expression CUD field allows an incoming call to destination 31200100994301 with a standard PAD PID 0x01000000 and User Data 0xD0<whatever> to match the following translation entry:
translate X25 31200100994301 cud \320.* tcp 162.120.169.11 port 13301
Note
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 the facilities, are applied on the outgoing call. Otherwise, the PAD call is refused.
Note
For example, entering the use-map option on the pad EXEC command returns the following:
interface serial 1encapsulation x25x25 address 2192222x25 win 7x25 wout 7x25 ips 256x25 ops 256x25 map pad 77630 packetsize 1024 1024 windowsize 2 2 reverseThe 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:
pad 77630 /use-mapThe 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 user data in hexadecimal format:
! On the interface the call goes out on:interface Serial1x25 map pad 417262510197 pid 0x01000000<hex for your user data>!translate tcp 172.21.186.54 x25 417262510197 use-mapThe 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:
! On the interface the call goes out on:interface Serial1x25 map pad 417262510198 pid 0x0E cud hello!translate tcp 172.21.186.54 x25 417262510198 use-mapApplying 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.
Increasing or Decreasing the Number of Virtual Terminal Lines
Because each protocol translation session uses a virtual terminal line, you need to increase the number of virtual terminal lines to increase the number of protocol translation sessions. That is, if your router has ten virtual terminal lines, you can have up to ten protocol translation sessions. The default number of virtual terminal lines is 5 (lines 0 through 4). To increase the number of lines, and thus the maximum number of protocol translation sessions, use the following commands beginning in global configuration mode, as appropriate:
Note
The maximum number of protocol translation sessions for each platform can be increased to the number specified in Table 24. One virtual terminal is required for each protocol translation session.
Table 24 Maximum Number of Protocol Translation Sessions by Platform
Cisco 1000 running
Cisco IOS software
