-
Dial Solutions Configuration Guide
-
About The Cisco IOS Software Documentation
- Part 1: Business Applications and Scenarios
-
Part 2: Dial-In Port Set-Up
-
Overview of Lines, Interfaces, and Controllers
-
Configuring Modem Support and Asynchronous Devices
-
Managing Modems
-
Configuring Terminal Characteristics for Dial Sessions
-
Setting Up ISDN Basic Rate Service
-
Configuring Synchronous Serial Ports
-
Configuring Channelized E1 and Channelized T1
-
Configuring Special ISDN Signaling
-
-
Part 3: Dial-In Terminal Service and Remote Node Configuration
-
Configuring Dial-In Terminal Services
-
Configuring Protocol Translation and Virtual Async Devices
-
Configuring the Cisco PAD Facility for X.25 Connections
-
Configuring Media-Independent PPP and Multilink PPP
-
Configuring Asynchronous PPP and SLIP
-
Configuring V.120 Remote Node Access
-
Configuring AppleTalk Remote Access
-
- Part 4: Dial Authentication
- Part 5: Dial-on-Demand Routing
- Part 6: Dial Backup
- Part 7: Dial-Out Modem Pooling
- Part 8: Large-Scale Dial Solutions
- Part 9: Cost-Control Solutions
- Part 10: Virtual Private Dialup Networks
- Part 11: Other Network Traffic on ISDN Channels
- Part 12: Dial-Related Addressing Services
-
Table Of Contents
Configuring Protocol Translation and Virtual Asynchronous Devices
Cisco's Implementation of Protocol Translation
Definition of Protocol Translation
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
Set Up Virtual Templates for Protocol Translation
Configure Protocol Translation
Configure One-Step Protocol Translation
Configure a Virtual Template for One-Step Protocol Translation
Configure Two-Step Protocol Translation
Configure a Virtual Template for Two-Step Protocol Translation
Change the Number of Supported Translation Sessions
Configure Tunneling of SLIP, PPP, or ARA
Configure One-Step Tunneling of SLIP or PPP
Configure One-Step Tunneling of ARA
Configure Two-Step Tunneling of SLIP or PPP
Enable Dynamic Address Assignment for Outgoing PPP and SLIP on VTY Lines
Assign IP Addresses Using DHCP
Assign IP Addresses Using Local IP Address Pooling
Apply an Access List to a Virtual Line
Increase or Decrease the Number of Virtual Terminal Lines
Enable Asynchronous Functions on VTY Lines
Create Virtual Asynchronous Interfaces
Enable Protocol Translation of PPP and SLIP on Virtual Asynchronous Interfaces
Enable IPX-PPP over X.25 to an IPX Network on VTY Lines
Enable Dynamic Routing on Virtual Asynchronous Interfaces
Enable TCP/IP Header Compression on Virtual Asynchronous Interfaces
Enable Keepalive Updates on Virtual Asynchronous Interfaces
Set an MTU on Virtual Asynchronous Interfaces
Enable PPP Authentication on Virtual Asynchronous Interfaces
Enable PPP Authentication via TACACS on Virtual Asynchronous Interfaces
Monitor and Maintain Virtual Interfaces
Monitor and Maintain a Virtual Access Interface
Display a Virtual Asynchronous Interface
Monitor Protocol Translation Connections
Log VTY-Async Authentication Information to the Console Terminal
Log VTY-Async Authentication Information to a Buffer
Log VTY-Async Authentication Information to a UNIX Syslog Server
Virtual Template for Protocol Translation Examples
Tunneling PPP across X.25 Example
Tunneling SLIP across X.25 Example
Tunneling PPP across X.25, and Specifying CHAP and Access List Security Example
Tunneling PPP with Header Compression On Example
Tunneling IPX-PPP across X.25 Example
Two-Step Tunneling of PPP with Dynamic Routing and Header Compression Example
Two-Step Tunneling of PPP with Dynamic Routing, TACACS, and CHAP Example
Protocol Translation Application Examples
Assign Addresses Dynamically for PPP Example
Central Site Protocol Translation Example
Decreasing the Number of Translation Sessions Example
Increasing the Number of Translation Sessions Example
LAT-to-LAT over an IP WAN Example
LAT-to-LAT over Frame Relay or SMDS Example
LAT-to-LAT Translation over a WAN Example
LAT-to-LAT over an X.25 Translation Example
LAT-to-TCP Translation over a WAN Example
Configuration for Access Server A
LAT-to-TCP over an X.25 Example
Local LAT-to-TCP Translation Example
Configuration for the Access Server
Standalone LAT-to-TCP Translation Example
Tunneling SLIP inside TCP Example
Tunneling PPP over X.25 Example
Protocol Translation Session Examples
Using the One-Step Method for TCP-to-X.25 Host Connections Example
Using Two-Step Protocol Translation for TCP-to-PAD Connections Examples
Changing Parameters and Settings Dynamically Example
Monitoring Protocol Translation Connections Example
Configuring Protocol Translation and Virtual Asynchronous Devices
This chapter describes how to configure protocol translation and virtual asynchronous connections using Cisco IOS software. 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, LAT, TN3270, ARA, PPP, SLIP, and XRemote.
For a complete description of the commands in this chapter, refer to the "Protocol Translation and Virtual Asynchronous Device Commands" chapter of the Dial Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
Note
Telnet is a remote terminal protocol that is part of the Transmission Control Protocol/Internet Protocol (TCP/IP) suite. The descriptions and examples in the following sections use the term TCP as a reference to Telnet functionality.
The following sections describe the process of tunneling and protocol translation, as well as the two-step and the one-step translation methods:
•
•
•
•
•
•
•
•
•
•
•
•
The X.3 packet assembler/disassembler (PAD) parameters are described in the "X.3 PAD Parameters" appendix in the Dial Solutions Command Reference.
Cisco's Implementation of Protocol Translation
This section describes the additional tasks required to perform protocol translation from one host to another host or to a router. Specifically, it contains 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, shows a remote PC dialing through an IP network and connecting an X.25 host. The PC's TCP packets 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 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, the protocol translation facility is used to enable tunneling of SLIP, PPP, or ARA.
shows a typical tunneling scenario.
Figure 2 Tunneling X.25 with PPP across an IP Network
You can also tunnel IPX PPP over X.25, TCP, or LAT to an IPX network when tunneling PPP on virtual terminal (VTY) lines.
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 is called one-step translation, which is the most popular translation 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 protocols listed below. Connecting between these protocols requires that you first connect to a router, then to the host to which you want to connect. This is called two-step translation, which is the least popular translation method.
•
•
One-Step Protocol Translation
Use the one-step method when network users repeatedly log on 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 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:
•
•
•
Refer to the section "Configure Protocol Translation" 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 PDN and TCP/IP). As with the one-step method, Cisco recommends 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.
Refer to the section "Configure Protocol Translation" in this chapter for configuration tasks.
Tunnel 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 (VTY) lines.
Refer to the section "Configure Tunneling of SLIP, PPP, or ARA" 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 do not need to 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 "Configure 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 VTY lines. Normally, PPP and SLIP function only on physical asynchronous interfaces. The vty-async command enables you to run PPP and SLIP on VTY 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 VTY lines and then configure automatic protocol startup. When a user connects to the VTY line and receives an EXEC prompt, ARA starts up automatically on the outgoing VTY line.
Set 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 later section "Configure Protocol Translation"). When a user dials in through a virtual terminal (VTY) 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 VTY 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
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 3 PPP Tunnel Session across an X.25 Network
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 4 PPP Tunnel Session across a TCP or LAT WAN
The virtual interface template service for protocol translation provides the following benefits:
•
•
•
Configure Protocol Translation
To configure protocol translation, perform the tasks in the following sections:
•
•
•
•
Configure One-Step Protocol Translation
To create one-step protocol translation connection specifications, perform the following task in global configuration mode:
translate protocol incoming-address [in-options] protocol
outgoing-address [out-options] [global-options]Create 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 scrip 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]Configure 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.
Note
To enable tunneling of PPP or SLIP across an X.25, TCP, or LAT WAN by using one-step protocol translation, complete the following tasks beginning in global configuration mode:
1
interface virtual-template number
Create a virtual interface template, and enter interface configuration mode.
2
ip unnumbered ethernet 01
Assign an IP address to the virtual interface template.
3
encapsulation {ppp | slip}2
Enable encapsulation on the virtual interface template.
4
peer default ip address {dhcp | pool [pool-name]}
Assign a default peer to the device connecting to the virtual access interface (such as the PC in ).
5
exit
Exit back to global configuration mode.
6
translate {lat | tcp | x25} incoming-address [in-options] virtual-template number [global-options]
Assign 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 specifying 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. The following table maps outgoing translate command options to interface commands you can configure in the virtual interface template.
Configure Two-Step Protocol Translation
To translate using the two-step method, perform the following Purpose 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). PPP and SLIP are supported on outgoing connections only.
Configure 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, complete the following Purposes beginning in global configuration mode:
1
interface virtual-template number
Create a virtual interface template, and enter interface configuration mode.
2
ip unnumbered ethernet 01
Assign an IP address to the virtual interface template.
3
encapsulation {ppp | slip}2
Enable encapsulation on the virtual interface template.
4
peer default ip address {ip-address | dhcp | pool [pool-name]}
Assign an IP address to the device connecting to the virtual access interface (such as the PC in ).
5
exit
Exit back to global configuration mode.
6
vty-async
Create a virtual asynchronous interface.
7
vty-async virtual-template number
Apply 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.
Change the Number of Supported Translation Sessions
Because each protocol translation session uses a virtual terminal (VTY) line, you need to increase the number of VTY lines to increase the number of protocol translation sessions. That is, if your router has ten VTY lines, you can have up to ten protocol translation sessions. The default number of VTY lines is 5 (lines 0 through 4). To increase the number of lines, and thus the maximum number of protocol translation sessions, perform the following tasks, 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.
Configure Tunneling of SLIP, PPP, or ARA
This section describes how to perform the following tasks:
•
•
•
•
You can also enable IPX over tunneled PPP sessions.
Configure One-Step Tunneling of SLIP or PPP
To tunnel SLIP or PPP using the one-step protocol translation facility, perform the following task 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 "Create 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 Example."
You can configure an outgoing session for IPX-PPP. To do so, issue 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 do not need to 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 VTY line at a time.
PPP and SLIP, including IPX-PPP, can be tunnelled on outgoing connections only.
Configure One-Step Tunneling of ARA
To tunnel ARA using the one-step protocol translation facility, perform the following tasks, beginning in global configuration mode. The first four steps are required. The next seven steps (5 through 11) are optional:
Configure Two-Step Tunneling of SLIP or PPP
To tunnel SLIP or PPP using the two-step protocol translation facility perform the following tasks, beginning in global configuration mode:
If you want to configure IPX over your PPP sessions on VTY lines, refer to the chapter "Configuring Asynchronous PPP and SLIP" in this publication.
Enable Dynamic Address Assignment for Outgoing PPP and SLIP on VTY 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 VTY lines.
Assign IP Addresses Using DHCP
The Dynamic Host Control Protocol (DHCP) client-proxy feature manages a pool of IP addresses available to PPP or SLIP dial-in clients without a known IP address. This 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 auto-dialed 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 Configuration Fundamentals Configuration Guide.
To assign IP addresses using DHCP, perform the following tasks 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.
Assign IP Addresses Using Local IP Address Pooling
You can make temporary IP addresses available for outgoing PPP and SLIP clients on outgoing sessions. To do so, 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, perform the following task 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.
Create 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 following tasks:
1
2
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 task 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.
Apply an Access List to a Virtual Line
To apply an access list to a virtual line, perform the following tasks in line configuration mode:
access-class number in
Restrict 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
Create 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, perform the following global configuration task:
x29 profile {default | name} parameter:value [parameter:value]
Create 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 Dial Solutions Command Reference.
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 "PAD and X.25 Connection Setup Commands" chapter of the Dial Solutions Command Reference.
Define X.25 Host Names
This section describes how to define symbolic host names. This 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, perform the following task in global configuration mode:
Increase or Decrease the Number of Virtual Terminal Lines
Because each protocol translation session uses a virtual terminal (VTY) line, you need to increase the number of VTY lines to increase the number of protocol translation sessions. That is, if your router has ten VTY lines, you can have up to ten protocol translation sessions. The default number of VTY lines is 5 (lines 0 through 4). To increase the number of lines, and thus the maximum number of protocol translation sessions, perform the following tasks, 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.
The maximum number of protocol translation sessions for each platform can be increased to the number specified in Table 18. One VTY line is required for each protocol translation session.
Cisco 1000 running Cisco IOS software
5
6
5
Cisco 2500 series
(8 asynchronous ports)5
200
190
Cisco 2500 series
(16 asynchronous ports)5
200
182
Cisco 3000 series
5
200
198
Cisco 3640
5
1002
872
Cisco 3620
5
1002
936
Cisco 4000 series
5
200
198
Cisco 4500 series
5
1002
1000
Cisco 4700 series
5
1002
1000
Cisco AS5200
5
200
182
Cisco 7000 series
5
120
118
Cisco 7200 series
5
1002
1000
Cisco 7000 series
with RSP5
1002
1000
1 Maximum number of VTYs + (TTYs + AUX + CON lines).
Enable Asynchronous Functions on VTY Lines
Using Cisco IOS software, you can configure asynchronous protocol features, such as PPP and SLIP, on VTY lines. PPP and SLIP normally function only on asynchronous interfaces, not on VTY lines. When you configure a VTY line to support asynchronous protocol features, you are creating virtual asynchronous interfaces on the VTY lines. One practical benefit of virtual asynchronous interfaces is the ability to tunnel PPP and SLIP across X.25, TCP, or LAT networks on VTY lines. You tunnel PPP and SLIP using the protocol translation facility.
Perform the tasks in the following sections to configure and use virtual asynchronous interfaces. The first task is required; the remaining tasks are optional.
•
•
•
•
•
•
•
•
Note
Create Virtual Asynchronous Interfaces
To create a virtual asynchronous interface, perform the following task in global configuration mode:
vty-async
Configure all virtual terminal lines to support asynchronous protocol features.
Enable Protocol Translation of PPP and SLIP on Virtual Asynchronous Interfaces
One practical benefit of enabling virtual asynchronous interfaces is the ability to tunnel PPP and SLIP over X.25, thus extending remote node capability into the X.25 area. You can also tunnel PPP and SLIP over Telnet or LAT on virtual terminal lines. You can tunnel PPP and SLIP over X.25, LAT, or Telnet, but you do so by using the protocol translation feature in the Cisco IOS software.
To tunnel incoming dial-up SLIP or PPP connections over X.25, LAT, or TCP to an IP network, you can use one-step protocol translation or two-step protocol translation, as follows:
•
•
Enable IPX-PPP over X.25 to an IPX Network on VTY Lines
You can enable IPX-PPP on VTYs, which permits clients to log in to a VTY on a router, invoke a PPP session at the EXEC prompt to a host, and run IPX to the host.
For example, in , the client Terminal on the X.25 network logs into the VTY line on the access server, which is configured for IPX-PPP. When the user connects to the access server and the EXEC prompt appears, the user issues the PPP command to connect to the IPX host. The VTY is configured to run IPX, so when the PPP session is established from the access server, the terminal can access the IPX host using an IPX application.
Figure 5 IPX-PPP on a Virtual Asynchronous Interface
To enable IPX to run over your PPP sessions on VTY lines, perform the following tasks, beginning in global configuration mode:
1
ipx routing [node]
Enable IPX routing.
2
interface loopback number
Create a loopback interface.
3
ipx network network1
Enable a virtual IPX network on the loopback interface.
4
vty-async ipx ppp-client loopback number
Enable IPX-PPP on VTY lines by assigning the VTY to the loopback interface configured for IPX.
1 Every loopback interface must have a unique IPX network number.
Enable Dynamic Routing on Virtual Asynchronous Interfaces
To route IP packets using the IGRP, RIP, and OSPF routing protocols on virtual asynchronous interfaces, perform the following task in global configuration mode:
vty-async dynamic-routing
Enable dynamic routing of IP packets on all virtual terminal lines.
When you make a connection, you must specify the routing keyword on the SLIP or PPP command line.
Note
Enable TCP/IP Header Compression on Virtual Asynchronous Interfaces
You can compress the headers on TCP/IP packets on virtual asynchronous interfaces to reduce their size and increase performance. This feature only compresses the TCP header, so it has no effect on UDP packets or other protocol headers. The TCP header compression technique, described fully in RFC 1144, is supported on virtual asynchronous interfaces using PPP and SLIP encapsulation. You must enable compression on both ends of the connection.
You can optionally specify outgoing packets to be compressed only if TCP incoming packets on the same virtual terminal line are compressed. If you do not specify this option, the Cisco IOS software will compress all traffic. The default is no compression. This option is valid for SLIP.
To compress the headers of outgoing TCP packets on virtual asynchronous interfaces, perform the following task in global configuration mode:
vty-async header-compression [passive]
Enable header compression on IP packets on all virtual terminal lines.
Enable Keepalive Updates on Virtual Asynchronous Interfaces
Keepalive updates are enabled on all virtual asynchronous interfaces by default. To change the keepalive timer or disable it on virtual asynchronous interfaces, perform the following task in global configuration mode:
vty-async keepalive [seconds]
Specify the frequency with which the Cisco IOS software sends keepalive messages to the other end of an asynchronous serial link.
The default interval is 10 seconds. It is adjustable in one-second increments from 0 to 32,767 seconds. To turn off keepalive updates, set the value to 0. A connection is declared down after three update intervals have passed without receiving a keepalive packet.
Virtual terminal lines have very low bandwidth. When adjusting the keepalive timer, large packets can delay the smaller keepalive packets long enough to cause the session to disconnect. You might need to experiment to determine the best value.
Set an MTU on Virtual Asynchronous Interfaces
The maximum transmission unit (MTU) refers to the size of an IP packet. You might want to change to a smaller MTU size for IP packets transmitted on a virtual asynchronous interface for any of the following reasons:
•
•
•
For example, at 9600 baud, a 1500-byte packet takes about 1.5 seconds to transmit. This delay would indicate that you want an MTU size of about 200 (1.5 seconds / 0.2 seconds = 7.5 and 1500-byte packet / 7.5 = 200-byte packet).
To specify the maximum IP packet size, perform the following task in interface configuration mode:
vty-async mtu bytes
Specify the size of the largest IP packet that the virtual asynchronous interface can support.
The default MTU size is 1500 bytes. Possible values are 64 bytes to 1,000,000 bytes.
The TCP protocol running on the remote device can have a different MTU size than the MTU size configured on your router. Because the Cisco IOS software performs IP fragmentation of packets larger than the specified MTU, do not change the MTU size unless the SLIP or PPP implementation running on the host at the other end of the asynchronous line supports reassembly of IP fragments.
Enable PPP Authentication on Virtual Asynchronous Interfaces
You can enable Challenge Handshake Authentication Protocol (CHAP) or Password Authenti
