-
Access and Communication Servers Configuration Guide
-
About This Manual
-
Access and Comms Server Product Overview
-
Understanding the User Interface
-
Loading System Images and Config. Files
-
Managing the System
-
Configuring Interfaces
-
Configuring Dial on Demand Routing
-
Configuring LAPB and X.25
-
Configuring Frame Relay
-
Configuring SMDS
-
Configuring Telnet
-
Configuring LAT
-
Configuring TN3270
-
Configuring AppleTalk Remote Access
-
Configuring SLIP and PPP
-
Configuring XRemote
-
Configuring AppleTalk Routing
-
Configuring IP
-
Configuring IP Routing
-
Configuring Novell IPX
-
Configuring Protocol Translation
-
Table Of Contents
Interface Configuration Task List
Understand Supported Interfaces and Encapsulations
Synchronous Serial Compression
Synchronous Serial Encapsulation Methods
Asynchronous Serial Encapsulation Methods
Ethernet Encapsulation Methods
Token Ring Encapsulation Methods
Configure an Asynchronous Serial Interface
Configure an Ethernet Interface
Configure a Loopback Interface
Configure a Synchronous Serial Interface
Configure a Token Ring Interface
Configure Low-Speed Serial Interfaces on Cisco 2500 Routers
Overview of Half-Duplex DTE and DCE State Machines
Half-Duplex DTE State Machines
Half-Duplex DCE State Machines
Change between Controlled-Carrier and Constant-Carrier Modes
Place a Low-Speed Serial Interface in Controlled-Carrier Mode
Place a Low-Speed Serial Interface in Constant-Carrier Mode
Change between Controlled-Carrier and Constant-Carrier Modes Example
Tune Half-Duplex Timers Example
Change between Synchronous and Asynchronous Modes
Return a Low-Speed Serial Interface to Synchronous Mode
Specify the Mode of a Low-Speed Serial Interface Example
Configure Compression of PPP Data
Add a Description for an Interface
Configure Group and Member Asynchronous Interfaces
Define Slave Asynchronous Interface Characteristics
Configure the Tunnel Interface
Configure the Tunnel Destination
Configure End-to-End Checksumming
Configure a Tunnel Identification Key
Configure a Tunnel Interface to Drop Out-of-Order Datagrams
Understand Asynchronous Host Mobility
Configure Synchronous Serial Features
Reenable HDLC Serial Encapsulation
Configure Compression of HDLC Data
Configure Compression of LAPB Data
Configure the Clock Rate on DCE Appliques
Monitor and Maintain Snapshot Routing
Assigning IP Addresses to an Incoming Connection
Configure DHCP Address Pooling
Turn off DHCP Address Pooling on an Interface
Configure Local IP Address Pooling
Turn off Local IP Address Pooling on an Interface
Configure Specific IP Addresses for an Interface
Configure IP Address Pooling on Point-to-Point Links
Choose the IP Address Assignment Method
Define the Global Default Mechanism
Define DHCP as the Global Default Mechanism
Define Local Address Pooling as the Global Default Mechanism
Configure Per-Interface IP Address Assignment
Select the Ethernet Encapsulation
Configure the Point-to-Point Protocol
Enable CHAP or PAP Authentication
Enable Link Quality Monitoring
Ignore DCD and Monitor DSR as Line Up/Down Indicator
Control Interface Hold-Queue Limits
Limit Size of the Transmit Queue
Adjust Maximum Packet Size or MTU Size
Monitor and Maintain the Interface
Shut Down and Restart an Interface
Run Interface Loopback Diagnostics
Enable Loopback on MCI and SCI Serial Cards
Enable Loopback on MCI and MEC Ethernet Cards
Configure the Ethernet Loopback Server
Enable Loopback on Token Ring Cards
Interface Configuration Examples
Enabling Interface Configuration Example
Restricted Access on the Asynchronous Interface Example
SLIP and PPP Connection Examples
Interface Description Examples
Group and Member Asynchronous Interfaces Examples
CHAP with an Encrypted Password Example
When the Primary Line Goes Down
When the Primary Line Reaches Threshold
When the Primary Line Exceeds Threshold
Configure DHCP Pooling Examples
Configure Local Pooling Example
Configure Specific IP Addresses for an Interface Example
Configuring Interfaces
Use the information in this chapter to understand the types of interfaces supported on Cisco Systems access servers. Our access servers support two types of interfaces: physical and virtual interfaces.The virtual interfaces our access servers support include subinterfaces and IP tunnels.
For hardware technical descriptions and information about installing the access server interfaces, refer to the hardware installation and maintenance publication for your particular product. For command descriptions and usage information, refer to the Access and Communication Servers Command Reference publication.
Note
One or more of the commands that previously appeared in this chapter have been replaced by new commands. See the Access and Communication Servers Command Reference publication for command information. The old commands continue to perform their normal function in the current release, but support for them will cease in a future release.
Interface Configuration Task List
You can perform the tasks in the following sections to configure and maintain the interfaces supported on your access servers. The first section introduces material that you might need to know in advance of the other tasks.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
See "Interface Configuration Examples" at the end of this chapter for interface configuration examples.
Understand Supported Interfaces and Encapsulations
The following sections describe the interfaces and encapsulations supported by our access servers.
Synchronous Serial
Support for the synchronous serial interface is supplied on the following serial network interface cards or systems:
•
•
•
The MCI and SCI cards can query the appliques to determine their types for use in reports displayed by the EXEC show commands. However, they do so only at system startup, so the appliques must be attached when the system is started. Use the show interfaces and show controllers mci EXEC commands to display the serial port numbers. These commands provide a report for each interface supported by the access server.
Synchronous Serial Compression
The synchronous serial interface supports point-to-point compression. Our software implements a predictor compressor (the RAND algorithm). Compression of LAPB data is supported for LAPB.
Synchronous Serial Encapsulation Methods
By default, synchronous serial lines use the High-level Data Link Control (HDLC) serial encapsulation method, which provides the synchronous framing and error detection functions of HDLC without windowing or retransmission. The synchronous serial interfaces support the following serial encapsulation methods:
•
•
•
•
•
Encapsulation methods are set according to the type of protocol or application you configure on your access server. HDLC is described later in this chapter in the section "Reenable HDLC Serial Encapsulation." PPP is described later in this chapter in the section "Configure the Point-to-Point Protocol." The remaining methods are described in their respective chapters describing the protocols or applications. Serial encapsulation methods are also discussed in the Access and Communication Servers Command Reference publication, under the encapsulation command.
Asynchronous Serial
Access and communication server platforms provide a number of methods to connect serial devices, including RJ-11, RJ-45, and 50-pin Telco connectors. The ASM-CS supports Telco and RJ-11 connectors. The Cisco 2500 series access servers support RJ-45 connectors on "octopus" cable adapters that attach to high-density D-type connectors on the rear panel of the servers.
Asynchronous Serial Encapsulation Methods
There are two asynchronous serial encapsulation methods:
•
•
Refer to the chapter "Configuring SLIP and PPP" later in this publication, for more information about these encapsulation methods.
Ethernet
Support for the Ethernet interface is supplied on one of the following Ethernet network interface cards or systems:
•
•
Use the show interfaces and show controllers mci EXEC commands to display the Ethernet port numbers. These commands provide a report for each interface supported by the access server.
Ethernet Encapsulation Methods
Currently, there are three common Ethernet encapsulation methods:
•
•
•
The encapsulation method you use depends upon the type of Ethernet media connected to the access server and the routing application you configure. Further detail is provided in the sections "Select the Ethernet Encapsulation" later in this chapter. See also the chapters describing the protocols or applications.
Token Ring
Support for the Token Ring interface is supplied on The 4/16-Mbps Token Ring cards, which interconnect network servers to IEEE 802.5 and IBM-compatible Token Ring media at speeds of 4 or 16 Mbps. These include the 4/16-Mbps cards or CSC-R16M, CSC-1R, and CSC-2R (dual Token Ring card).
Support for the Token Ring MIB variables is provided as described in RFC 1231, "IEEE 802.5 Token Ring MIB," by K. McCloghrie, R. Fox, and E. Decker, May 1991. The mandatory Interface Table and Statistics Table are implemented, but the optional Timer Table of the Token Ring MIB is not. The Token Ring MIB has been implemented for the TRIP.
Use the show interfaces and show controllers token EXEC commands to display the Token Ring numbers. These commands provide a report for each ring supported by the access server.
Note
Token Ring Encapsulation Methods
The Token Ring interface by default uses the SNAP encapsulation format defined in RFC 1042. It is not necessary to define an encapsulation method for this interface.
Configure the Interface Type
Begin interface configuration in global configuration mode. To configure an interface, follow these steps:
Step 1
Step 2
Serial 0 is administratively down, line protocol is downHardware is MCI SerialMTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255Encapsulation HDLC, loopback not set, keepalive set (10 sec)Use the show hardware EXEC command to see a list of the system software and hardware.
For example, to begin configuring interface Serial 0, you would add the following line to the configuration file:
interface serial 0
Note
Step 3
Step 4
The following sections show how to begin to configure each interface type as a separate task. Follow this command with the routing or bridging interface configuration commands for your particular protocol or application, as described in subsequent chapters.
See the section "Interface Configuration Examples" at the end of this chapter.
Configure an Asynchronous Serial Interface
To specify an asynchronous interface, perform the following task in global configuration mode.
For more information on asynchronous interfaces, refer to the chapter "Configuring SLIP and PPP" later in this publication. To use SLIP or PPP to make a connection, see the Cisco Access Connection Guide.
Configure a Dialer Interface
To specify a dialer rotary group leader, perform the following task in global configuration mode:
Configure an Ethernet Interface
To configure an Ethernet interface, perform the following task in global configuration mode:
Configure a Loopback Interface
You can specify a software-only interface called a loopback interface that emulates an interface that is always up. A loopback interface is a virtual interface that allows BGP and RSRB sessions to stay up even if the outbound interface is down, and is supported on all platforms.
You can use the loopback interface as the termination address for BGP sessions, for RSRB connections, or for establishing a Telnet session from the access server's console to its auxiliary port when all other interfaces are down. In applications where other access servers will attempt to reach this loopback interface, you need to configure a routing protocol to distribute the subnet assigned to the loopback address.
Packets routed to the loopback interface are rerouted back to the box and processed locally. IP packets routed out the loopback interface but not destined to the loopback interface are dropped. This means the loopback interface also serves as the Null 0 interface.
To configure a loopback interface, perform the following task in global configuration mode:
See also the section "Run Interface Loopback Diagnostics" later in this chapter.
Configure a Null Interface
The access server supports a "null" interface. This pseudo-interface functions similarly to the null devices available on most operating systems. This interface is always up and can never forward or receive traffic; encapsulation always fails. The only interface configuration command that you can specify for the null interface is no ip redirects.
The null interface provides an alternative method of filtering traffic. The overhead involved with using access lists can be avoided by directing undesired network traffic to the null interface.
To specify the null interface, perform the following task in global configuration mode:
Specify null 0 (or null0) as the interface name and unit. The null interface can be used in any command that has an interface type as an argument. The following example configures a null interface for IP route 172.16.0.0:
ip route 172.16.0.0 255.0.0.0 null 0Configure a Synchronous Serial Interface
To configure a synchronous serial interface, perform the following task in global configuration mode:
For synchronous serial features, see the section "Configure Synchronous Serial Features" later in this chapter.
Configure a Token Ring Interface
To configure a Token Ring interface, perform the following task in global configuration mode:
Configure Low-Speed Serial Interfaces on Cisco 2500 Routers
This section describes how to configure low-speed serial interfaces on Cisco 2520 through Cisco 2523 routers. It describes these tasks in the following sections:
•
•
•
•
Overview of Half-Duplex DTE and DCE State Machines
The following section describes the communication process between half-duplex DTE transmit and receive state machines and half-duplex DCE transmit and receive state machines.
Half-Duplex DTE State Machines
As shown in , the half-duplex DTE transmit state machine for low-speed interfaces remains in the ready state when it is quiescent. When a frame is available for transmission, the state machine transitions to the transmit delay state and waits for a time period, which is defined by the half-duplex timer transmit-delay value command. You can choose a value between the range of 0 to 4400 ms (4.4 seconds) to configure this command. The default is 0 ms. Transmission delays are used for debugging half-duplex links and assisting lower speed receivers that cannot process back-to-back frames.
Figure 1 Half-Duplex DTE Transmit State Machine
After idling for a defined number of ms, the state machine asserts request to send (RTS) and transitions to the wait clear to send (CTS) state for the data communications equipment (DCE) to assert CTS. A timeout timer with a value set by the half-duplex timer rts-timeout value command starts. The range you configure is dependent on the serial interface hardware that is installed. This default is 3 ms. If the timeout timer expires before CTS is asserted, the state machine returns to the ready state and de-asserts RTS. If CTS is asserted prior to the timer's expiration, the state machine transitions to the transmit state and sends the frames.
Once there are no more frames to transmit, the state machine transitions to the wait transmit finish state. The machine waits for the transmit first in first out (FIFO) in the serial controller to empty, starts a delay timer with a value defined by the half-duplex timer rts-drop-delay value interface command, and transitions to the wait RTS drop delay state. You can choose a value between the range of 0 and 1140000 ms (1140 seconds). The default is 3 ms.
When the timer in the wait RTS drop delay state expires, the state machine de-asserts RTS and transitions to the wait CTS drop state. A timeout timer with a value set by the half-duplex timer cts-drop-timeout value interface command starts, and the state machine waits for the CTS to de-assert. You can choose a value between the range of 0 to 1140000 ms (1140 seconds). The default is 250 ms. Once the CTS signal is de-asserted or the timeout timer expires, the state machine transitions back to the ready state. If the timer expires before CTS is de-asserted, an error counter is incremented, which can be displayed by issuing the show controllers command for the serial interface in question.
As shown in , a half-duplex DTE receive state machine for low-speed interfaces idles and receives frames in the ready state. A giant frame is any frame whose size exceeds the maximum transmission unit (MTU). If the beginning of a giant frame is received, the state machine transitions to the in giant state and discards frame fragments until it receives the end of the giant frame. At this point, the state machine transitions back to the ready state and waits for the next frame to arrive.
Figure 2 Half-Duplex DTE Receive State Machine
An error counter is incremented upon receipt of the giant frames. To view the error counter, enter the show interface command for the serial interface in question.
Half-Duplex DCE State Machines
As shown in , for a low-speed serial interface in DCE mode, the half-duplex DCE transmit state machine idles in the ready state when it is quiescent. When a frame is available for transmission on the serial interface, such as when the output queues are no longer empty, the state machine starts a timer (based on the value the transmit-delay keyword, in milliseconds) and transitions to the transmit delay state. Similar to the DTE transmit state machine, the transmit delay state gives you the option of setting a delay between the transmission of frames; for example, this feature lets you compensate for a slow receiver that loses data when multiple frames are received in quick succession. Use the half-duplex timer transmit-delay value interface configuration command to specify a delay value not equal to 0. You can choose a value between the range of 0 to 4400 ms (4.4 seconds). The default is 0 ms.
Figure 3 Half-duplex DCE Transmit State Machine
After the transmit delay state, the next state depends on whether the interface is in constant-carrier mode (the default) or controlled-carrier mode.
If the interface is in constant-carrier mode, it transitions through the following states:
1
2
3
If the interface is in controlled-carrier mode, the interface performs a handshake using the data carrier detect (DCD) signal. In this mode, DCD is de-asserted when the interface is idle and has nothing to transmit. The transmit state machine transitions through the states as follows:
1
2
3
4
5
As shown in , the half-duplex DCE receive state machine idles in the ready state when it is quiescent. It transitions out of this state when the DTE asserts RTS. In response, the DCE starts a timer configured by the cts-delay keyword. This timer delays the assertion of CTS because some DTE interfaces expect this delay. Use the half-duplex timer cts-delay value interface configuration command to specify a delay value. The value you configure is dependent to the serial interface hardware installed.
Figure 4 Half-duplex DCE Receive State Machine
When the timer expires, the DCE state machine asserts CTS and transitions to the receive state. It stays in the receive state until there is a frame to receive. If the beginning of a giant frame is received, it transitions to the in giant state and keeps discarding all the fragments of the giant frame and transitions back to the receive state.
Transitions back to the ready state occur when RTS is de-asserted by the DTE. The response of the DCE to the de-assertion of RTS is to de-assert CTS and go back to the ready state.
Change between Controlled-Carrier and Constant-Carrier Modes
The half-duplex controlled-carrier command enables you to change between controlled-carrier and constant-carrier modes for low-speed serial DCE interfaces in half-duplex mode. Configure a serial interface for half-duplex mode by using the media-type half-duplex command. Full-duplex mode is the default for serial interfaces. This interface configuration is available on Cisco 2520 through Cisco 2523 routers.
Controlled-carrier operation means that the DCE interface will have DCD de-asserted in the quiescent state. When the interface has something to transmit, it will assert DCD, wait a user-configured amount of time, then start the transmission. When it has finished transmitting, it will again wait a user-configured amount of time, then de-assert DCD.
Place a Low-Speed Serial Interface in Controlled-Carrier Mode
To place a low-speed serial interface in controlled-carrier mode, perform the following task in interface configuration mode:
Place a low-speed serial interface in controlled-carrier mode.
half-duplex controlled-carrier
Place a Low-Speed Serial Interface in Constant-Carrier Mode
To return a low-speed serial interface to constant-carrier mode from controlled-carrier mode, perform the following task in interface configuration mode:
Place a low-speed serial interface in constant-carrier mode.
no half-duplex controlled-carrier
Change between Controlled-Carrier and Constant-Carrier Modes Example
The following example shows how to change to controlled-carrier mode from the default of constant-carrier operation:
Router(config)# interface serial 2Router(config-if)# half-duplex controlled-carrierThe following example shows how to change to constant-carrier mode from controlled-carrier mode:
Router(config)# interface serial 2Router(config-if)# no half-duplex controlled-carrierTune Half-Duplex Timers
To tune half-duplex timers, perform the following task in interface configuration mode:
The timer tuning commands permit you to adjust the timing of the half-duplex state machines to suit the particular needs of their half-duplex installation.
Note that the half-duplex timer command and its options deprecates the following two timer tuning commands that are available only on high-speed serial interfaces:
•
•
Tune Half-Duplex Timers Example
The following examples show how to set the cts-delay timer to 1234 ms and the transmit-delay timer to 50 ms.
Router(config)# interface serial 2Router(config-if)# half-duplex timer cts-delay 1234Router(config-if)# half-duplex timer transmit-delay 50Change between Synchronous and Asynchronous Modes
To specify the mode of a low-speed serial interface as either synchronous or asynchronous, perform the following task in interface configuration mode:
Specify the mode of a low-speed interface as either synchronous or asynchronous.
physical-layer {sync | async}
This command applies only to low-speed serial interfaces available on Cisco 2520 through Cisco 2523 routers.
In synchronous mode, low-speed serial interfaces support all interface configuration commands available for high-speed serial interfaces, except the following two commands:
•
•
When placed in asynchronous mode, low-speed serial interfaces support all commands available for standard asynchronous interfaces. The default is synchronous mode.
Note that when you enter this command, it does not appear in the output of show running config and show startup config command, because the command is a physical-layer command.
Return a Low-Speed Serial Interface to Synchronous Mode
To return to the default mode (synchronous) of a low-speed serial interface on a Cisco 2520 through Cisco 2523 router, perform the following task in interface configuration mode:
Specify the Mode of a Low-Speed Serial Interface Example
The following example shows how to change a low-speed serial interface from synchronous to asynchronous mode:
Router(config)# interface serial 2Router(config-if)# physical-layer asyncThe following examples show how to change a low-speed serial interface from asynchronous mode back to its default synchronous mode:
Router(config)# interface serial 2Router(config-if)# physical-layer syncorRouter(config)# interface serial 2Router(config-if)# no physical-layerThe following example shows some typical asynchronous interface configuration commands:
Router(config)# interface serial 2Router(config-if)# physical-layer asyncRouter(config-if)# ip address 1.0.0.2 255.0.0.0Router(config-if)# async default ip address 1.0.0.1Router(config-if)# async mode dedicatedRouter(config-if)# async default routingThe following example shows some typical synchronous serial interface configuration commands available when the interface is in synchronous mode:
Router(config)# interface serial 2Router(config-if)# physical-layer syncRouter(config-if)# ip address 1.0.0.2 255.0.0.0Router(config-if)# no keepaliveRouter(config-if)# ignore-dcdRouter(config-if)# nrzi-encodingRouter(config-if)# no shutdownConfigure Compression of PPP Data
You can configure point-to-point software compression on serial interfaces that use PPP encapsulation. Compression reduces the size of a PPP frame via lossless data compression. The compression algorithm used is a predictor algorithm (the RAND algorithm), which uses a compression dictionary to predict what the next character in the frame will be.
For HDLC encapsulations, you can specify a Stacker compression algorithm by using the stac keyword. PPP encapsulations support both predictor and Stacker compression algorithms.
Compression is performed in software and might significantly affect system performance. We recommend that you disable compression if CPU load exceeds 65 percent. To display the CPU load, use the show process cpu EXEC command.
If the majority of your traffic is already compressed files, it is recommended that you not use compression.
To configure compression over PPP, perform the following tasks in interface configuration mode:
Step 1
encapsulation ppp
Step 2
compress [predictor | stac]
Add a Description for an Interface
You can add a description about an interface to help you remember what is attached to it. This entry is meant solely as a comment to help identify what the interface is being used for. The description will appear in the output of the following commands: show startup-config, copy running-config, and show interfaces.
To add the description, complete the following task in interface configuration mode:
For examples of adding a description, see the section "Interface Configuration Examples" at the end of this chapter.
Configure Group and Member Asynchronous Interfaces
Using the interface group-async command, you can create an asynchronous interface to be used as a group interface. In turn, other asynchronous interfaces, known as "members," can be associated with this asynchronous group interface.
This association allows you to quickly configure the group interface and all of its member interfaces with a single command entered at the asynchronous group interface command line. You can have more than one group interface on a device; however, a member interface can only be associated with one group.
illustrates the group-member interface concept.
Figure 6-1 Group-Member Association on Asynchronous Interfaces
To create an asynchronous group interface and associate member interfaces to this group interface, perform the following commands starting in global configuration mode:
Refer to "Group and Member Asynchronous Interfaces Examples" for an example configuration.
Define Slave Asynchronous Interface Characteristics
Member interfaces can have certain interface configurations that differ from their group. The following are valid interface configuration commands:
•
•
To define a member to have one or more interface configurations different from its group, enter the following command in interface configuration mode, where interface-command is one of the commands listed in the preceding list:
Configure a member to have specific differences from its group.
member interface-number interface-command
Understand Subinterfaces
A subinterface is a mechanism that allows a single physical interface to support multiple logical interfaces or networks. That is, several logical interfaces or networks can be associated with a single hardware interface. Subinterfaces are implemented in various WAN and LAN protocols, including ATM, Frame Relay, SMDS, X.25, and Novell IPX. For more information about using subinterfaces, refer to the appropriate protocol chapter in this publication.
Understand Tunneling
Tunneling provides a way to encapsulate arbitrary packets inside of a transport protocol. This feature is implemented as a virtual interface to provide a simple interface for configuration. The tunnel interface is not tied to specific "passenger" or "transport" protocols, but rather, it is an architecture that is designed to provide the services necessary to implement any standard point-to-point encapsulation scheme.
Tunneling has three primary components:
•
•
•
•
•
•
To understand the process of tunneling, consider connecting two AppleTalk networks with a non-AppleTalk backbone, such as IP. The relatively high bandwidth consumed by the broadcasting of Routing Table Maintenance Protocol (RTMP) data packets can severely hamper the backbone's network performance. This problem can be solved by tunneling AppleTalk through a foreign protocol, such as IP. Tunneling encapsulates an AppleTalk packet inside the foreign protocol packet, which is then sent across the backbone to a destination access server. The destination access server then de-encapsulates the AppleTalk packet and, if necessary, routes the packet to a normal AppleTalk network. Because the encapsulated AppleTalk packet is sent in a directed manner to a remote IP address, bandwidth usage is greatly reduced. Furthermore, the encapsulated packet benefits from any features normally enjoyed by IP packets, including default routes and load balancing.
illustrates IP tunneling terminology and concepts.
Figure 6-2 IP Tunneling Terminology and Concepts
Advantages of Tunneling
There are several situations where encapsulating traffic in another protocol is useful:
•
•
•
•
Figure 6-3 Providing Workarounds for Networks with Limited Hop Counts
Special Considerations
The following are considerations and precautions to observe when configuring tunneling:
•
•
•
•
•
•
Figure 6-4 Tunnel Precautions: Hop Counts
•
•
•
•
If you see line protocol down, as in the following example, it might be because of a recursive route:
%TUN-RECURDOWN Interface Tunnel 0temporarily disabled due to recursive routingConfigure IP Tunneling
If you want to configure IP tunneling, you must perform the tasks in the following sections:
•
•
The tasks in the following tunnel configuration sections are optional:
•
•
•
•
For examples using these commands, see the section "IP Tunneling Examples" at the end of this chapter.
Configure the Tunnel Interface
To configure tunneling, you must configure the tunnel interface by performing the following task in global configuration mode:
Configure the Tunnel Source
You must specify the tunnel interface's source address by performing the following task in interface configuration mode:
Configure the tunnel source.
tunnel source {ip-address | interface-type interface-number}
Note
Configure the Tunnel Destination
You must specify the tunnel interface's destination by performing the following task in interface configuration mode:
Configure the Tunnel Mode
The encapsulation mode for the tunnel interface defaults to generic route encapsulation (GRE), so this task is considered optional. However, if you want a mode other than GRE, you must configure it by performing the following task in interface configuration mode:
If you are tunneling AppleTalk, you must use either AppleTalk Update Routing Protocol (AURP), Cayman or GRE tunneling mode. Cayman tunneling is designed by Cayman Systems, and enables access servers to interoperate with Cayman GatorBoxes. You can have a Cisco access server at either end of the tunnel, or you can have a GatorBox at one end and a Cisco access server at the other end. Use Distance Vector Multicast Routing Protocol (DVMRP) mode when an access server connects to a mrouted access server to run DVMRP over a tunnel. You must configure Protocol-Independent Multicast (PIM) and an IP address on a DVMRP tunnel.
CautionDo not configure a Cayman tunnel with an AppleTalk network address.
If you use GRE, you must have only our access servers at both ends of the tunnel connection. When using GRE to tunnel AppleTalk, you must configure an AppleTalk network address and a zone. Perform the following tasks to tunnel AppleTalk using GRE:
Step 1
interface tunneln
Step 2
appletalk cable-range start-end [network.node]1
Step 3
appletalk zone zone-name2
Step 4
tunnel source [interface | ip-address]
Step 5
tunnel destination ip-address
Step 6
tunnel mode gre ip
1 This command is documented in the "AppleTalk Commands" chapter of the Access and Communication Servers Command Reference publication.
2 This command is documented in the "AppleTalk Commands" chapter of the Access and Communication Servers Command Reference publication.
Configure End-to-End Checksumming
Some passenger protocols rely on media checksums to provide data integrity. By default, the tunnel does not guarantee packet integrity. By enabling end-to-end checksums, the access servers will drop corrupted packets. To enable such checksums on a tunnel interface, perform the following task in interface configuration mode:
Configure a Tunnel Identification Key
You can optionally enable an ID key for a tunnel interface. This key must be set to the same value on the tunnel endpoints. Tunnel ID keys can be used as a form of weak security to prevent misconfiguration or injection of packets from a foreign source.
The tunnel ID key is available with GRE only.
Note
To configure a tunnel ID key, perform the following task in interface configuration mode:
Configure a Tunnel Interface to Drop Out-of-Order Datagrams
You can optionally configure a tunnel interface to drop datagrams that arrive out of order. This is useful when carrying passenger protocols that behave poorly when they receive packets out of order (for example, LLC2-based protocols). This option is available with GRE only.
To use this option, perform the following task in interface configuration mode:
Monitor IP Tunnels
Complete any of the following tasks in EXEC mode to monitor the IP tunnels you have configured:
List tunnel interface information.
show interfaces tunnel unit [accounting]
List the routes that go through the tunnel.
show protocol route1
List the route to the tunnel destination.
show ip route2
1 This command is documented in the "System Management Commands" chapter in the Access and Communication Servers Command Reference publication.
2 This command is documented in the "IP Routing Protocols Commands" chapter in the Access and Communication Servers Command Reference publication.
Understand Asynchronous Host Mobility
Increasingly, mobile users are accessing networks through dial-up telephone connections. In contrast to local employees who can dial directly into an access server providing multiprotocol access to network resources, mobile users must often dial into an access server elsewhere on the organization's internetwork.
The access server supports a packet tunneling strategy that provides the host with mobility across the extended internetwork—in effect creating a virtual private network 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, the user experiences a server environment identical to the one that appears when he or she connects 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.
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.
Figure 6-5 Asynchronous Host Mobility
The remote user implements asynchronous host mobility by executing a User EXEC tunnel command. When executed, the command sets up a network layer connection to the destination specified in the command. 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.
Refer to the Cisco Access Connection Guide for information about setting up the network layer connection with the tunnel command.
Configure Synchronous Serial Features
The optional tasks in the following sections configure features on a synchronous serial interface:
•
•
•
•
Reenable HDLC Serial Encapsulation
The access server provides HDLC encapsulation for serial lines by default. This encapsulation method provides the synchronous framing and error detection functions of HDLC without windowing or retransmission. Although it is the default, it can be reenabled as the encapsulation method, if necessary, by performing the following task in interface configuration mode:
Configure Compression of HDLC Data
You can configure point-to-point software compression on serial interfaces that use HDLC encapsulation. Compression reduces the size of a HDLC frame via lossless data compression. The compression algorithm used is a Stacker (LZS) algorithm.
Compression is performed in software and might significantly affect system performance. We recommend that you disable compression if CPU load exceeds 65%. To display the CPU load, use the show process cpu EXEC command.
If the majority of your traffic is already compressed files, you should not use compression.
To configure compression over HDLC, perform the following tasks in interface configuration mode:
Step 1
encapsulation hdlc
Step 2
compress stac
Configure Compression of LAPB Data
You can configure point-to-point software compression on serial interfaces that use LAPB or multi-LAPB encapsulation. Compression reduces the size of a LAPB or multi-LAPB frame via lossless data compression. The compression algorithm used is a predictor algorithm (the RAND algorithm), which uses a compression dictionary to predict what the next character in the frame will be.
Compression is performed in software and might significantly affect system performance. We recommend that you disable compression if CPU load exceeds 65%. To display the CPU load, use the show process cpu EXEC command.
Predictor compression is recommended when the bottleneck is the load on the router; Stacker compression is recommended when the bottleneck is line bandwidth. Compression is not recommended if the majority of your traffic is already compressed files. Compression is also not recommended for linespeeds greater than T1; the added processing time will slow performance on such lines.
To configure compression over LAPB, perform the following tasks in interface configuration mode:
Step 1
encapsulation lapb
Step 2
compress [predictor | stac]
To configure compression over multi-LAPB, perform the following tasks in interface configuration mode:
Step 1
encapsulation lapb multi
Step 2
compress [predictor | stac]
When using compression, the MTU for the serial interface and the LAPB N1 parameter should be adjusted as in the following example, in order to avoid informational diagnostics regarding excessive MTU or N1 sizes:
interface serial 0encapsulation lapbcompress predictormtu 1509lapb n1 12072
