Table Of Contents
Configuring DDR
Cisco's Implementation of Dial Backup and DDR
Fast Call Rerouting for ISDN
DDR Fast Switching
Placing Calls Using DDR
Chat Scripts on the Auxiliary Port
V.25bis over Synchronous Interfaces
DTR Dialing for Synchronous Interfaces
Controlling Access for DDR
Dial Backup Configuration Task List
Select Backup Line
Define the Traffic Load Threshold
Define Backup Line Delays
DDR Configuration Task Overview
Configure an Interface to Place Calls
Create Chat Scripts for Asynchronous Interfaces
Suggested Chat Script Naming Conventions
Specify Chat Scripts for DDR
Configure Calls to a Single Site
Configure Calls to Multiple Sites
Calling on a Single Line or Multiple Lines
Calling from Dialer Rotary Groups
Configure an Interface to Receive Calls
Configure an Interface to Receive Calls from a Single Site
Configure an Interface to Receive Calls from Multiple Sites
Configure an Interface to Receive Calls on a Single Line or Multiple Lines
Configure an Interface to 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 Multilink PPP
Configure Multilink PPP on Asynchronous Interfaces
Configure Multilink PPP on a Single ISDN BRI Interface
Configure Multilink PPP on Multiple ISDN BRI Interfaces
Configure PPP Callback
Configure a Router as a Callback Client
Configure a Router as a Callback Server
Configure Snapshot Routing
Configure the Client Router
Configure the Server Router
Configure DDR over LAPB
Configure DDR over X.25
Configure DDR over Frame Relay
Configuration Restrictions
Configuration Overview
Configure DDR for Routed Protocols
Configure DDR for AppleTalk
Configure DDR for Banyan VINES
Configure DDR for DECnet
Configure DDR for IP
Configure ISO CLNS over DDR
Configure DDR for Novell IPX
Configure XNS over DDR
Configure DDR for Transparent Bridging
Define the Protocols to Bridge
Specify the Bridging Protocol
Control Access for Bridging
Permit All Bridge Packets
Control Bridging Access by Ethernet Type Codes
Configure an Interface for Bridging
Specify the Interface
Configure the Destination
Assign the Interface to a Bridge Group
Customize the DDR Network
Set Line-Idle Time
Set Idle Time for Busy Interfaces
Set Line-Down Time
Set Carrier-Wait Time
Control Access to a DDR Interface
Set Dialer Interface Priority
Configure a Dialer Hold Queue
Configure Bandwidth on Demand
Disable and Reenable DDR Fast Switching
Monitor DDR Connections and Snapshot Routing
DDR Configuration Examples
Dial Backup Using the Auxiliary Port Example
Dial Backup Using DDR and ISDN Example
Configuring DDR in an IP Environment Example
Configuring Multiple Destination Dial Strings Example
Configuring Dialer Rotary Groups Example
Dialing a Single Site or Multiple Sites Example
Using Chat Scripts Example
Writing and Implementing Chat Scripts Example
Chat Scripts and Dialer Mapping Example
System Scripts and Modem Scripts Example
Dial-on-Demand PPP Configuration Example
DTR Dialing Configuration Example
Multilink PPP Examples
One ISDN Interface Configured for Multilink PPP Example
Multiple ISDN Interfaces Configured for Multilink PPP Example
PPP Callback Example
Snapshot Routing Examples
LAPB Support Configuration Example
X.25 Support Configuration Example
Frame Relay Support Examples
In-Band Dialing (V.25bis) and Static Map
ISDN Dialing and Dynamic Maps
ISDN Dialing and Subinterfaces
AppleTalk Configuration Example
Banyan VINES Configuration Example
DECnet Configuration Example
ISO CLNS Configuration Example
XNS Configuration Example
DDR for Transparent Bridging Examples
Configuring DDR
This chapter describes how to configure your router for dial-on-demand routing (DDR) and dial backup. For a complete description of the commands mentioned in this chapter, refer to the "DDR Commands" chapter in the Router Products 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 (DTR inactive) until one of the following conditions is met:
•
The primary line goes down.
•
The transmitted traffic load on the primary line exceeds a defined limit.
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 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.
The following protocols can be routed over DDR: AppleTalk, Banyan VINES, CLNS, DECnet, IP, IPX, and XNS. For more information see the appropriate protocol configuration chapters.
Synchronous and asynchronous interfaces can be configured for DDR connections to one or more destination networks. When a packet is received for a remote network, the router uses dialing commands to send the phone number of the destination network to a modem. The modem (DCE device) then dials the destination DCE device and establishes a connection.
illustrates a typical DDR interconnection configuration.
Figure 8-1 DDR Interconnection
Fast Call Rerouting for ISDN
When DDR calls using an ISDN interface are not accepted, dialer is able to place the call again or proceed to other calls almost immediately, and does not have to wait for the dialer wait-for-carrier timer to expire. The ISDN software learns within a few seconds that a call was not accepted and always informs the dialer software, thus greatly reducing delays.
This feature is automatically enabled for all ISDN interfaces when the router software begins to run.
You can still modify the dialer wait-for-carrier timer for DDR interfaces, and the show dialer command still shows the destination number, if connected.
DDR Fast Switching
In the past, only process switching was available on interfaces configured for DDR. Process switching provided an acceptable level of performance because DDR was used on low-speed lines. Now, however, fast switching is required to take advantage of ISDN PRI and multiple BRI platforms.
Fast switching is enabled by default on DDR interfaces. It is enabled for two routed protocols, IP and IPX, and for two encapsulations, HDLC and 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 router, DDR places calls using the following methods:
•
Chat scripts on the auxiliary port
•
V.25bis over synchronous interfaces
•
DTR dialing for synchronous interfaces
Chat Scripts on the Auxiliary Port
A chat script is a string of text that defines the login "conversation" that occurs between two systems. It consists of expect-send pairs that define the string that the local system expects to receive from the remote system and what the local system should send as a reply.
On asynchronous lines, our routers 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. See the "Regular Expressions" appendix in the Router Products Command Reference publication for information about regular expressions.
Note
Only the auxiliary port supports asynchronous lines.
V.25bis over Synchronous Interfaces
Our routers support connections from the synchronous serial interface to any DCE device that supports V.25bis. These devices include ISDN TAs for ISDN B-channel connections. V.25bis is an International Telecommunication Union Telecommunication Standardization Sector (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 ITU-T carries out the functions of the former Consultative Committee for International Telegraph and Telephone (CCITT).
The V.25bis specification describes two modes of establishing or receiving calls: the direct call mode and the addressed call mode. Routers 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 router for dialing out must support certain hardware signals in addition to V.25bis. When the router 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
For many V.25bis devices, raised DCD requires a special cable to crossover DCD and Data Set Ready (DSR) signals, because the V.25bis specification requires DSR to be raised when a connection is established.
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. These options are not supported in the dial string for native ISDN Basic Rate Interfaces (BRIs). The functions of these options are nation-specific, and they might have different implementations in your country. Refer to your modem or ISDN TA manual for a list of supported options.
Table 8-1 ITU-T V.25bis Options
Option
|
Description
|
:
|
Wait tone.
|
<
|
Pause.
Usage and duration of this parameter vary by country.
|
=
|
Separator 3.
For national use.
|
>
|
Separator 4.
For national use.
|
P
|
Dialing to be continued in pulse mode.
Optionally accepted parameter.
|
T
|
Tone. (Dialing to be continued in Dual Tone Multifrequency, DTMF mode).
Optionally accepted parameter.
|
&
|
Flash. (The flash duration varies by country.)
Optionally accepted parameter.
|
DTR Dialing for Synchronous Interfaces
Our routers also support connections from synchronous serial lines through non-V.25bis modems. Routers 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:
•
Dialer access lists and dialer access groups—Based on the access lists configured, access groups control access for DDR.
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."
A router 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 router 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
TCP/IP routing protocols IS-IS, BGP, and OSPF are not recommended with DDR because they require an acknowledgment for routing updates. Because DDR lines are brought up as needed, DDR will not necessarily be active and available to send responses at the times the updates are sent.
•
Address mapping—Interfaces can be configured to map a next hop address to a phone number. This allows the router to forward packets to the correct destinations and to determine if a connection is already established to that destination.
•
CHAP—Access control using Challenge Handshake Authentication Protocol (CHAP) can be configured on serial interfaces that have PPP encapsulation enabled. CHAP reduces the risk of security violations on your router. CHAP also serves a method to identify incoming calls.
Note
Access lists must be defined before you can use DDR. If there are no access lists defined, access is implicitly denied. See the "Configuring AppleTalk" chapter for information about AppleTalk static routes defined, the "Configuring IP" chapter for information about the IP access lists with the tcp keyword specified, and the "Configuring Novell IPX" chapter for information about the IPX access lists.
Dial Backup Configuration Task List
When you configure dial backup, you must first decide whether you want to back up 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 tasks in the following sections to configure dial backup:
•
Select Backup Line
•
Define the Traffic Load Threshold
•
Define Backup Line Delays
Select Backup Line
To configure dial backup, set a secondary serial interface as a backup to a primary serial interface. An external data communications equipment (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:
Task
|
Command
|
Select a backup line.
|
backup interface serial number or backup interface slot/port (For the Cisco 7000 series)
|
Note
When using a BRI with dial backup, neither of the B channels can be used while the interface is in a standby mode. In addition, when used as a backup interface, only one B channel is usable. Once the backup is initiated over one B channel, the second B channel is unavailable.
The interface specified in the backup interface command can only back up one interface. For examples of selecting a backup line, see the "Dial Backup Using the Auxiliary Port Example" and the "Dial Backup Using DDR and ISDN Example" sections later in 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:
Task
|
Command
|
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 has changed. This means that you can define two delays:
•
A delay that applies after the primary line goes down but before the secondary line is activated
•
A delay that applies after the primary line goes up but before the secondary line is activated
To define these delays, perform the following task in interface configuration mode:
Task
|
Command
|
Define backup line delays.
|
backup delay {enable-delay | never} {disable-delay | never}
|
For examples of how to define backup line delays, see the sections "Dial Backup Using the Auxiliary Port Example" and "Dial Backup Using DDR and ISDN Example" later in this chapter.
DDR Configuration Task Overview
Before you configure the asynchronous interface on the auxiliary port to support DDR, configure the line as follows:
•
Specify line speed.
•
Set flow control, if any.
•
Specify your modem type.
To configure your router for dial-on-demand routing, you must perform one of the tasks in the following sections:
•
Configure an Interface to Place Calls
•
Configure an Interface to Receive Calls
•
Configure an Interface to Place and Receive Calls
You can also optionally customize, enhance, and monitor DDR by performing the tasks in the following sections:
•
Configure Multilink PPP
•
Configure PPP Callback
•
Configure Snapshot Routing
•
Configure DDR over LAPB
•
Configure DDR over X.25
•
Configure DDR over Frame Relay
•
Configure DDR for Routed Protocols
•
Configure DDR for Transparent Bridging
•
Customize the DDR Network
•
Monitor DDR Connections and Snapshot Routing
See the "DDR Configuration Examples" section later in this chapter for examples of how to configure DDR on your network.
Configure an Interface to Place Calls
To configure a single interface, multiple interfaces, or dialer rotary groups to place calls, perform the following tasks:
Step 1
Create chat scripts (asynchronous interfaces only).
Step 2
Specify a chat script for DDR (asynchronous interfaces only).
Step 3
Configure to call a single site or multiple sites.
Step 4
Configure calling from dialer rotary groups.
The following sections describe these tasks.
Create Chat Scripts for Asynchronous Interfaces
You must define a chat script for dialing out on asynchronous lines, specifically the asynchronous interface on the auxiliary port. Chat scripts are used to send commands for modem dialing and logging on to remote systems.
To create a chat script, perform the following task in global configuration mode:
Task
|
Command
|
Create a script that will place a call on a modem and/or log on to a remote system.
|
chat-script script-name expect send
|
It is recommended that you write one chat script (a "modem" chat script) for placing a call and another one (a "system" or "login" chat script) to log onto remote systems, where required.
For an example of how to use chat scripts, see "Using Chat Scripts Example" later in this chapter.
Suggested Chat Script Naming Conventions
A suggested chat script naming convention is as follows:
vendor-type-modulation
In other words, the syntax of the chat-script command becomes the following:
chat-script vendor-type-modulation expect send...
For example, if you have a Telebit t3000 modem that uses V.32bis modulation, you would name your chat script as follows:
telebit-t3000-v32bis
The chat-script command could become the following:
Router(config)# chat-script telebit-t3000-v32bis ABORT ERROR ABORT BUSY ABORT
"NO ANSWER" "" "AT H" OK "AT DT \T" DIALING \c TIMEOUT 30 CONNECT \c
Adhering to this naming convention allows you to specify a range of chat scripts using partial chat script names with regular expressions. This is particularly useful for dialer rotary groups and is explained further in the "Configure an Interface to Receive Calls" section later in this chapter.
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:
Task
|
Command
|
Specify a modem script for a line.
|
script dialer regexp
|
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 Router Products 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.
Configure 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
Enable DDR on the interface.
Step 2
For synchronous interfaces, specify the dial string (synchronous interfaces).
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:
Task
|
Command
|
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 an Interface 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.
For ISDN interfaces, the dialer in-band command is not required. The software automatically configures these interfaces to be dialer type ISDN.
Note
For asynchronous interfaces that do not require a system script, a modem script must be defined for the associated line by using the script dialer line configuration command.
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:
Task
|
Command
|
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:
•
The modem script can be used to dial and log in to the remote system.
•
You are calling a system that does not require a login script; that is, a system that answers and immediately goes into protocol mode.
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. ISDN devices call the number specified in the string.
To specify the string (telephone number) to be called on serial interfaces (asynchronous or synchronous), perform the following task in interface configuration mode:
Task
|
Command
|
Specify the number to dial.
|
dialer string dial-string
|
Configure Calls to Multiple Sites
You can configure your router to call multiple sites from a single line, from multiple lines, or from a dialer rotary group.
Calling on a Single Line or Multiple Lines
To configure your router to call multiple sites on a single line or on multiple lines, perform the following tasks:
Step 1
Enable DDR on the interface.
Step 2
Define multiple dialing destinations on the interface, or specify a string of numbers to dial.
To enable DDR on an interface, perform the following task in interface configuration mode:
Task
|
Command
|
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:
Task
|
Command
|
Define multiple dialing destinations on a synchronous interface.
|
dialer map protocol next-hop-address dial-string[:isdn-subaddress]
|
Define multiple dialing destinations on an asynchronous interface.
|
dialer map protocol next-hop-address [modem-script modem-regexp] [system-script system-regexp] dial-string[:isdn-subaddress]
|
Specify a string of numbers to dial (to configure one phone number on multiple lines only.)
|
dialer string dial-string
|
Define multiple dialing destinations on an ISDN interface.
|
dialer map protocol [speed 56 | speed 64] next-hop-address dial-string[:isdn-subaddress]
|
Note
For ISDN interfaces only, you can specify an optional speed parameter for dialer map commands if you also specify a dial string. This option informs the ISDN software whether it should place a call at 56 or 64 kbps. If you omit the ISDN speed parameter, the default is 64 kbps.
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 period (.) is a wildcard that matches any character, and the asterisk (*) indicates that the preceding character can be duplicated multiple times. For more information about regular expressions, see the "Regular Expressions" appendix in the Router Products 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.
Calling from Dialer Rotary Groups
Perform the following steps to configure your router to place multiple calls using a dialer rotary group.
Step 1
Define a rotary group.
Step 2
Enable DDR on the rotary interface.
Step 3
Define multiple dialing destinations for the rotary group.
Step 4
Assign physical interfaces to the rotary group.
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
The dialer rotary groups discussed in this chapter are on the router. The telephone company also has rotary groups that allow you to dial one rotary phone number and get connected to one of several different phone numbers. If you are using telephone company rotary groups, it is a good idea to configure dialer rotary groups on the router.
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 up to 9 dialer interfaces. Perform the following tasks for each dialer rotary group.
To define a rotary group, perform the following task in global configuration mode:
Task
|
Command
|
Define a rotary group.
|
interface dialer number
|
To enable DDR for the dialer rotary group, perform the following task in interface configuration mode:
Task
|
Command
|
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:
Task
|
Command
|
Define multiple dialing destinations on a synchronous interface.
|
dialer map protocol next-hop-address dial-string[:isdn-subaddress]
|
Define multiple dialing destinations on an asynchronous interface.
|
dialer map protocol next-hop-address [modem-script modem-regexp] [system-script system-regexp] dial-string[:isdn-subaddress]
|
To assign a physical interface to a dialer rotary group, perform the following task in interface configuration mode:
Task
|
Command
|
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.
An ISDN BRI is a rotary group of B channels. An ISDN interface can be part of a rotary group comprising other interfaces (synchronous, asynchronous, ISDN BRI, or ISDN PRI). However, Cisco supports at most one level of recursion; that is, a rotary of rotaries is acceptable, but a rotary of rotaries of rotaries is not supported.
Note
When you look at your configuration file, commands will not appear in the order in which you entered them. You will also see interface configuration commands that you did not enter, because interfaces inherit the parameters of the dialer interface in the dialer rotary group to which each interface has been assigned.
illustrates how dialer interfaces work. In this example configuration, serial interfaces 1, 2, and 3 are assigned to dialer rotary group 1. This 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 8-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 single 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:
•
Configure an Interface to Receive Calls from a Single Site
•
Configure an Interface to Receive Calls from Multiple Sites
Note
CHAP or PAP is required for caller identification on dialer rotary groups receiving calls from multiple sites and is described later in this section. CHAP or PAP can also be used for authentication only, in which case, an accompanying dialer map command is not required.
Configure an Interface to Receive Calls from a Single Site
To configure an interface to receive a call from a single site, 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 and thus configure an interface to receive calls from a single site, perform the following task in interface configuration mode:
Task
|
Command
|
Enable DDR on a serial interface.
|
dialer in-band [no-parity | odd-parity]
|
You cannot set up an ISDN interface to receive calls from a single site.
Configure an Interface to Receive Calls from Multiple Sites
You can configure your router to receive calls from multiple sites on a single line, on multiple lines, or on a dialer rotary group.
Configure an Interface to Receive Calls on a Single Line or Multiple Lines
No special configuration is required to receive calls on individual lines.
Configure an Interface to Receive Calls on a Dialer Rotary Group
To configure your router to receive calls on a dialer rotary group, follow these steps:
Step 1
Assign a rotary group leader.
Step 2
Enable DDR on the rotary interface.
Step 3
Enable and configure CHAP or PAP authentication.
Step 4
Assign physical interfaces to dialer rotary groups.
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 you define the dialer interface by assigning it a number, you configure interface parameters for the dialer interface. Then, you assign physical interfaces 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
The dialer rotary groups discussed in this chapter are on the router. The telephone company also has rotary groups that allow you to dial one rotary phone number and get connected to one of several different phone numbers.
You can define up to nine dialer interfaces. For each dialer rotary group, perform the following task in global configuration mode:
Task
|
Command
|
Define a rotary group.
|
interface dialer number
|
Enable DDR on the Rotary Interface
To receive a call from multiple sites, you 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:
Task
|
Command
|
Enable DDR on a serial interface.
|
dialer in-band [no parity | odd parity]
|
Configure and Configure CHAP or PAP Authentication
The Point-to-Point Protocol (PPP) with Challenge Handshake Authentication Protocol (CHAP) authentication or Password Authentication Protocol (PAP) is often used to inform the central site about which remote routers are connected to it.
With this authentication information, if another packet is received for a destination to which the router is already connected, an additional call will not be placed. However, if using rotaries, the packet will be sent out the correct port.
CHAP and PAP are specified in RFC 1334. These protocols are supported on synchronous and asynchronous serial interfaces. When using CHAP or PAP authentication, each router identifies itself by a name, which informs the other router what routers are currently connected to it. This identification process prevents a router from placing a call to another router if it is already connected to that router and prevents unauthorized access. See the "Configuring Interfaces" chapter in this manual for more information about CHAP and PAP.
Note
To use CHAP or PAP, you must be running PPP encapsulation.
When CHAP is enabled, a remote device (a PC, workstation, or router) attempting to connect to the local router is requested, or challenged, to respond. The challenge consists of a random number and the host name of the local router. 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 router 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 router. 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 router.
CHAP transactions occur only at the time a link is established. The local router does not issue a challenge during the rest of the call. (The local router can, however, respond to such requests from other devices during a call.)
When PAP is enabled, the remote router attempting to connect to the local router is required to send an authentication request. If the username and password specified in the authentication request are accepted, the router sends an authentication acknowledgment.
To use CHAP or PAP, you must perform the following tasks:
Step 1
Enable PPP encapsulation.
Step 2
Enable CHAP or PAP on the interface. After you have enabled one of these protocols, the local router requires authentication from remote devices. If the remote device does not support CHAP, no traffic will be passed to that device.
Step 3
For CHAP, configure host name authentication and the secret or password for each remote system with which authentication is required.
To enable PPP encapsulation, perform the following task in interface configuration mode:
Task
|
Command
|
Enable PPP on an interface.
|
encapsulation ppp1
|
To enable CHAP or PAP on an interface configured for PPP encapsulation, perform one of the following tasks in interface configuration mode:
Task
|
Command
|
Enable CHAP on an interface.
|
ppp authentication chap [if-needed]
|
Enable PAP on an interface.
|
ppp authentication pap
|
After you have enabled CHAP or PAP, the local router requires authentication from remote devices that are calling in. If the remote device does not support the authentication protocol, no traffic will be passed to that device.
To specify the password to be used in CHAP caller identification, perform the following task in global configuration mode:
Task
|
Command
|
Configure authentication.
|
username name password secret
|
Add a username entry for each remote system from which the local router requires authentication.
The host name of each site calling in to the local router needs to be mapped to its address. To map a next hop address to a host name (case-sensitive), perform the following task in interface configuration mode:
Task
|
Command
|
Configure a serial interface to map host names to next hop addresses (for rotary groups only).
|
dialer map protocol next-hop-address name hostname
|
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:
Task
|
Command
|
Include the specified physical interface in a dialer rotary group.
|
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
Perform tasks in one of the following sections to configure an interface to place and receive calls:
•
Place and Receive Calls from a Single Site
•
Place and Receive Calls from Multiple Sites
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.
Place and Receive Calls from a Single Site
To configure your router to place calls to and receive calls from a single site, perform the following tasks in interface configuration mode:
Step 1
Enable DDR.
Step 2
Specify the phone number to dial.
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 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:
Task
|
Command
|
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:
Task
|
Command
|
Specify a string of numbers to dial.
|
dialer string dial-string[:isdn-subaddress]
|
Note
Any incoming calls are assumed to be from the dialer string.
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
Enable DDR.
Step 2
Specify a phone number to dial.
Step 3
Map next hop to host name and phone number.
To call and receive calls from multiple sites, you 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:
Task
|
Command
|
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:
Task
|
Command
|
Specify a string of numbers to dial (to configure one phone number on multiple lines only).
|
dialer string dial-string[:isdn-subaddress]
|
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:
Task
|
Command
|
Configure an interface for PPP encapsulation.
|
encapsulation ppp1
|
Enable CHAP. or Enable PAP.
|
ppp authentication chap or ppp authentication pap
|
Map the next hop to host name and phone number.
|
dialer map protocol next-hop-address [modem-script modem-regexp] [system-script system-regexp] name hostname dial-string[:isdn-subaddress]
|
See the "Create Chat Scripts for Asynchronous Interfaces" section and the "Specify Chat Scripts for DDR" section for an explanation of assigning chat scripts to an interface or dialer rotary group.
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 8-3 Hub-and-Spoke Configuration Using Dial-on-Demand Routing
Configure Multilink PPP
Multilink PPP allows packets to be fragmented and the fragments to be sent at the same time over multiple point-to-point links to the same remote address. The multiple links come up in response to a dialer load threshold that you define. The load can be calculated on inbound traffic, outbound traffic, or on either, as needed for the traffic between the specific sites.
Multilink PPP is designed to work over single or multiple interfaces of the following types that are configured to support both dial-on-demand rotary groups and PPP encapsulation:
•
Asynchronous serial interfaces
•
Basic Rate Interfaces (BRIs)
•
Primary Rate Interfaces (PRIs)
Configure Multilink PPP on Asynchronous Interfaces
To configure Multilink PPP on asynchronous interfaces, you configure the asynchronous interfaces to support DDR and PPP encapsulation, then you configure a dialer interface to support PPP encapsulation, bandwidth on demand, and Multilink PPP.
To configure an asynchronous interface to support DDR and PPP encapsulation, complete the following tasks beginning in global configuration mode:
Task
|
Command
|
Step 1 Specify an asynchronous interface.
|
interface async number
|
Step 2 Specify no IP address for the interface.
|
no ip address
|
Step 3 Enable PPP encapsulation.
|
encapsulation ppp
|
Step 4 Enable DDR on the interface.
|
dialer in-band
|
Step 5 Include the interface in a specific dialer rotary group.
|
dialer rotary-group number
|
Repeat this step for additional asynchronous interfaces, as needed.
At some point, adding more asynchronous interfaces does not improve performance, With the default MTU size, Multilink PPP should support three asynchronous interfaces using V.34 modems. However, packets might be dropped occasionally if the MTU is small or large bursts of short frames occur.
To configure a dialer interface to support PPP encapsulation and Multilink PPP, complete the following tasks beginning in global configuration mode:
Task
|
Command
|
Step 1 Define a dialer rotary group.
|
interface dialer number
|
Step 2 Specify no IP address for the interface.
|
no ip address
|
Step 3 Enable PPP encapsulation.
|
encapsulation ppp
|
Step 4 Enable DDR on the interface.
|
dialer in-band
|
Step 5 Configure bandwidth on demand by specifying the maximum load before the dialer places another call to a destination.
|
dialer load-threshold load [inbound | outbound | either]
|
Step 6 Enable Multilink PPP.
|
ppp multilink
|
Configure Multilink PPP on a Single ISDN BRI Interface
To enable multilink PPP on a single Integrated Services Digital Network (ISDN) BRI interface, you are not required to define a dialer rotary group separately because ISDN interfaces are dialer rotary groups by default. To enable PPP on an ISDN BRI interface, perform the following tasks beginning in global configuration mode:
Task
|
Command
|
Step 1 Specify an ISDN interface.
|
interface BRI number
|
Step 2 Provide an appropriate protocol address for the interface.
|
ip address ip-address mask
|
Step 3 Enable PPP encapsulation.
|
encapsulation ppp
|
Step 4 Specify a dialer idle timeout.
|
dialer idle-timeout seconds
|
Step 5 Specify the dialer load threshold for bringing up additional WAN links.
|
dialer load-threshold load [either | outbound | inbound]
|
Step 6 Configure the ISDN interface to call the remote site.
|
dialer map protocol next-hop-address [name hostname] [spc] [speed 56 | 64] [broadcast] [dial-string[:isdn-subaddress]]
|
Step 7 Add the interface to a dialer rotary group.
|
dialer-group number
|
Step 8 Enable PPP authentication. or Configure ISDN calling line identification.
|
ppp authentication pap or isdn caller number
|
Step 9 Enable multilink PPP on the dialer rotary group.
|
ppp multilink
|
If you do not use PPP authentication procedures (Step 8), your telephone service must pass caller ID information.
Configure Multilink PPP on Multiple ISDN BRI Interfaces
To enable multilink PPP on multiple ISDN BRI interfaces, you configure the BRIs separately and add them each to the same rotary group. Then you set up a the dialer rotary interface and configure it for multilink PPP.
To configure each of the BRIs to belong to the same rotary group, perform the following tasks beginning in global configuration mode:
Task
|
Command
|
Step 1 Specify one of the BRI interfaces.
|
interface BRI number
|
Step 2 Specify that it does not have an individual protocol address.
|
no ip address
|
Step 3 Enable PPP encapsulation.
|
encapsulation ppp
|
Step 4 Disable keepalives.
|
no keepalive
|
Step 5 Set the dialer idle timeout period, using the same timeout for each of the BRI interfaces you configure.
|
dialer idle-timeout seconds
|
Step 6 Add the interface to the rotary group.
|
dialer rotary-group number
|
Step 7 Specify the dialer load threshold for bringing up additional WAN links.
|
dialer load-threshold load [either | outbound | inbound]
|
Repeat Steps 1 through 7, above, for each BRI you want to belong to the same dialer rotary group.
To set up the dialer rotary interface for the BRI interfaces, perform the following tasks beginning in global configuration mode:
Task
|
Command
|
Step 1 Specify the dialer rotary interface.
|
interface dialer number
|
Step 2 Specify the protocol address for the dialer rotary interface.
|
ip address address mask
|
Step 3 Enable PPP encapsulation.
|
encapsulation ppp
|
Step 4 Disable keepalives.
|
no keepalive
|
Step 5 Specify in-band dialing.
|
dialer in-band
|
Step 6 Specify the dialer idle timeout period, using the same timeout period as the individual BRI interfaces.
|
dialer idle-timeout seconds
|
Step 7 Map the next-hop protocol address and name to the dial string needed to reach it.
|
dialer map protocol next-hop-address [name hostname] [spc] [speed 56 | 64] [broadcast] [dial-string[:isdn-subaddress]]
|
Step 8 Specify the dialer load threshold, using the same threshold as the individual BRI interfaces.
|
dialer load-threshold load [either | outbound | inbound]
|
Step 9 Control access to this interface by adding it to a dialer access group.
|
dialer-group number
|
Step 10 Enable PPP Challenge Handshake Authentication Protocol (CHAP) authentication. or Configure caller ID screening.
|
ppp authentication chap
or isdn caller number
|
Step 11 Enable multilink PPP |