|
|
This chapter describes how to configure PPP or SLIP encapsulation over asynchronous lines for connection-oriented protocols such as IP, IPX, and AppleTalk. For a complete description of the PPP and SLIP commands in this chapter, refer to the "Asynchronous PPP and SLIP Commands" chapter in 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.
The following sections are provided in this chapter:
Serial Line Internet Protocol (SLIP) and Point-to-Point Protocol (PPP) define methods of sending Internet Protocol (IP) packets over standard asynchronous serial lines with minimum line speeds of 1200 baud.
Using SLIP or PPP encapsulation over asynchronous lines is an inexpensive way to connect PCs to a network. PPP and SLIP over asynchronous dial-up modems allow a home computer to be connected to a network without the cost of a leased line. Dial-up PPP and SLIP links can also be used for remote sites that need only occasional remote node or backup connectivity. Both public-domain and vendor-supported PPP and SLIP implementations are available for a variety of computer applications.
The Cisco IOS software concentrates a large number of SLIP or PPP PC or workstation client hosts onto a network interface that allows the PCs to communicate with any host on the network. The Cisco IOS software can support any combination of SLIP or PPP lines and lines dedicated to normal asynchronous devices such as terminals and modems. Refer to RFC 1055 for more information about SLIP, and RFCs 1331 and 1332 for more information about PPP.
SLIP is an older protocol. PPP is a newer, more robust protocol than SLIP, and it contains functions that can detect or prevent misconfiguration. PPP also provides greater built-in security mechanisms.
Figure 86 illustrates a typical asynchronous SLIP or PPP remote-node configuration.
Sample SLIP or PPP Remote-Node Configuration
The BOOTP protocol allows a client machine to discover its own IP address, the address of the router, and the name of a file to be loaded into memory and executed. There are typically two phases to using BOOTP: first, the client's address is determined and the boot file is selected; then the file is transferred, typically using TFTP.
PPP and SLIP clients can send BOOTP requests to the Cisco IOS software, and the Cisco IOS software responds with information about the network. For example, the client can send a BOOTP request to find out what its IP address is and where the boot file is located, and the Cisco IOS software responds with the information.
BOOTP supports the extended BOOTP requests specified in RFC 1084 and works for both PPP and SLIP encapsulation.
BOOTP compares to Reverse Address Resolution Protocol (RARP) as follows: RARP is an older protocol that allows a client to determine its IP address if it knows its hardware address. (Refer to the Network Protocols Configuration Guide, Part 1 for more information about RARP.) However, RARP is a hardware link protocol, so it can be implemented only on hosts that have special kernel or driver modifications that allow access to these raw packets. BOOTP does not require kernel modifications.
Line configuration commands configure a connection to a terminal or a modem. Interface configuration (async) commands, described in this chapter, configure a line as an asynchronous network interface over which networking functions are performed.
The Cisco IOS software also supports IP routing connections for communication that requires connecting one network to another.
The Cisco IOS software supports protocol translation for PPP and SLIP between other network devices running Telnet, LAT, or X.25. For example, you can send IP packets across a public X.25 PAD network using SLIP or PPP encapsulation when SLIP or PPP protocol translation is enabled. For more information, refer to the chapter "Configuring Protocol Translation and Virtual Asynchronous Devices" in this publication.
If asynchronous dynamic routing is enabled, you can enable routing at the user level by using the routing keyword with the slip or ppp EXEC command.
Asynchronous interfaces offer both dedicated and dynamic address assignment, configurable hold queues and IP packet sizes, extended BOOTP requests, and permit and deny conditions for controlling access to lines. Figure 87 shows a sample asynchronous routing configuration.
The Cisco IOS software recognize a variety of IP broadcast addresses. When a router receives an IP packet from an asynchronous client, it rebroadcasts the packet onto the network without changing the IP header.
The Cisco IOS software receives the SLIP or PPP client broadcasts and responds to BOOTP requests with the current IP address assigned to the asynchronous interface from which the request was received. This facility allows the asynchronous client software to automatically learn its own IP address.
The following tasks are provided:
You can configure network-layer protocols, such as AppleTalk, IP, and IPX, over PPP and SLIP. SLIP supports only IP, but PPP supports each of these protocols. Refer to the sections that follow to configure these protocols over PPP and SLIP.
To enable IP-PPP (IPCP) on a synchronous or asynchronous interface, use the following commands, beginning in interface configuration mode:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| ip address ip-address mask [secondary] | Configure IP routing on the interface. | ||
| encapsulation ppp | Enable PPP encapsulation on the serial interface. | ||
| async mode interactive | Enable interactive mode on an asynchronous interface. |
You can configure IPX to run over PPP (IPXCP) on synchronous serial and asynchronous serial interfaces using one of two methods.
The first method associates an asynchronous interface with a loopback interface configured to run IPX. It permits you to configure IPX-PPP on asynchronous interfaces only.
The second method permits you to configure IPX-PPP on asynchronous and synchronous serial interfaces. However, it requires that you specify a dedicated IPX network number for each interface, which can require a substantial number of network numbers for a large number of interfaces.
You can also configure IPX to run on vtys configured for PPP. Refer to the section "Enable IPX and PPP over X.25 to an IPX Network on vty Lines" later in this section.
To permit IPX client connections to an asynchronous interface, the interface must be associated with a loopback interface configured to run IPX. To permit such connections, use the following commands beginning in global configuration mode:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| ipx routing [node] | Enable IPX routing. | ||
| interface loopback number | Create a loopback interface, which is a virtual interface, existing only inside the router. | ||
| ipx network network1 | Enable IPX routing on the loopback interface. | ||
| exit | Exit to global configuration mode. | ||
| interface async number | Enter interface configuration mode for the asynchronous interface. | ||
| ip unnumbered type number | Configure IP unnumbered routing on the interface. | ||
| encapsulation ppp | Enable PPP encapsulation on the interface. | ||
| async mode interactive | Enable interactive mode on an asynchronous interface. | ||
| Assign the asynchronous interface to the loopback interface configured for IPX. | |||
| ipx sap-interval 0 | Turn off SAP updates to optimize bandwidth on asynchronous interfaces. |
| 1Every interface must have a unique IPX network number. |
If you are configuring IPX-PPP on asynchronous interfaces, you should filter routing updates on the interface. Most asynchronous serial links have very low bandwidth, and routing updates take up a great deal of bandwidth. in the previous task table uses the ipx sap-interval 0 to filter SAP updates. For more information about filtering routing updates, refer to the section "Create Filters for Updating the Routing Table" in the "Configuring Novell IPX" chapter in the Network Protocols Configuration Guide, Part 2.
To enable IPX and PPP, use the following commands starting in global configuration mode. The first five tasks are required. The last task is optional:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| ipx routing [node] | Enable IPX routing. | ||
| interface loopback number | Create a loopback interface, which is a virtual interface, existing only inside the router. | ||
| encapsulation ppp | Enable PPP encapsulation on the interface. | ||
| async mode interactive | Enable interactive mode on an asynchronous interface. | ||
| ipx network network1 | Enable IPX routing on the interface. | ||
| ipx sap-interval 0 | (Optional) Turn off SAP updates to optimize bandwidth on asynchronous interfaces. |
| 1Every interface must have a unique ipx network number. |
If you are configuring IPX and PPP on asynchronous interfaces, you should filter routing updates on the interface. Most asynchronous serial links have very low bandwidth, and routing updates take up a great deal of bandwidth. To filter routing updates, refer to the section "Create Filters for Updating the Routing Table" in the "Configuring Novell IPX" chapter in the Network Protocols Configuration Guide, Part 2.
You can enable IPX-PPP on virtual terminal lines (vtys), which permits clients to log into 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 Figure 88, the client terminal on the X.25 network logs into the access server via a vty line, 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.
To enable IPX to run over your PPP sessions on vty lines, use the following commands beginning in global configuration mode:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| ipx routing [node] | Enable IPX routing. | ||
| interface loopback number | Create a loopback interface. | ||
| ipx network network1 | Enable a virtual IPX network on the loopback interface. | ||
| Enable IPX-PPP on vty lines by assigning the vty to the loopback interface configured for IPX. |
| 1Every loopback interface must have a unique IPX network number. |
You can configure an asynchronous interface so that users can access AppleTalk zones by dialing into the router via PPP through this interface. Users accessing the network can run AppleTalk and IP natively on a remote Macintosh, access any available AppleTalk zones from Chooser, use networked peripherals, and share files with other Macintosh users. This feature is also referred to as ATCP.
You create a virtual network that exists only for accessing an AppleTalk internet through the server. To create a new AppleTalk zone, issue the appletalk virtual-net command and use a new zone name; this network number is then the only one associated with this zone. To add network numbers to an existing AppleTalk zone, use this existing zone name in the command; this network number is then added to the existing zone.
Routing is not supported on these interfaces.
To enable ATCP for PPP, use the following commands in interface configuration (asynchronous) mode:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| encapsulation ppp | Define encapsulation as PPP on this interface. | ||
| appletalk virtual-net network-number zone-name | Create an internal network on the server. | ||
| Enable client-mode on this interface. |
To enable IP-SLIP on a synchronous or asynchronous interface, use the following commands beginning in interface configuration mode:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| ip address ip-address mask | Configure IP routing on the interface. | ||
| encapsulation slip | Enable SLIP encapsulation on the serial interface. | ||
| Enable interactive mode on an asynchronous interface. |
The access server supports a packet tunneling strategy that extends the internetwork---in effect creating a virtual private link for the mobile user. When a user activates asynchronous host mobility, the access server on which the remote user dials into becomes a remote point-of-presence (POP) for the user's home network. Once logged in, users experience a server environment identical to the one that they experience when they connect directly to the "home" access server.
Once the network layer connection is made, data packets are tunneled at the physical and/or data link layer instead of at the protocol layer. In this way, raw data bytes from dial-in users are transported directly to the "home" access server, which processes the protocols.
Figure 89 illustrates the implementation of asynchronous host mobility on an extended internetwork. A mobile user connects to an access server on the internetwork and, by activating asynchronous host mobility, is connected to a "home" access server configured with the appropriate username. The user sees an authentication dialog or prompt from the "home" system and can proceed as if he or she were connected directly to that device.
Asynchronous host mobility is enabled with the tunnel EXEC command and the ip tcp async-mobility server global command. The ip tcp async-mobility server command establishes asynchronous listening on TCP tunnel port 57. The tunnel command sets up a network layer connection to the specified destination. Both commands must be used. The access server accepts the connection, attaches it to a virtual terminal (vty), and runs a command parser capable of running the normal dial-in services. After the connection is established, data is transferred between the modem and network connection with a minimum of interpretations. When communications are complete, the network connection can be closed and terminated from either end.
To enable asynchronous host mobility, use the following commands in user EXEC mode:
| Step | Command | Purpose |
|---|---|---|
1 | configure terminal | Enter global configuration mode. |
2 | ip tcp async-mobility server | Enable asychronous listening on TCP tunnel port 57. |
3 | exit | Go to User EXEC mode. |
4 | Set up a network layer connection to a router by specifying its Internet name or address. Replace the host argument with the name or address of the device you want to connect to. |
From a router other than a Cisco router, you must use Telnet.
After a connection is established, you receive an authentication dialog or prompt from your home router, and can proceed as if you are connected directly to that router. When communications are complete, the network connection can be closed and terminated from either end of the connection.
This section describes how to connect devices across telephone lines by using the Point-to-Point Protocol (PPP) and Serial Line Internet Protocol (SLIP).
This section contains the following sections:
| Command | Purpose |
|---|---|
ppp {/default | {remote-ip-address | remote-name} [@tacacs-server]} [/routing] | Create a PPP connection. |
If you specify an address for the TACACS server using /default or tacacs-server, the address must be the first parameter in the command after you type ppp. If you do not specify an address or enter /default, you are prompted for an IP address or host name. You can enter /default at this point.
For example, in Figure 90, if you are working at home on the device ntpc and want to connect to Server 1 using PPP, you could dial into the access server. When you connect to the EXEC prompt on the access server, type the ppp command to connect with the device.
To terminate a session, disconnect from the device on the network using the command specific to that device. Then, exit from the EXEC by using the exit command.
To make a serial connection to a remote host by using SLIP, use the following command in EXEC mode:
| Command | Purpose |
|---|---|
slip [/default] {remote-ip-address | remote-name} [@tacacs-server] [/routing]} [/compressed] | Create a SLIP connection. |
Your system administrator can configure SLIP to expect a specific address or to provide one for you. It is also possible to set up SLIP in a mode that compresses packets for more efficient use of bandwidth on the line.
If you specify an address for the TACACS server using /default or tacacs-server, the address must be the first parameter in the command after you type slip. If you do not specify an address or enter /default, you are prompted for an IP address or host name. You can enter /default at this point.
If you do not use the tacacs-server argument to specify a TACACS server for SLIP address authentication, the TACACS server specified at login (if any) is used for the SLIP address query.
To optimize bandwidth on a line, SLIP enables compression of the SLIP packets using Van Jacobson TCP header compression as defined in RFC 1144.
To terminate a session, disconnect from the device on the network using the command specific to that device. Then, exit from EXEC mode by using the exit command.
NetBIOS Extended User Interface (NetBEUI) is a simple networking protocol developed by IBM for use by PCs in a LAN environment. It is an extension of IBM's original Network Basic Input/Output System (NetBIOS). NetBEUI uses a broadcast-based name to 802.x address translation mechanism. Because NetBEUI has no network layer, it is a nonroutable protocol.
The NetBIOS Frames Control Protocol (NBFCP) enables packets from a NetBEUI application to be transferred via a PPP connection. For this release, NetBEUI/PPP is supported in the access server and Cisco enterprise images only.
Using the Cisco IOS implementation, remote NetBEUI users can have access to LAN-based NetBEUI services. The PPP link becomes the ramp for the remote node to access NetBIOS services on the LAN. Refer to Figure 91. An LLC2 connection is set up between the remote access client and router, and a second LLC2 connection is set up between the router and the remote access (NetBEUI) server.
By supporting NetBEUI remote clients over PPP, Cisco routers function as a native NetBEUI dialin router for remote NetBEUI clients. Thus, you can offer remote access to a NetBEUI network through asynchronous or ISDN connections.
To enable a remote access client using a NetBEUI application to connect with the remote router providing NetBEUI services, you must configure interfaces on the remote access client side and the remote router side. Use the following command beginning in interface configuration mode:
| Command | Purpose |
|---|---|
netbios nbf | Enable NetBEUI's NetBIOS Frames Protocol on each side of a NetBEUI connection. |
To view NetBEUI connection information, use the following command in EXEC mode:
| Command | Purpose |
|---|---|
show nbf sessions | View NetBEUI connection information. |
To tune IP performance, complete the tasks in the following sections:
You can compress the headers of your TCP/IP packets to reduce their size and thereby increase performance. Header compression is particularly useful on networks with a large percentage of small packets, such as those supporting many Telnet connections. 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 serial lines using HDLC or PPP encapsulation. You must enable compression on both ends of a serial connection.
You can optionally specify outgoing packets to be compressed only if TCP incoming packets on the same interface are compressed. If you do not specify this option, the Cisco IOS software will compress all traffic. The default is no compression.
You can also specify the total number of header compression connections that can exist on an interface. You should configure one connection for each TCP connection through the specified interface.
To enable compression, use the following tasks in interface configuration mode:
| Command | Purpose |
|---|---|
ip tcp header-compression [passive] | Enable TCP header compression. |
ip tcp compression-connections number | Specify the total number of header compression connections that can exist on an interface. |
You can set the amount of time that the Cisco IOS software will wait to attempt to establish a TCP connection. In previous versions of the Cisco IOS software, the system would wait a fixed 30 seconds when attempting to do so. This amount of time is not sufficient in networks that have dial-up asynchronous connections, such as a network consisting of dial-on-demand links that are implemented over modems, because it will affect your ability to Telnet over the link (from the router) if the link must be brought up.
Because the connection attempt time is a host parameter, it does not pertain to traffic going through the router, just to traffic originated at it.
To set the TCP connection attempt time, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
ip tcp synwait-time seconds | Set the amount of time the Cisco IOS software will wait to attempt to establish a TCP connection. |
The Cisco IOS software permits compression of IPX packet headers over various WAN media. There are two protocols for IPX compression on point-to-point links.
Cisco routers support IPX Header Compression (CIPX) on all point-to-point Novell interfaces over various WAN media.
CIPX is described in RFC 1553, "Compressing IPX Headers Over WAN Media." The CIPX algorithm is based on the same concepts as Van Jacobson's TCP/IP header compression algorithm. CIPX operates over PPP WAN links using either the IPXCP or IPXWAN communications protocols.
CIPX compresses all IPX headers and IPX/NCP headers for Novell packets with the following Network Control Program (NCP) packet types:
In this version of software, CIPX is configurable only for PPP links.
CIPX header compression can reduce header information from 30 bytes down to as little as 1 byte in size. This reduction can save bandwidth and reduce costs associated with IPX routing over WAN links that are configured to use IPXCP or IPXWAN.
Consider the following issues before implementing CIPX:
To configure CIPX, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
Compress IPX packet headers in a PPP session. |
Fast switching involves the use of a high-speed switching cache for IP routing. With fast switching, destination IP addresses are stored in the high-speed cache so that some time-consuming table lookups can be avoided. The Cisco IOS software generally offers better packet transfer performance when fast switching is enabled.
To enable or disable fast switching, use the following commands in interface configuration mode:
| Command | Purpose |
|---|---|
ip route-cache | Enable fast-switching (use of a high-speed route cache for IP routing). |
no ip route-cache | Disable fast switching and enable load balancing on a per-packet basis. |
The high-speed route cache used by IP fast switching is invalidated when the IP routing table changes. By default, the invalidation of the cache is delayed slightly to avoid excessive CPU load while the routing table is changing.
To control route cache invalidation, use the following commands in global configuration mode as needed for your network:
| Command | Purpose |
|---|---|
no ip cache-invalidate-delay | Allow immediate invalidation of the cache. |
ip cache-invalidate-delay [minimum maximum quiet threshold] | Delay invalidation of the cache. |
The following example shows a line that is in asynchronous mode using PPP encapsulation (see Figure 92). The name of the PC is ntpc. Assuming that the name ntpc is in the Domain Naming System (DNS), the access server can match a real IP address. The PC must be running a terminal emulator program.
router> ppp ntpc@server1
Once a correct password is entered, you are placed in SLIP mode, and the IP address appears.
router> slip
Password: Entering SLIP mode. Your IP address is 192.31.7.28, MTU is 1524 bytes
The following example illustrates the prompts displayed and the response required when dynamic addressing is used to assign the SLIP address:
router> slip
IP address or hostname? 192.31.6.15 Password: Entering SLIP mode Your IP address is 192.31.6.15, MTU is 1524 bytes
In the preceding example, the address 192.31.6.15 has been assigned as the default. Password verification is still required before SLIP mode can be enabled.
router> slip default
Password: Entering SLIP mode Your IP address is 192.31.6.15, MTU is 1524 bytes
The following example illustrates the implementation of header compression on the interface with the IP address 128.66.2.1:
router> slip 128.66.2.1 /compressed Password: Entering SLIP mode. Interface IP address is 128.66.2.1, MTU is 1500 bytes. Header compression will match your system.
In the preceding example, the interface is configured for ip tcp header-compression passive, which permitted the user to enter the /compressed keyword at the EXEC mode prompt. The message "Header compression will match your system" indicates that the user specified compression. If the line was configured for ip tcp header-compression on, this line would read "Header compression is On."
The following example specifies a TACACS server named parlance for address authentication:
router> slip 1.0.0.1@parlance Password: Entering SLIP mode. Interface IP address is 1.0.0.1, MTU is 1500 bytes Header compression will match your system.
Posted: Mon May 3 11:37:55 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.