|
|
Cisco IOS software Release 11.2 F enables you to simplify 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 "Configuration Tasks"). 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.
For more information about virtual asynchronous interfaces, refer to the following sections in the Cisco IOS Release 11.2 Access Services Configuration Guide:
This chapter describes how to configure virtual templates for protocol translation only. For more information about virtual interface templates in general, including additional applications of virtual templates, limitations, and a list of terms, refer to the chapter "Virtual Interface Template Service" in this feature guide.
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).
Figure 26 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 27 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.
The virtual interface template service for protocol translation provides the following benefits:
Most new and uncommon terms for virtual templates are described in the feature chapter "Virtual Interface Template Service." However, the following term is not described in that feature chapter, but is used in relation to virtual interface templates for protocol translation:
virtual asynchronous interface--A VTY line configured as an asynchronous interface by using the vty-async command. Can be used for two-step protocol translation.
This feature is supported on all platforms that support protocol translation, including the following:
To configure virtual interface templates for protocol translation, ensure that your software image supports protocol translation. For more information about features supported in software images, refer to the Release Notes for Cisco IOS Release 11.2 F. You must also understand the concepts of both one-step and two-step protocol translation. For more information, refer to the "Configuring Protocol Translation" chapter of the Cisco IOS Release 11.2 Access Services Configuration Guide.
This section describes how to configure a virtual template to tunnel PPP or SLIP across an X.25, TCP, or LAT wide-area network (WAN) using both one-step and two-step protocol translation. This section describes the following tasks:
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. The process of configuring incoming and global protocol translation options remains the same as that described in the Cisco IOS Release 11.2 Access Services Configuration Guide.
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:
| Task | Command |
|---|---|
| Step 1 Create a virtual interface template, and enter interface configuration mode. | interface virtual-template number |
| Step 2 Assign an IP address to the virtual interface template. | ip unnumbered ethernet 01 |
| Step 3 Enable encapsulation on the virtual interface template. | encapsulation {ppp | slip}2 |
| Step 4 Assign an IP address to the device connecting to the virtual access interface (such as the PC in Figure 26). | peer default ip address {ip-address | dhcp | pool [pool-name]} |
| Step 5 Exit back to global configuration mode. | exit |
| Step 6 Assign the virtual interface template to a protocol translation session. | translate {lat | tcp | x25} incoming-address [in-options] virtual-template number [global-options] |
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. Table 21 maps outgoing translate command options to interface commands you can configure in the virtual interface template.
| Translate Command Options | Corresponding Interface Configuration Command |
|---|---|
| ip-pool | peer default ip address {ip-address | dhcp | pool [poolname]} |
| header-compression | ip tcp header compression [on | off | passive] |
| routing | ip routing or ipx routing |
| mtu | mtu |
| keepalive | keepalive |
| authentication {chap | pap} | ppp authentication {chap | pap} |
| ppp use-tacacs | ppp use-tacacs |
| ipx loopback | ipx ppp-client loopback number |
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; it cannot be created directly. However, a virtual access interface can be cleared and displayed.
To display or clear a specific virtual access interface, perform the relevant task:
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 tasks beginning in global configuration mode:
| Task | Command |
|---|---|
| Step 1 Create a virtual interface template, and enter interface configuration mode. | interface virtual-template number |
| Step 2 Assign an IP address to the virtual interface template. | ip unnumbered ethernet 01 |
| Step 3 Enable encapsulation on the virtual interface template. | encapsulation {ppp | slip}2 |
| Step 4 Assign an IP address to the device connecting to the virtual access interface (such as the PC in Figure 26). | peer default ip address {ip-address | dhcp | pool [pool-name]} |
| Step 5 Exit back to global configuration mode. | exit |
| Step 6 Create a virtual asynchronous interface. | vty-async |
| Step 7 Apply the virtual template to the virtual asynchronous interface. | vty-async virtual-template number |
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.
When the configuration of a virtual interface template is cloned to a VTY line configured as a virtual access interface for two-step protocol translation, you can view information about the VTY line by performing the following task:
This section shows examples of configuring tunneling of PPP and SLIP using one-step and two-step protocol translation.
The following examples show how to configure a virtual template and apply them in one-step protocol translation sessions.
In the following example, the virtual interface template specifies a peer IP address of 172.16.2.131, which is the IP address of the PC in Figure 28. 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 28.
interface virtual-template 1 ip unnumbered Ethernet0 ! static address of 172.18.2.131 for the PC dialing in to the corporate intranet peer default ip address 172.16.2.131 encapsulation ppp ! ! X.121 address of 5555678 is the number the PAD dials to connect through the router translate x25 5555678 virtual-template 1
The template in this example uses SLIP encapsulation, instead of the PPP encapsulation.
interface Virtual-Template5 ip unnumbered Ethernet0 encapsulation slip peer default ip address 172.22.2.130 ! translate x25 5555000 virtual-template 5
The template in this example uses PPP encapsulation, although it is not explicitly specified. It also uses challenge handshake authentication protocol (CHAP) authentication and an X.29 access list.
x29 access-list 1 permit ^5555 ! interface Virtual-Template1 ip unnumbered Ethernet0 peer default ip address 172.16.2.129 ppp authentication chap ! translate x25 5555667 virtual-template 1 access-class 1
The following example uses TCP header compression when tunneling PPP across X.25.
interface Virtual-Template1 ip unnumbered Ethernet0 ip tcp header-compression passive peer default ip address 172.16.2.128 ! translate x25 5555676 virtual-template 1
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, then assigns that loopback interface to the virtual interface template.
ipx routing 0000.0c07.b509 ! interface loopback0 ipx network 544 ipx sap-interval 2000 ! interface Virtual-Template1 ip unnumbered Ethernet0 ipx ppp-client Loopback0 peer default ip address 172.16.2.127 ! translate x25 5555766 virtual-template 1
The following examples show how to create and configure virtual interface templates and apply them in two-step protocol translation sessions.
The template in the following example uses the default encapsulation of PPP. It does not specify a peer default IP address because it is using two-step translation.
vty-async vty-async virtual-template 1 vty-async dynamic-routing vty-async header-compression ! interface Virtual-Template1 ip unnumbered Ethernet0 no peer default ip address
After the user connects to the router (in this example, named waffler), they invoke the ppp command to complete the two-step connection:
waffler> ppp /routing /compressed 172.16.2.31
Entering PPP routing mode.
Async interface address is unnumbered (Ethernet0)
Your IP address is 172.16.2.31. MTU is 1500 bytes
The template in the following example uses the default encapsulation of PPP, and applies CHAP authentication with TACACS+.
aaa authentication ppp default tacacs+ ! vty-async vty-async dynamic-routing vty-async virtual-template 1 ! interface Ethernet0 ip address 10.11.12.2 255.255.255.0 ! interface Virtual-Template1 ip unnumbered Ethernet0 no peer default ip address ppp authentication chap
The following new command enables you to view statistics about the virtual access interface you identified with the show users command:
The following command, which has not changed since Cisco IOS Release 11.2, shows how to identify a virtual access interface (dynamically created on a VTY line) in contrast with other lines on a router:
The following commands have been modified to support virtual templates for protocol translation for one-step translation:
The following command has been modified to support virtual templates for protocol translation for two-step translation:
All other commands that enable virtual interface templates were introduced in Cisco IOS Release 11.2.
Use the show interfaces virtual-access EXEC command to display information about virtual access interfaces.
| number | Number of the virtual terminal (VTY) line on which the virtual access interface has been created. |
EXEC
This command first appeared in Cisco IOS Release 11.2 F.
To identify the number of the VTY line on which the virtual access interface was created, issue the show users EXEC command included in this feature chapter.
The following is sample output from the show interfaces virtual-access command:
scruples# show interface virtual-access 2
Virtual-Access2 is up, line protocol is up
Hardware is Virtual Access interface
Interface is unnumbered. Using address of Ethernet0 (10.0.21.14)
MTU 1500 bytes, BW 9 Kbit, DLY 100000 usec, rely 255/255, load 1/255
Encapsulation PPP, loopback not set, keepalive not set
DTR is pulsed for 0 seconds on reset
LCP Open
Open: IPCP
Last input 00:00:06, output 00:00:05, output hang never
Last clearing of "show interface" counters 00:14:58
Input queue: 1/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/64/0 (size/threshold/drops)
Conversations 0/1 (active/max active)
Reserved Conversations 0/0 (allocated/max allocated)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
4 packets input, 76 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
8 packets output, 330 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
scruples#
Table 22 describes the fields shown in this sample display.
| Field | Description |
|---|---|
| Virtual-Access ... is {up | down | administratively down} | Indicates whether the interface is currently active (whether carrier detect is present), inactive, or has been taken down by an administrator. |
| line protocol is {up | down | administratively down} | Indicates whether the software processes that handle the line protocol think the line is usable (that is, whether keepalives are successful). |
| Hardware is Virtual Access interface | The type of interface. In this case, the interface is a dynamically created virtual access interface existing on a VTY line. |
| Internet address | interface is unnumbered | IP address, or IP unnumbered for the line. If unnumbered, the output lists the interface and IP address to which the line is assigned (Ethernet0 at 10.0.21.14 in this example). |
| MTU | Maximum transmission unit for packets on the virtual access interface. |
| BW | Bandwidth of the virtual access interface in kilobits per second. |
| DLY | Delay of the virtual access interface in microseconds. |
| rely | Reliability of the virtual access interface as a fraction of 255 (255/255 is 100% reliability), calculated as an exponential average over five minutes. |
| load | Load on the virtual access interface as a fraction of 255 (255/255 is completely saturated), calculated as an exponential average over five minutes. The calculation uses the value from the bandwidth interface configuration command. |
| Encapsulation | Encapsulation method assigned to the virtual access interface. |
| loopback | Test in which signals are sent and then directed back toward the source at some point along the communication path. Used to test network interface usability. |
| keepalive | Interval set for keepalive packets on the interface. If keepalives have not been enabled, the message is "keepalive not set." |
| DTR | Data Terminal Ready. An RS232-C circuit that is activated to let the DCE know when the DTE is ready to send and receive data. |
| LCP open | closed | req sent | Link control protocol (for PPP only; not for SLIP). LCP must come to the open state before any useful traffic can cross the link. |
| Open IPCP | IPXCP | ATCP | IPCP is IP control protocol for PPP, IPXCP is IPX control protocol for PPP, ATCP is AppleTalk control protocol for PPP. Network control protocols (NCPs) for the PPP suite. The NCP is negotiated after the LCP opens. The NCP must come into the open state before useful traffic can cross the link. |
| Last input | Number of hours, minutes, and seconds since the last packet was successfully received by a virtual access interface. Useful for knowing when a dead interface failed. |
| output | The number of hours, minutes, and seconds since the last packet was successfully transmitted by a virtual access interface. |
| output hang | Number of hours, minutes, and seconds (or never) since the virtual access interface was last reset because of a transmission that took too long. When the number of hours in any of the "last" fields exceeds 24 hours, the number of days and hours is printed. If that field overflows, asterisks are printed. |
| Last clearing | The time at which the counters that measure cumulative statistics (such as number of bytes transmitted and received) shown in this report were last reset to zero. Note that variables that might affect routing (for example, load and reliability) are not cleared when the counters are cleared.
*** indicates the elapsed time is too large to be displayed. |
| Input queue, drops | Number of packets in input queues. Each number is followed by a slash, the maximum size of the queue, and the number of packets dropped due to a full queue. |
| Queueing strategy | The type of queueing selected to prioritize network traffic. The options are first-come-first-serve (FCFS) queueing, weighted fair queueing, priority queueing, and custom queueing. |
| Output queue | Number of packets in output queues. Each number is followed by a slash, the maximum size of the queue, and the number of packets dropped due to a full queue. |
| Conversations | Number of weighted fair queueing conversations. |
| Reserved Conversations | Number of reserved weighted fair queueing conversations. The example shows the number of allocated conversations divided by the number of maximum allocated conversations. In this case, there have been 0 reserved conversations. |
| Five minute input rate, Five minute output rate | Average number of bits and packets transmitted per second in the last five minutes. |
| packets input | Total number of error-free packets received by the system. |
| bytes | Total number of bytes, including data and MAC encapsulation, in the error free packets received by the system. |
| no buffer | Number of received packets discarded because there was no buffer space in the main system. Compare with ignored count. Broadcast storms on Ethernets and bursts of noise on serial lines are often responsible for no input buffer events. |
| broadcasts | Total number of broadcast or multicast packets received by the virtual access interface. |
| runts | Number of packets that are discarded because they are smaller than the medium's minimum packet size. |
| giants | Number of packets that are discarded because they exceed the medium's maximum packet size. |
| input errors | Total number of no buffer, runts, giants, CRCs, frame, overrun, ignored, and abort counts. Other input-related errors can also increment the count, so that this sum might not balance with the other counts. |
| CRC | The cyclic redundancy checksum generated by the originating LAN station or far end device does not match the checksum calculated from data received. On a LAN, this often indicates noise or transmission problems on the LAN interface or the LAN bus. A high number of CRCs is usually the result of collisions or a station transmitting bad data. On a serial link, CRCs often indicate noise, gain hits or other transmission problems on the data link. |
| frame | Number of packets received incorrectly having a CRC error and a noninteger number of octets. On a serial line, this is usually the result of noise or other transmission problems. |
| overrun | Number of times the serial receiver hardware was unable to hand received data to a hardware buffer because the input rate exceeded the receiver's ability to handle the data. |
| ignored | Number of received packets ignored by the virtual access interface because the interface hardware ran low on internal buffers. These buffers are different than the system buffers mentioned previously in the buffer description. Broadcast storms and bursts of noise can cause the ignored count to be incremented. |
| abort | Illegal sequence of one bits on a virtual access interface. This usually indicates a clocking problem between the virtual access interface and the data link equipment. |
| packets output | Total number of messages transmitted by the system. |
| bytes | Total number of bytes, including data and MAC encapsulation, transmitted by the system. |
| underruns | Number of times that the far-end transmitter has been running faster than the near-end communication server's receiver can handle. This might never be reported on some virtual access interfaces. |
| output errors | Sum of all errors that prevented the final transmission of datagrams out of the virtual access interface being examined. Note that this might not balance with the sum of the enumerated output errors, as some datagrams might have more than one error, and others might have errors that do not fall into any of the tabulated categories. |
| collisions | Number of packets colliding. |
| interface resets | Number of times a virtual access interface has been completely reset. This can happen if packets queued for transmission were not sent within several seconds. This can be caused by a malfunctioning modem that is not supplying the transmit clock signal, or by a cable problem. If the system notices that the carrier detect line of a virtual access interface is up, but the line protocol is down, it periodically resets the interface in an effort to restart it. Interface resets can also occur when a virtual access interface is looped back or shut down. |
| restarts | Number of times the controller was restarted because of errors. |
| carrier transitions | Number of times the carrier detect (CD) signal of a virtual access interface has changed state. Indicates modem or line problems if the CD line changes state often. If data carrier detect (DCD) goes down and comes up, the carrier transition counter increments two times. |
| output buffer failures | Number of outgoing packets dropped from the output buffer. |
| output buffers swapped out | Number of times the output buffer was swapped out. |
To display information about the active lines on the router, use the show users user EXEC command.
show users [all]| all | (Optional) Specifies that all lines be displayed, regardless of whether anyone is using them. |
User EXEC
This command first appeared in Cisco IOS Release 11.2.
This command displays the line number, connection name, idle time, hosts (including virtual access interfaces) and terminal location.
The following is sample output from the show users command. You can use it to identify an active virtual access interface:
Router> show users
Line User Host(s) Idle Location
* 0 con 0 idle 01:58
10 vty 0 Virtual-Access2 0 1212321
The asterisk (*) indicates the current terminal session.
Table 23 describes significant fields shown in the displays.
| Field | Description |
|---|---|
| Line | Contains three subfields.
|
|
User | User connected to the line. If no user is listed in this field, no one is using the line. |
| Host(s) | Host to which the user is connected (outgoing connection). A value of idle means that there is no outgoing connection to a host. The value of Virtual-Access2 in the example refers to virtual access interface number 2. The value of Virtual PPP (PT) is the virtual access interface referred to by the previous line.
|
| Idle | Interval (in minutes) since the user has entered something. |
| Location | Either the hard-wired location for the line or, if there is an incoming connection, the host from which incoming connection originated. In the example, 1212321 refers to the X.121 address of an X.25 host. |
When receiving a LAT connection request to a service name, the Cisco router can automatically translate the request to another outgoing protocol connection type. To set this up, use the translate lat global configuration command.
The command syntax that follows shows how to apply a virtual interface template in place of outgoing translate options. If you are using virtual templates for protocol translation, all outgoing options are defined in the virtual interface template. Table 21 lists all outgoing options and their corresponding interface configuration commands.
translate lat incoming-service-name [unadvertised] virtual-template number [global-options]No default translation parameters
Global configuration
This command first appeared before Cisco IOS Release 10.0.
You define the protocol translation connections by choosing a protocol keyword and supplying the appropriate address, host name, or service name. The protocol connection information is followed by optional features for that connection, as appropriate. For example, the binary option is only appropriate with TCP/IP connections. The global options, in general, apply to all the connection types, but there are exceptions.
The following example configures PPP tunneling from a PC across a LAT network. The remote PC is given the IP address 10.12.118.12 when it dials in. The unadvertised keyword prevents broadcast of service advertisements to other servers.
interface Virtual-Template1 ip unnumbered Ethernet0 peer default ip address 10.12.118.12 ppp authentication chap !translatelat pt-printer1unadvertisedvirtual-template 1incoming option outgoing
show translate
translate tcp
translate x25
x29 access-list
x29 profile
When receiving a TCP connection request to a particular destination address or host name, the Cisco router can automatically translate the request to another outgoing protocol connection type. To set this up, use the translate tcp global configuration command.
The command syntax that follows shows how to apply a virtual interface template in place of outgoing translate options. If you are using virtual templates for protocol translation, all outgoing options are defined in the virtual interface template. Table 21 lists all outgoing options and their corresponding interface configuration commands.
translate tcp incoming-address [in-options] virtual-template number [global-options]No default translation parameters
Global configuration
This command first appeared before Cisco IOS Release 10.0.
You define the protocol translation connections by choosing a protocol keyword and supplying the appropriate address, host name, or service name. The protocol connection information is followed by optional features for that connection, as appropriate. For example, the binary option is only appropriate with TCP/IP connections. The global options, in general, apply to all the connection types, but there are exceptions.
The following example illustrates the use of the TCP incoming option printer for an incoming TCP connection:
interface Virtual-Template1 ip unnumbered Ethernet0 peer default ip address 10.12.108.1 ppp authentication chaptranslatetcp 172.19.32.250printerVirtual-Template1! incoming option outgoing
show translate
translate lat
translate x25
x29 access-list
x29 profile
When receiving a X.25 connection request to a particular destination address, the Cisco router can automatically translate the request to another outgoing protocol connection type. To set up this feature, use the translate x25 global configuration command.
The command syntax that follows shows how to apply a virtual interface template in place of outgoing translate x25 options. If you are using virtual templates for protocol translation, all outgoing options are defined in the virtual interface template. Table 21 lists all outgoing options and their corresponding interface configuration commands.
translate x25 incoming-address [in-options] virtual-template number [global-options]No default translation parameters
Global configuration
This command first appeared before Cisco IOS Release 10.0.
You define the protocol translation connections by choosing a protocol keyword and supplying the appropriate address or service name. The protocol connection information is followed by optional features for that connection, as appropriate. The global options, in general, apply to all the connection types, but there are exceptions. The swap keyword, for example, is for X.25 to TCP translations only. See the examples for more explanations on how to enter this command.
The following example shows a virtual template with PPP encapsulation specified by default (not explicit). It also specifies CHAP authentication and an X.29 access list.
x29 access-list 1 permit ^5555 ! interface Virtual-Template1 ip unnumbered Ethernet0 peer default ip address 172.16.2.129 ppp authentication chap ! translate x25 5555667 virtual-template 1 access-class 1
interface virtual-template
show translate
translate lat
translate tcp
x29 access-list
x29 profile
To configure virtual terminal (VTY) lines to support asynchronous protocol functions based on the definition of a virtual interface template, use the vty-async virtual-template global configuration command. Use the no form of this command to disable virtual interface templates for asynchronous functions on virtual terminal lines.
vty-async virtual-template number
| number | The virtual interface number. |
Asynchronous protocol features are not enabled by default on virtual terminal lines.
Global configuration
The vty-async command first appeared in Cisco IOS Release 10.3. The vty-async virtual-template command first appeared in Cisco IOS Release 11.2 F.
The vty-async virtual-template command enables you to support tunneling of SLIP or PPP across X.25, TCP, or LAT networks by using two-step protocol translation.
Before issuing the vty-async virtual-template command, create and configure a virtual interface template by using the interface virtual-template command. Configure this virtual interface as a regular asynchronous serial interface. That is, assign the virtual interface template the IP address of the Ethernet interface, and configure addressing, just as on an asynchronous interface. You can also enter commands in interface configuration mode that compress TCP headers or configure CHAP authentication for PPP.
After creating a virtual interface template, apply it by issuing the vty-async virtual-template command. When a user dials in through a VTY line, the router creates a virtual access interface, which is a temporary interface that supports the asynchronous protocol configuration specified in the virtual interface template. This virtual access interface is created dynamically, and is freed up as soon as the connection drops.
Before virtual templates were implemented, you could use the vty-async command to extend asynchronous protocol functions from physical asynchronous interfaces to VTY lines. However, in doing so, you created a virtual asynchronous interface, rather than the virtual access interface. The difference is that the virtual asynchronous interfaces are allocated permanently, whereas the virtual access interfaces are created dynamically when a user calls in and closed down when the connection drops.
If you are tunnelling SLIP or PPP using the one-step protocol translation method, refer to the "Configure a Virtual Template for One-Step Protocol Translation" section earlier in this feature chapter.
You can have up to 25 virtual templates interfaces, but can apply only one to vty-async interfaces on a router. There can be up to 300 virtual access interfaces on a router.
The following example enables asynchronous protocol features on virtual terminal lines:
vty-async vty-async Virtual-Template 1 vty-async dynamic-routing vty-async header-compression ! interface Virtual-Template1 ip unnumbered Ethernet0 encapsulation ppp no peer default ip address ppp authentication chap
ppp
slip
translate lat
translate tcp
translate x25
interface virtual-template
After configuring a virtual template and applying it to an outgoing translate session, make sure you have configured security to prevent unauthenticated and unauthorized access to network resources. For more information, refer to the chapters "Configuring Network Access Security" and "Configuring Terminal Access Security" in the Cisco IOS Release 11.2 Security Configuration Guide.
|
|