-
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
Configuring Dial-on-Demand Routing
Cisco's Implementation of Dial Backup and DDR
Chat Scripts on Asynchronous Interfaces
V.25bis over Synchronous Interfaces
DTR Dialing for Synchronous Interfaces
Dial Backup Configuration Task List
Define the Traffic Load Threshold
Configure an Interface to Place Calls
Create Chat Scripts for Asynchronous Interfaces
Configuring Calls to a Single Site
Configuring Calls to Multiple Sites
Call on a Single Line or Multiple Lines
Configure an Interface to Receive Calls
Configure to Receive Calls from a Single Site
Configure to Receive Calls from Multiple Sites
Receive Calls on a Single Line or Multiple Lines
Receive Calls on a Dialer Rotary Group
Configure an Interface to Place and Receive Calls
Place and Receive Calls from a Single Site
Place and Receive Calls from Multiple Sites
Configure a Router as a Callback Client
Configure a Router as a Callback Server
Monitor and Maintain Snapshot Routing
Configure DDR over an X.25 Interface
Configure DDR over Frame Relay
Configure DDR for Routed Protocols
Set Idle Time for Busy Interfaces
Controlling Access to a DDR Interface
Set the Load Threshold for a Dialer Interface
Disable and Reenable DDR Fast Switching
DTR Dialing Configuration Example
Configuring DDR in an IP Environment Example
Configuring DDR in an IPX Environment Example
Configuring Multiple Destination Dial Strings Example
Configuring Dialer Rotary Groups Example
Dialing a Single Site or Multiple Sites Example
Writing and Implementing Chat Scripts Example
Chat Scripts and Dialer Mapping Example
System Scripts and Modem Scripts Example
Dial-on-Demand PPP Configuration Examples
DTR Dialing Configuration Example
In-Band Dialing (V.25bis) and Static Map
LAPB Support Configuration Example
X.25 Support Configuration Example
AppleTalk Configuration Example
In-Band Dialing (V.25bis) and Static Map
Set Up a One-Way Client-to-Server DDR
Set Up a Two-Way Reciprocal Client-Server DDR without Authentication
Set Up a Two-Way DDR with Authentication
Set Up a Hub-and-Spoke DDR with Authentication
Set Up Two-Way DDR for Novell IPX
Configuration for a Fully Meshed DDR for Novell (IP and IPX with Authentication)
Configuring Dial-on-Demand Routing
This chapter describes how to configure your access server for dial-on-demand routing (DDR) and dial backup. For a complete description of the commands mentioned in this chapter, refer to the "Dial-on-Demand Routing Commands" chapter in the Access and Communication Servers Command Reference publication.
Cisco's Implementation of Dial Backup and DDR
Dial backup provides protection against WAN downtime by allowing you to configure a backup serial line circuit-switched connection. Dial backup software keeps the secondary line inactive (data terminal ready [DTR] inactive) until one of the following conditions is met:
•
The primary line goes down.
•
The secondary line and these conditions are defined using the backup interface, backup load, and backup delay interface configuration commands.
When the software detects a lost Carrier Detect signal from the primary line device or finds that the line protocol is down, it activates DTR on the secondary line. At that time, the data communications equipment (DCE) must be set to dial the remote site. When the connection is made, the routing protocol defined for the serial line will take over the task of transmitting traffic over the dialup line.
DDR provides network connections across the Public Switched Telephone Network (PSTN). Traditionally, networks have been interconnected using dedicated lines for wide-area network (WAN) connections. With DDR, you can use modems, Integrated Service Data Network (ISDN) terminal adapters (TAs), or integrated ISDN capabilities to establish low-volume, periodic network connections over public circuit-switched networks. You can also establish dial-up connections over X.25 or Frame Relay packet-switched networks by using LAPB, X.25, or Frame Relay encapsulations.
illustrates a typical DDR interconnection configuration.
Figure 7-1 Dial-on-Demand Routing Interconnection
DDR Fast Switching
Fast switching is enabled by default on DDR interfaces. It is enabled for two routed protocols, IP and IPX, and for one encapsulation, PPP.
Fast-switching can be disabled and reenabled on a protocol-by-protocol basis on a DDR interface. For information on disabling and reenabling fast switching of protocols, see the "Disable and Reenable DDR Fast Switching" section later in this chapter.
Placing Calls Using DDR
On the access server, DDR places calls using the following two methods:
•
•
Chat Scripts on Asynchronous Interfaces
On asynchronous lines, our access servers support chat scripts used to send commands for modem dialing and logging on to remote systems. To dial a call on an asynchronous line, a chat script must be defined. If multiple chat scripts are defined, regular expressions are used for powerful pattern matching to select between many scripts. Refer to the appendix "Regular Expressions" in the Access and Communication Servers Command Reference publication for information about regular expressions.
A chat script is a string of text that defines the login "conversation" that occurs between two systems. It consists of expect-send pairs, which define the string the local system expects to receive from the remote system and what the local system should send as a reply.
V.25bis over Synchronous Interfaces
Our access servers support connections from the synchronous serial interface to any DCE device that supports V.25bis. V.25bis is an ITU-T recommendation for initiating calls using in-band signaling. Depending on the type of modem or CSU/DSU you are using, ITU-T V.25bis options might be supported.
Note
The V.25bis specification describes two modes of establishing or receiving calls: the direct call mode and the addressed call mode. Access servers support connections using the addressed call mode and synchronous, bit-oriented operation. The addressed call mode allows control signals and commands to be sent over the DCE data interface to establish and terminate calls. These commands are packaged in High-Level Data Link Control (HDLC) synchronous data frames.
Devices used by the access server for dialing out must support certain hardware signals in addition to V.25bis. When the access server drops DTR, the device must disconnect any calls that are currently connected. When the device connects to the remote end, Data Carrier Detect (DCD) must be automatically asserted.
Note
lists V.25bis options. The V.25bis options are supported in the dial string (telephone number) only if you have enabled DDR using the dialer in-band command. The functions of these options are nation-specific, and they might have different implementations in your country. Refer to your modem manual for a list of supported options.
Table 7-1 ITU-T V.25bis Options
Our access servers support connections over serial lines connected by non-V.25bis modems, using EIA signaling (DTR) only.
DTR Dialing for Synchronous Interfaces
Our access servers also support connections from synchronous serial lines through non-V.25bis modems. Access servers connected by non-V.25bis modems must use data terminal ready (DTR) EIA signaling only.
For more information about configuring the router to support DTR dialing, see the "Configure Calls to a Single Site" section later in this chapter.
Controlling Access for DDR
DDR supports a variety of security and access control methods including the following:
•
Packets that are permitted entry according to the access list are identified as "interesting" or "packets of interest." Packets that are not permitted entry or are denied entry by an access list are deemed "uninteresting."
An access server activates the dial-on-demand feature when it receives an interesting packet destined for a location that can be reached over a dialed connection through a PSTN. After the access server dials the destination phone number and establishes a connection, packets can be transmitted. When the transmission is complete, after a configured period of line time during which there is no interesting traffic on the line, the line is automatically disconnected.
Note
•
•
Note
Dial Backup Configuration Task List
You must first decide whether you want to backup when the primary line goes down, when traffic load on the primary line exceeds the defined threshold, or both. The tasks you perform depend on your decision. Perform one or more of the following tasks to configure dial backup:
•
Select Backup Line
To configure dial backup, set a secondary serial interface as a backup to a primary serial interface. An external DCE device such as a modem, attached to a circuit-switched service, must be connected to the secondary serial interface. The external device must be capable of responding to a DTR signal (DTR active) by auto-dialing a connection to a preconfigured remote site.
To select a backup line, perform the following task in interface configuration mode:
The interface specified in the backup interface command can only backup one interface. For an example of selecting a backup line, see "Dial Backup Example" at the end of this chapter.
Define the Traffic Load Threshold
You can configure dial backup to activate the secondary line based on the traffic load on the primary line. The software monitors the traffic load and computes a five-minute moving average. If this average exceeds the value you set for the line, the secondary line is activated and, depending upon how the line is configured, some or all of the traffic will flow onto the secondary dialup line.
To define how much traffic should be handled at one time on an interface, perform the following task in interface configuration mode:
Define the traffic load threshold as a percentage of the primary line's available bandwidth.
backup load {enable-threshold | never}
{disable-load | never}
Define Backup Line Delays
You can configure a value that defines how much time should elapse before a secondary line status changes after a primary line status changed. This means you can define two delays:
•
•
To define these delays, perform the following task in interface configuration mode:
For an example of how to define backup line delays, see "Dial Backup Example" at the end of this chapter.
DDR Configuration Task List
Before you configure the asynchronous interface to support DDR, configure the line as follows:
•
•
•
Refer to the chapter "Configuring Terminal Lines and Modem Support" for more information about setting line speed, flow control, and modem type.
One of the following three tasks is required to configure your access server for dial-on-demand routing:
•
•
•
The following are optional tasks to customize, enhance, and monitor DDR:
•
•
•
The following sections describe these tasks. See the "DDR Configuration Examples" section later in this chapter for an idea of how to configure DDR on your network.
Configure an Interface to Place Calls
The following tasks are required to configure a single interface, multiple interfaces, or dialer rotary groups to place calls:
Step 1
Step 2
Step 3
Step 4
The following sections describe these tasks.
Create Chat Scripts for Asynchronous Interfaces
After a chat script has been defined as described in the "Configuring Terminal Lines and Modem Support" chapter of this publication, it must be applied to a line or an interface before it can be used. To specify a chat script for a line, perform the following task in line configuration mode:
A maximum of one script dialer command can be configured per line. The chat script naming convention described in the "Configuring Terminal Lines and Modem Support" chapter of this publication allows you to specify a chat script by the type of the modem attached to that line as follows:
script dialer modem-type*
It is recommended that one chat script (a "dialer" chat script) be written for placing a call and another chat script (a "system" or "login" chat script) be written to log in to remote systems, where required.
UNIX-style regular expressions are used to match patterns and select between many scripts. This will be useful if you specify modem scripts on an interface that is used to dial multiple destinations. Dialing multiple destinations is described in the "Configuring Calls to Multiple Sites" section in this chapter. Regular expressions are described in the "Regular Expressions" appendix in the Access and Communication Servers Command Reference publication.
You can also assign chat scripts to asynchronous interfaces for purposes other than DDR. For more information, refer to the chapter "Configuring Terminal Lines and Modem Support" in this publication.
Specify Chat Scripts for DDR
After a chat script has been defined as described in the "Configuring Terminal Lines and Modem Support" chapter of this publication, it must be applied to a line or an interface before it can be used. To specify a chat script for a line, perform the following task in line configuration mode:
A maximum of one script dialer command can be configured per line. The chat script naming convention described in the "Configuring Terminal Lines and Modem Support" chapter of this publication allows you to specify a chat script by the type of the modem attached to that line as follows:
script dialer modem-type*
It is recommended that one chat script (a "dialer" chat script) be written for placing a call and another chat script (a "system" or "login" chat script) be written to log in to remote systems, where required.
UNIX-style regular expressions are used to match patterns and select between many scripts. This will be useful if you specify modem scripts on an interface that is used to dial multiple destinations. Dialing multiple destinations is described in the "Configure Calls to Multiple Sites" section. Regular expressions are described in the "Regular Expressions" appendix of the Access and Communication Servers Command Reference publication.
You can also assign chat scripts to asynchronous interfaces for purposes other than DDR. For more information, refer to the chapter "Configuring Terminal Lines and Modem Support" in this publication.
Configuring Calls to a Single Site
The modem chat script becomes the default chat script for an interface. This means that it becomes the default chat script for the dialer string and dialer map commands presented in this section.
To configure an interface to call a single site, perform the following steps:
Step 1
Step 2
For asynchronous interfaces, specify chat scripts and dial strings.To enable DDR and specify either DTR dialing or in-band dialing, perform one of the following tasks in interface configuration mode:
Configure a serial interface to use DTR dialing.
dialer dtr
Configure a serial interface to use in-band dialing.
dialer in-band [odd-parity | no-parity]
To call a single site over serial lines connected by non-V.25bis modems using EIA signaling only (specifically, the Data Terminal Ready [DTR] signal), you enable DDR using the dialer dtr command. A serial interface configured for DTR dialing can place calls only; it cannot accept them. Dialer rotary group leaders cannot be configured for DTR dialing.
For information about configuring the router that will receive the DTR calls, see the "Configure to Receive Calls from a Single Site" section.
To call a single site over serial lines connected by asynchronous interfaces or by V.25bis modems on synchronous interfaces, you enable DDR using the dialer in-band command. If using V.25bis modems, you can optionally specify parity. The 1984 version of the V.25bis specification states that characters must have odd parity. However, the default is no parity.
For an example of configuring an interface to support DTR dialing, see the section "DTR Dialing Configuration Example" later in this chapter.
Note
To place a call to a single site on an asynchronous line for which a modem script has not been assigned or a system script must be specified, perform the following task in interface configuration mode:
Specify chat scripts and a dial string.
dialer map protocol next-hop-address [modem-script
modem-regexp] [system-script system-regexp] dial-string [isdn-subaddress]
Use the dialer map command to specify a chat script if no modem script is specified for the line or an additional (system) chat script is required to log in to the remote system.
You do not need to specify a system script if one of the following is true:
•
•
If you want to call only one remote system per interface, the dialer string command is useful. You do not need to use the dialer map command for authentication. Dialers pass the string you have defined to the external DCE.
To specify the string (telephone number) to be called on serial interfaces (asynchronous or synchronous), perform the following task in interface configuration mode:
Configuring Calls to Multiple Sites
You can configure your access server to call multiple sites from a single line, from multiple lines, or from a dialer rotary group.
Call on a Single Line or Multiple Lines
To configure your access server to call multiple sites on a single line or on multiple lines, perform the following tasks:
Step 1
Step 2
Or, specify a string of numbers to dial.
To enable DDR on an interface, perform the following task in interface configuration mode:
Enable DDR on a serial interface. Set parity on synchronous serial interfaces only.
dialer in-band [no-parity | odd-parity]
To define dialing destinations, perform one of the following tasks, as appropriate:
If you adhered to the chat script naming convention described earlier in this chapter, use the form [modem-script *modulation-type] in the dialer map command, as in ".*-v32bis." This allows you to specify the modulation type that is best for the system you are calling, and allows the modem type for the line to be specified by the modem chat-script command.
The expression "." is a wildcard that matches any character, and the expression "*" indicates that the preceding character can be duplicated multiple times. For more information about regular expressions, refer to the appendix "Regular Expressions" in the Access and Communication Servers Command Reference publication.
If there is a modem script specified in the interface configuration command (dialer map) and a modem script specified in the line configuration command (modem chat-script), the first chat script that matches both will be used. If no script matches both, an error message is logged and the connection is not established. If there is no modem chat script specified for the line, the first chat script (chat-script global configuration command) that matches the modem script regular expression will be used. If there is a system script specified in the interface configuration command, the first chat script to match the regular expression will be used.
Configure a dialer map command for each remote destination for that interface.
Call on a Dialer Rotary Group
To configure your access server to place multiple calls using a dialer rotary group, perform the following tasks:
Step 1
Step 2
Step 3
Step 4
Dialer rotary groups allow you to apply a single interface configuration to a set of physical interfaces. Dialer rotary groups are useful in environments that have multiple callers and calling destinations. Configure a dialer interface unless you are only using a single line for dialing out or have a single line dedicated to each destination.
Note
A dialer rotary group is defined by specifying a "dialer interface." The dialer interface is not a physical interface; it is an entity that allows you to propagate an interface configuration to multiple interfaces. After the dialer interface is defined by a number, interface parameters are configured for the dialer interface. Finally, physical interfaces are assigned to the dialer rotary group. Physical interfaces inherit the interface dialer configuration parameters.
After an interface configuration is propagated to a set of physical interfaces, those interfaces can be used to place calls using standard DDR criteria. When many destinations are configured, any of the physical interfaces in a rotary group can be used for outgoing calls. When traffic arrives, an interface from the rotary group is dialed. When more traffic for a different host arrives, another interface is dialed. Using the dialer interface allows you to specify one set of dialer maps that can apply to multiple physical lines.
You can define none to as many as nine dialer interfaces. Perform the tasks in this section for each dialer rotary group.
To define a rotary group, perform the following task in global configuration mode:
To enable DDR for the dialer rotary group, perform the following task in interface configuration mode:
Enable DDR on a serial interface. Set parity on synchronous serial interfaces only.
dialer in-band [no-parity | odd-parity]
To define multiple dialing destinations for the dialer rotary group, perform one of the following tasks in interface configuration mode, as appropriate:
To assign a physical interface to a dialer rotary group, perform the following task in interface configuration mode:
Include the specified physical interface in a dialer rotary group in interface configuration mode.
dialer rotary-group number
Interfaces in a dialer rotary group do not have individual addresses; when the interface is being used for dialing, it inherits the parameters configured for the dialer interface. However, if the individual interface is configured with an address and it is subsequently used to establish a connection from the user EXEC level, the individual interface address again applies.
Note
illustrates how dialer interfaces work. In this example configuration, serial interfaces 1, 2, and 3 are assigned to dialer rotary group 1. That means that these three interfaces take on the parameters configured for dialer interface 1. For example, when it is being used for dialing, the IP address of serial interface 2 is the same as the address of the dialer interface, 131.108.1.1.
Figure 7-2 Sample Dialer Interface Configuration
Configure an Interface to Receive Calls
You can configure an interface or dialer rotary group to receive calls from a single site or from multiple sites. To configure a single line or multiple lines to receive calls from a single site or multiple sites, simply enable DDR. To receive calls from multiple sites on a dialer rotary group, configure the dialer rotary group to authenticate the caller.
Perform one of the following tasks to configure an interface to receive calls:
•
•
Note
Configure to Receive Calls from a Single Site
To receive a call from a single site, you must enable DDR using the dialer in-band command. Dialers specified by this command use chat scripts for asynchronous interfaces and V.25bis on synchronous interfaces. Parity is not needed to enable DDR to receive calls only.
To receive calls from an interface that is using DTR dialing, an interface can be configured for in-band dialing or not configured for anything but encapsulation, depending on the desired behavior. If the receiving interface is expected to terminate a call when no traffic is received for some time, in-band dialing must be configured (along with access lists and a dummy dialer string). If the receiving interface is purely passive, no additional configuration is necessary.
To enable DDR, perform the following task in interface configuration mode:
Configure to Receive Calls from Multiple Sites
You can configure your access server to receive calls from multiple sites on a single line, on multiple lines, or on a dialer rotary group.
Receive Calls on a Single Line or Multiple Lines
No special configuration is required to receive calls on individual lines.
Receive Calls on a Dialer Rotary Group
The following steps describe how to configure your access server to receive calls on a dialer rotary group:
Step 1
Step 2
Step 3
Step 4
Assign a Rotary Group Leader
Dialer rotary groups allow you to apply a single interface configuration to a set of physical interfaces. Dialer rotary groups are useful in environments that have multiple callers and calling destinations. Configure a dialer interface unless you are only using a single line for dialing out.
A dialer rotary group is defined by specifying a dialer interface. The dialer interface is not a physical interface; it is an entity that allows you to propagate an interface configuration to multiple interfaces. After the dialer interface is defined by a number, interface parameters are configured for the dialer interface. Finally, physical interfaces are assigned to the dialer rotary group. Physical interfaces inherit the interface dialer configuration parameters.
After an interface configuration is propagated to a set of physical interfaces, those interfaces can be used to place calls using standard DDR criteria. When many destinations are configured, any of the physical interfaces in a rotary group can be used for outgoing calls. When traffic arrives, an interface from the rotary group is dialed. When more traffic for a different host arrives, another interface is dialed. Using the dialer interface allows you to specify one set of dialer maps that can apply to multiple physical lines.
Note
You can define 0 to as many as 9 dialer interfaces. For each dialer rotary group, perform the following task in global configuration mode:
Enable DDR
To receive a call from multiple sites, you must enable DDR using the dialer in-band command. Dialers specified by this command use chat scripts for asynchronous interfaces and V.25bis on synchronous interfaces. Parity is not needed to enable DDR to receive calls only.
To enable DDR, perform the following task in interface configuration mode:
Configure Challenge Handshake Authentication Protocol (CHAP)
Point-to-Point Protocol (PPP) with Challenge Handshake Authentication Protocol (CHAP) authentication is often used to inform the central site about which remote access servers are connected to it.
With this authentication information, if another packet is received for a destination to which the access server is already connected, an additional call will not be placed. However, if using rotaries, the packet will be sent out the correct port.
CHAP is specified in RFC 1333. CHAP is supported on synchronous and asynchronous serial interfaces. Using CHAP authentication, each access server identifies itself by a name, which informs the other access server what access servers are currently connected to it. This identification process prevents an access server from placing a call to another access server if it is already connected to that access server and prevents unauthorized access.
Note
When CHAP is enabled, a remote device (a PC, workstation, or access server) attempting to connect to the local access server is requested, or challenged, to respond. The challenge consists of a random number and the host name of the local access server. This challenge is transmitted to the remote device. The required response is an encrypted version of a secret password, or secret, plus a random value and the name of the remote device.
The remote device finds the secret by looking up the host name that was received in the challenge. When the local access server receives the challenge response, it verifies the response by looking up the name of the remote device given in the response. The secret passwords must be identical on the remote device and the local access server. These names and secret passwords are configured using the username command.
By transmitting this response, the secret is never transmitted, preventing other devices from stealing it and gaining illegal access to the system. Without the proper response, the remote device cannot connect to the local access server.
CHAP transactions occur only at the time a link is established. The local access server does not issue a challenge during the rest of the call. (The local access server can, however, respond to such requests from other devices during a call.)
To use CHAP, you must perform the following tasks:
•
•
•
To enable PPP encapsulation, perform the following task in interface configuration mode:
To enable CHAP on an interface configured for PPP encapsulation, perform the following task in interface configuration mode:
Enable CHAP on an interface.
ppp authentication chap [if-needed]
or
ppp authentication chap
Use the optional if-needed argument with TACACS or Extended TACACS. After you enable CHAP, the local access server requires authentication from remote devices that are calling in. If the remote device does not support CHAP, no traffic is passed to that device.
To specify the password to be used in CHAP caller identification, perform the following task in global configuration mode:
Add a name entry for each remote system from which the local access server requires authentication.
To configure TACACS as an alternative to host authentication, perform the following task in interface configuration mode:
Use the ppp use-tacacs command with TACACS and Extended TACACS. Use the aaa authentication ppp command with AAA/TACACS+.
The host name of each site calling in to the local access server needs to be mapped to its address. To map a next hop to a host name, perform the following task in interface configuration mode:
Configure a serial interface to map host names to next hop addresses. For rotary groups only.
dialer map protocol next-hop-address name hostname
Enable PAP
Access control using Password Authentication protocol (PAP) is available on all serial interfaces that use PPP encapsulation. The authentication feature reduces the risk of security violations on your access server.
To use PAP, perform the following task in interface configuration mode:
Enable PAP on the interface.
ppp authentication pap [if-needed]
or
ppp authentication pap [list-name]1
1 This command is documented in the "Interface Configuration Commands" chapter of the Access and Communication Servers Command Reference publication.
Use the optional if-needed argument with TACACS or Extended TACACS. Use the optional list-name keyword with AAA/TACACS+.
To specify the password to be used in PAP caller identification, perform the following task in global configuration mode:
To configure TACACS as an alternative to host authentication, perform the following task in interface configuration mode:
Use the ppp use-tacacs command with TACACS or Extended TACACS. Use the aaa authentication ppp command with AAA/TACACS+.
Assign an Interface to a Dialer Rotary Group
To assign a physical interface to a dialer rotary group, perform the following task in interface configuration mode:
Include the specified physical interface in a dialer rotary group in interface configuration mode.
dialer rotary-group number
Interfaces in a dialer rotary group do not have individual addresses; when the interface is being used for dialing, it inherits the parameters configured for the dialer interface. However, if the individual interface is configured with an address and it is subsequently used to establish a connection from the user EXEC level, the individual interface address again applies.
Configure an Interface to Place and Receive Calls
You can configure an interface or dialer rotary group to both place and receive calls. If the interface is calling and being called by a single site, simply enable DDR and specify a dialer string. For calling and receiving calls from multiple sites, an interface or dialer rotary group must be configured to authenticate callers and to map next hop addresses to phone numbers, or dial strings.
Perform one of the following tasks to configure an interface to place and receive calls:
•
•
Place and Receive Calls from a Single Site
To configure your access server to place calls to, and receive calls from, a single site, perform the following tasks in interface configuration mode:
Step 1
Step 2
When a dialer string is configured on an interface, and CHAP is not, any incoming call is assumed to be from the configured dialer string.
To call and receive a call from a single site, you must enable DDR using the dialer-in-band command. Dialers specified by this command use chat scripts on asynchronous interfaces and V.25bis on synchronous interfaces. If using V.25bis, you can optionally specify parity. The 1984 version of the V.25bis specification states that characters must have odd parity. However, the default is no parity.
To enable DDR, perform the following task in interface configuration mode:
Enable DDR on a serial interface. Set parity on synchronous serial interfaces only.
dialer in-band [no-parity | odd-parity]
To specify a dial-string destination for an interface, perform the following task in interface configuration mode:
Note
Place and Receive Calls from Multiple Sites
To configure a single line, multiple lines, or a rotary group to place calls to and receive calls from multiple sites, perform the following tasks in interface configuration mode:
Step 1
Step 2
Step 3
Step 4
To call and receive calls from multiple sites, you must enable DDR using the dialer in-band command. Dialers specified by this command use chat scripts on asynchronous interfaces and V.25bis on synchronous interfaces. If using V.25bis, you can optionally specify parity. The 1984 version of the V.25bis specification states that characters must have odd parity. However, the default is no parity.
To enable DDR, perform the following task in interface configuration mode:
Enable DDR on a serial interface. Set parity on synchronous serial interfaces only.
dialer in-band [no-parity | odd-parity]
To specify one destination dial-string per interface, perform the following task in interface configuration mode:
Specify a string of numbers to dial (to configure one phone number on multiple lines only).
dialer string dial-string
Calls from the multiple sites will need to be authenticated. Authentication can be done through CHAP. To enable CHAP on an interface and authenticate sites that are calling in, perform the following tasks in interface configuration mode:
Configure an interface for PPP encapsulation.
encapsulation ppp
Enable CHAP.1
ppp authentication {chap | pap} [if-needed]
Map the next hop address to the host name and phone number.
dialer map protocol next-hop-address [modem-script modem-regexp] [system-script system-regexp] name hostname dial-string
1 For more information about configuring CHAP, see the section "Configure Challenge Handshake Authentication Protocol (CHAP)" earlier in this chapter.
shows a configuration in which the central site is calling and receiving calls from multiple sites. In this configuration, multiple sites are calling in to a central site, and the central site is calling out to the remote sites.
Figure 7-3 Sample Configuration Using Dial-on-Demand Routing
Configure PPP Callback
PPP callback provides a client-server relationship between the end points of a point-to-point connection. PPP callback allows a router to request that a dial-up peer router call back. The callback feature can be used to control access and toll costs between the routers.
When PPP callback is configured on the participating routers, the calling router (the callback client) passes authentication information to the remote router (the callback server), which uses the host name and dialstring authentication information to determine whether to place a return call. If the authentication is successful, the callback server disconnects and then places a return call. The remote username of the return call is used to associate it with the initial call so that packets can be transmitted.
Both routers on a point-to-point link must be configured for PPP callback. The callback client must be configured to initiate PPP callback and the callback server must be configured to accept PPP callback.
This feature implements the following callback specifications of RFC 1570:
•
•
Return calls are made using the same dialer rotary group but not necessarily the same line as the initial call.
Note
Configure a Router as a Callback Client
To configure a router interface as a callback client, complete the following tasks beginning in global configuration mode:
Configure a Router as a Callback Server
To configure a router as a callback server, complete the following tasks beginning in global configuration mode:
Step 1
interface serial number
Step 2
dialer in-band [no-parity | odd-parity]
Step 3
encapsulation ppp
Step 4
ppp authentication {chap | pap}
Step 5
dialer map protocol address name hostname class classname dialstring
Step 6
dialer hold-queue number timeout seconds
Step 7
dialer enable-timeout seconds
Step 8
ppp callback accept
Step 9
dialer callback-secure
Step 10
exit
Step 11
map-class dialer classname
Step 12
dialer callback-server [username] [dialstring]
1 Serial interfaces can accept the default timeout of 15 seconds. ISDN interfaces should set a shorter timeout (because of switch latency, the timeout period should be longer than 1 second).
Note
PPP Callback Example
The following example configures a PPP callback server and client to call each other.
The PPP callback server is configured on a serial interface in a router in Atlanta. The callback server requires an enable timeout and a map-class to be defined.
The PPP callback client is configured on a serial interface in a router in Dallas. The callback client does not require an enable timeout and a map-class to be defined.
PPP Callback Server
interface serial0ip address 7.1.1.7 255.255.255.0encapsulation pppdialer callback-securedialer enable-timeout 2dialer map ip 7.1.1.8 name atlanta class dial1 81012345678901dialer-group 1ppp callback acceptppp authentication chap!map-class dialer dial1dialer callback-server usernamePPP Callback Client
interface serial0ip address 7.1.1.8 255.255.255.0encapsulation pppdialer map ip 7.1.1.7 name dallas 81012345678902dialer-group 1ppp callback requestppp authentication chapConfigure Snapshot Routing
Snapshot routing, which is available on serial lines, is a method of learning remote routes dynamically and then keeping the routes available for a period of time while regular routing updates are not being exchanged. This might be during periods when a remote site has not dialed into the local site or when a remote site has a dedicated connection to the local site but wishes to avoid the overhead of exchanging routing updates. Snapshot routing allows you to avoid configuring static routes when using dial-on-demand routing. It also eliminates the overhead required for sending periodic updates over dedicated serial lines.
When configuring snapshot routing, you choose one router on the interface to be the client router and one or more other routers to be server routers. The client router determines the frequency at which routing information is exchanged between routers.
Routing information is exchanged during an active period. At the end of this period, the router takes a snapshot of the entries in the routing table. These entries remain frozen during a quiet period. At the end of the quiet period, another active period starts during which routing information is again exchanged.
At the end of the active period, the client router takes a snapshot of the entries in the routing table. These entries remain frozen during a quiet period. At the end of the quiet period, another active period starts during which routing information is again exchanged. See .
Figure 7-4 Active and Quiet Periods in Snapshot Routing
When the router transitions from the quiet period to the active period, the line might not be available for a variety of reasons. For example, the line might be down or busy, or the PVC might be down. If this happens, the router has to wait through another entire quiet period before it can update its routing table entries. This might be a problem if the quiet period is very long, for example, around 12 hours. To avoid having to wait through the quiet period, you can configure a retry period. If the line is not available when the quiet period ends, the router waits for the amount of time specified by the retry period and then transitions to an active period. See .
Figure 7-5 Retry Period in Snapshot Routing
Snapshot routing is useful in two command situations:
•
•
The following routing protocols support snapshot routing. Note that these are all distance-vector protocols.
•
•
•
To configure snapshot routing, perform the tasks described in the following sections. The tasks in the first two sections are required; those in the remaining section are optional:
•
Configure the Client Router
To configure snapshot routing on the client router that is connected to a dedicated serial line, perform the following steps starting in global configuration mode:
Step 1
interface serial number
Step 2
snapshot client active-time quiet-time [suppress-statechange-updates] [dialer]
To configure snapshot routing on the client router connected to an interface configured for DDR, perform the following steps starting in global configuration mode:
