|
|
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.
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 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.
Figure 7-1 illustrates a typical DDR interconnection configuration.
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.
On the access server, DDR places calls using the following two methods:
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.
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.
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.
Table 7-1 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.
| 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. |
Our access servers support connections over serial lines connected by non-V.25bis modems, using EIA signaling (DTR) only.
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.
DDR supports a variety of security and access control methods including the following:
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:
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:
| Task | Command |
|---|---|
| Select a backup line. | backup interface type number |
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.
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} |
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:
| Task | Command |
|---|---|
| Define backup line delays. | backup delay {enable-delay | never} {disable-delay | never} |
For an example of how to define backup line delays, see "Dial Backup Example" at the end of this chapter.
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.
The following tasks are required to configure a single interface, multiple interfaces, or dialer rotary groups to place calls:
Step 1 Create chat scripts (for asynchronous interfaces only; refer to "Configure Chat Scripts for Asynchronous Lines" in the chapter "Configuring Terminal Lines and Modem Support").
Step 2 Specify a chat script for a line (asynchronous).
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.
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 "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.
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 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.
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.
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 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.
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:
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:
| Task | Command |
|---|---|
| Specify a string of numbers to dial. | dialer string dial-string |
You can configure your access server to call multiple sites from a single line, from multiple lines, or from a dialer rotary group.
To configure your access server 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, 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.
To configure your access server to place multiple calls using a dialer rotary group, perform the following tasks:
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.
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:
| 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, as appropriate:
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.
Figure 7-2 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.
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:
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:
| Task | Command |
|---|---|
| Enable DDR on a serial interface. | dialer in-band [no-parity | odd-parity] |
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.
No special configuration is required to receive calls on individual lines.
The following steps describe how to configure your access server to receive calls on a dialer rotary group:
Step 1 Assign a Rotary Group Leader
Step 2 Enable DDR
Step 3 Configure Challenge Handshake Authentication Protocol (CHAP) or Enable PAP
Step 4 Assign an Interface to a Dialer 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.
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 0 to as many as 9 dialer interfaces. For each dialer rotary group, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Define a rotary group. | interface dialer number |
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:
| Task | Command |
|---|---|
| Enable DDR on a serial interface. | dialer in-band [no parity | odd parity] |
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.
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:
| Task | Command |
|---|---|
| Enable PPP on an interface. | encapsulation ppp |
To enable CHAP on an interface configured for PPP encapsulation, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| 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:
| Task | Command |
|---|---|
| Configure host authentication. | username name password password |
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:
| Task | Command |
|---|---|
| Configure TACACS. | ppp use-tacacs [single-line] or aaa authentication ppp |
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:
| 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 |
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:
| Task | Command |
|---|---|
| Enable PAP on the interface. | ppp authentication pap [if-needed] or ppp authentication pap [list-name]1 |
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:
| Task | Command |
|---|---|
| Configure host authentication. | username name password secret |
To configure TACACS as an alternative to host authentication, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Configure TACACS. | ppp use-tacacs [single-line] or aaa authentication ppp |
Use the ppp use-tacacs command with TACACS or Extended TACACS. Use the aaa authentication ppp command with AAA/TACACS+.
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.
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:
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 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 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:
| 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 |
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 Configure PPP encapsulation and enable CHAP.
Step 4 Map next hop to host name and phone number.
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:
| 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 |
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 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 |
Figure 7-3 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.
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.
To configure a router interface as a callback client, complete the following tasks beginning in global configuration mode:
| Task | Command |
|---|---|
| Step 1 Specify the interface. | interface serial number |
| Step 2 Enable DDR. Set parity on synchronous serial interfaces only. | dialer in-band [no-parity | odd-parity] |
| Step 3 Enable PPP encapsulation. | encapsulation ppp |
| Step 4 Enable CHAP or Password Authentication Protocol (PAP) authentication. | ppp authentication chap or ppp authentication pap |
| Step 5 Map the next hop address to the host name and phone number, using the name of the map-class established for PPP callback on this interface. | dialer map protocol address name hostname class classname dialstring |
| Step 6 Enable the interface to request PPP callback for this callback map class. | ppp callback request |
| Step 7 Configure a dialer hold-queue to store packets for this callback map class. | dialer hold-queue packets timeout seconds |
To configure a router as a callback server, complete the following tasks beginning in global configuration mode:
| Task | Command |
|---|---|
| Step 1 Specify the interface and enter interface configuration mode. | interface serial number |
| Step 2 Enable DDR. Set parity on synchronous serial interfaces only. | dialer in-band [no-parity | odd-parity] |
| Step 3 Enable PPP encapsulation. | encapsulation ppp |
| Step 4 Enable CHAP or PAP authentication. | ppp authentication {chap | pap} |
| Step 5 Map the next hop address to the host name and phone number, using the name of the map-class established for PPP callback on this interface. | dialer map protocol address name hostname class classname dialstring |
| Step 6 Configure a dialer hold queue to store packets to be transferred when the callback connection is established. | dialer hold-queue number timeout seconds |
| Step 7 Configure a dialer enable timeout (for ISDN interfaces).1 | dialer enable-timeout seconds |
| Step 8 Configure the interface to accept PPP callback. | ppp callback accept |
| Step 9 Enable callback security, if desired. (Optional) | dialer callback-secure |
| Step 10 Return to global configuration mode. | exit |
| Step 11 Configure a dialer map class for PPP callback. | map-class dialer classname |
| Step 12 Specify whether the dialstring to call is to be identified by looking up the authenticated hostname or is determined during callback negotiation. | dialer callback-server [username] [dialstring] |
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.
interface serial0 ip address 7.1.1.7 255.255.255.0 encapsulation ppp dialer callback-secure dialer enable-timeout 2 dialer map ip 7.1.1.8 name atlanta class dial1 81012345678901 dialer-group 1 ppp callback accept ppp authentication chap ! map-class dialer dial1 dialer callback-server username
interface serial0 ip address 7.1.1.8 255.255.255.0 encapsulation ppp dialer map ip 7.1.1.7 name dallas 81012345678902 dialer-group 1 ppp callback request ppp authentication chap
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.
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.
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:
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:
| Task | Command |
|---|---|
| Step 1 Specify a serial interface. | interface serial number |
| Step 2 Configure the client router. | 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:
Repeat Step 5 for each map you want to define.
To configure snapshot routing on the server router that is connected to a dedicated serial line, perform the following steps starting in global configuration mode:
| Task | Command |
|---|---|
| Step 1 Specify a serial interface. | interface serial number |
| Step 2 Configure the server router. | snapshot server active-time [dialer] |
The active period for the client router and its associated server routers should be the same.
For an example of configuring the snapshot client and server routers, see the "Snapshot Routing Examples" section later in this chapter.
To monitor and maintain snapshot routing, perform one or both of the following tasks in EXEC mode:
| Task | Command |
|---|---|
| Terminate the quiet period on the client router within two minutes. | clear snapshot quiet-time interface |
| Display information about snapshot routing parameters. | show snapshot interface |
Dial-on-demand routing over serial lines now supports LAPB encapsulation, in addition to the previously supported PPP and X.25 encapsulations.
LAPB encapsulation is supported on synchronous serial and dialer rotary group interfaces, but not on asynchronous dialers.
Because the default encapsulation is HDLC, you must explicitly configure LAPB encapsulation. To configure an interface to support LAPB encapsulation, perform the following task in interface configuration mode and also complete the DDR configuration of the interface:
| Task | Command |
|---|---|
| Specify LAPB encapsulation. | encapsulation lapb [dte | dce] [multi | protocol]1 |
For more information about the serial connections on which LAPB encapsulation is appropriate, see the encapsulation lapb command in the "X.25 and LAPB Commands" chapter of the Access and Communication Servers Command Reference publication.
For an example of configuring an interface for DDR over LAPB, see the "LAPB Support Configuration Example" section later in this chapter.
Our access servers support PPP serial encapsulation and X.25 encapsulation on synchronous serial interfaces. X.25 encapsulation is available for in-band and DTR dialers, but dialer group leaders cannot be configured for X.25 encapsulation.
To configure an interface for X.25 encapsulation, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Configure the interface to use X.25 encapsulation. | encapsulation x25 [dte | dce] [ddn | bfe] [ietf] |
For an example of configuring an interface for X.25 encapsulation, see the section "X.25 Encapsulation Example."
Access to Frame Relay networks is now available through dial-up connections as well as leased lines. Dial-up connectivity allows Frame Relay networks to be extended to sites that do not generate enough traffic to justify leased lines and also allows a Frame Relay network to back up another network or point-to-point line.
DDR over Frame Relay is supported for synchronous serial interfaces and for rotary groups, and is available for in-band and DTR dialers.
Frame Relay supports multiple connections (PVCs) over the same serial interface B-channel, but only one physical interface can be used (dialed, connected, and active) in a rotary group.
The following restrictions apply to DDR over Frame Relay:
No new commands are required to support DDR over Frame Relay. In general, you configure Frame Relay and configure DDR. In general, complete the following steps to configure an interface for DDR over Frame Relay:
For examples of configuring various interfaces for DDR over Frame Relay, see the "Configure DDR over Frame Relay" section of this chapter.
DDR supports the following routed protocols: AppleTalk, IP, and Novell IPX.
To configure DDR for a routed protocol, perform the tasks in the relevant section:
To configure DDR for AppleTalk, you specify AppleTalk access lists and then define DDR dialer lists. Use the dialer-list protocol command to define permit or deny conditions for the entire protocol; for a finer granularity, use the dialer-list protocol command with the list keyword.
See the "Controlling Access to a DDR Interface" section for more information about defining dialer lists. For an example of configuring DDR for AppleTalk, see the "AppleTalk Configuration Example" section.
To configure DDR for IP, perform one of the following tasks in global configuration mode:
| Task | Command |
|---|---|
| Specify an IP standard access list. or Specify an IP extended access list. | access-list access-list-number {deny | permit} source [source-mask] access-list access-list-number {deny | permit} protocol source source-mask destination destination-mask [operator operand]1 |
You can now also use simplified IP access lists that use the abbreviation any instead of the numeric forms of source and destination addresses and masks. Other forms of IP access lists are also available. For more information, see the "IP Commands" chapter of the Access and Communication Servers Command Reference publication.
To use dynamic routing where multiple remote sites communicate with each other through a central site, you might need to disable the IP split horizon feature. See the "Configuring IP Routing Protocols" chapter for more information.
For an example of configuring DDR for IP, see the "Configure DDR for IP" section.
On DDR links for Novell IPX, the link may come up often even when all client sessions are idle because the server sends watchdog/keepalive packets to all the clients approximately every five minutes. A local access server with the DDR link can be configured to idle out the link and still make the server believe the clients are active by responding to the watchdog packets on behalf of the clients. To do so, perform the following tasks in interface configuration mode:
Step 1 Enable DDR.
Step 2 Disable IPX fast switching.
Step 3 Enable either IPX watchdog spoofing or SPX keepalive spoofing.
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. | dialer in-band [no parity | odd-parity] |
You must also disable IPX fast switching. To disable fast switching, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Disable fast switching for IPX. | no ipx route-cache1 |
After enabling DDR and disabling IPX fast switching for the interface, you can enable either IPX watchdog spoofing or SPX keepalive spoofing.
To enable IPX watchdog spoofing, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Enable IPX watchdog spoofing.
or Enable SPX watchdog spoofing. | ipx watchdog-spoof1
|
To enable SPX keepalive spoofing, perform the following tasks in interface configuration mode:
| Task | Command |
|---|---|
| Enable SPX keepalive spoofing. | ipx spx-spoof1 |
| Set the idle time after which spoofing begins. | ipx spx-idle-time delay-in-seconds1. |
For a detailed DDR for IPX configuration example, see the "IPX over DDR Example" section in the "Configuring Novell IPX" chapter.
Perform the following tasks, as necessary, to customize DDR in your network:
To specify the amount of time a line will stay idle before it is disconnected, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Set line idle time. | dialer idle-timeout seconds |
The fast idle timer is activated if there is contention for a line. In other words, if a line is in use and a packet for a different next hop address is received, and the busy line is required to send the competing packet, the dialer fast idle timer is activated.
If the line has been idle for the configured amount of time, the current call is disconnected immediately and the new call is placed.
If the line has not yet been idle as long as the fast idle timer, the packet is dropped because there is no way to get through to the destination. (After the packet is dropped, the fast idle timer remains active and the current call is disconnected as soon as it has been idle for as long as the fast idle timeout.
If, in the meantime, there is another packet transmitted to the currently connected destination, and it is classified as interesting, the fast idle timer will be restarted.
Specify the amount of time a line for which there is contention will stay idle before the line is disconnected and the competing call is placed. Perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Set idle time for high traffic lines. | dialer fast-idle seconds |
This task applies to inbound and outbound calls.
To set the length of time an interface stays down before it is available to dial again after a line is disconnected or fails, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Set the interface downtime. | dialer enable-timeout seconds |
This task applies to inbound and outbound calls.
To set how long to wait for the telephone service (carrier), perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Set how long to wait for the carrier to come up when a call is placed. | dialer wait-for-carrier-time seconds |
For asynchronous interfaces, this task sets the total time to wait for a call to connect. This time is set to allow for running the chat script.
Access lists are central to the operation of DDR. In general, access lists are used as the screening criteria for determining when to initiate DDR calls. All packets are tested against the dialer access list. Packets that match a permit entry are deemed interesting or packets of interest. Packets that do not match a permit entry or that do match a deny entry are deemed uninteresting. When a packet is found to be interesting, either the idle timer is reset (if the line is active) or a connection is attempted (assuming the line is available but not active). If a tested packet is deemed uninteresting, it will be forwarded if it is intended for a destination known to be on a specific interface and the link is active. However, such a packet will not initiate a DDR call and will not reset the idle timer.
Before you perform the tasks outlined in this section, see the "Configuring IP" chapter in this publication for information about defining IP access lists, and see the "Configuring Novell IPX" chapter for information about defining IPX access lists. Define access lists if you want to control access on DDR interfaces by access lists rather than protocols.
Step 1 Associate a protocol or access list with the dialer access group.
Step 2 Set a dialer access group number.
You can permit or deny access to an entire protocol or you can specify an access list for more refined control. Perform one of the following tasks in global configuration mode:
For the dialer-list protocol list command form, acceptable access list numbers are Banyan VINES, DECnet, IP, and XNS standard and extended access list numbers; Novell IPX standard, extended, and SAP access list numbers; AppleTalk access lists numbers; and bridge type codes. Packets matching permit conditions are deemed interesting. Packets matching deny conditions or not matching any dialer list statements are deemed uninteresting.
An interface can be associated only with a single dialer access group; multiple dialer access group assignments are not allowed. To specify the dialer access group to which you want to assign an access list, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Specify the number of the dialer access group to which the specific interface belongs. | dialer-group group-number |
You can assign dialer priority to an interface. Priority indicates which interface in a dialer rotary group will get used first. Perform the following task in interface configuration mode.
| Task | Command |
|---|---|
| Specify which dialer interfaces will be used first. | dialer priority number
|
For example, you might give one interface in a dialer rotary group higher priority than another if it is attached to a faster, more reliable modem. In this way, the higher-priority interface will be used as often as possible.
The range of values for number is 0 through 255. Zero is the default value and lowest priority; 255 is the highest priority. This command applies to outgoing calls only.
Sometimes packets destined for a remote router are discarded because no connection exists. Establishing a connection using an analog modem can take time, during which packets are discarded. However, configuring a dialer hold queue will allow "interesting" outgoing packets to be queued and sent as soon as the modem connection is established.
A dialer hold queue can be configured on any type of dialer, including in-band synchronous, asynchronous, DTR, and ISDN dialers. Also, rotary groups can be configured with a dialer hold queue. If a rotary group of a dialer interface is configured with a hold queue, all members of the group will be configured with a dialer hold queue and no individual member's hold queue can be altered.
To establish a dialer hold queue, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Create a dialer hold queue and specify the number of packets to be held in it. | dialer hold-queue packets |
As many as 100 packets can be held in an outgoing dialer hold queue.
You can configure a dialer rotary group to place additional calls to a single destination if the load for the interface exceeds a specified weighted value. Parallel access server links are established based on traffic load. The number of parallel links that can be established to one location is not limited.
| Task | Command |
|---|---|
| Configure the dialer rotary group to place additional calls to a single destination, as indicated by interface load. | dialer load-threshold load
|
Fast switching is enabled by default on all DDR interfaces. When fast switching is enabled or disabled on an ISDN D-channel, it is enabled or disabled on all B-channels. When fast switching is enabled or disabled on a dialer interface, it is enabled or disabled on all rotary group members but cannot be enabled or disabled on serial interfaces individually.
Fast switching can be disabled and reenabled on a protocol-by-protocol basis. To disable fast switching and reenable it, complete one of the following protocol-specific tasks:
| Task | Command |
|---|---|
| Disable IP fast switching over a DDR interface. | no ip route-cache
ip route cache |
| Disable IPX fast switching over a DDR interface. | no ipx route-cache
ipx route-cache |
To monitor DDR connections and snapshot routing, perform the following tasks in privileged EXEC mode:
The examples provided in this section show various DDR configurations as follows:
The following is an example of dial backup on interface async 1:
interface serial 0 ip address 172.30.3.4 255.255.255.0 backup interface async1 backup delay 10 10 ! interface async 1 ip address 172.30.3.5 255.255.255.0 dialer in-band dialer string 5551212 dialer-group 1 async dynamic routing ! dialer-list 1 protocol ip permit ! chat-script sillyman "" "atdt 5551212" TIMEOUT 60 "CONNECT" ! line 1 modem chat-script sillyman modem inout speed 9600
In the following example, CS A and CS B are connected to a PSTN network.
CS A is configured for DTR dialing.
interface serial 0 ip address 172.30.170.19 255.255.255.0 dialer dtr dialer-group 1 ! access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 ! dialer-list 1 list 101
Remote CS B is configured for in-band dialing so it can disconnect an idle call.
interface serial 0 ip address 172.30.170.20 255.255.255.0 dialer in-band dialer string cs A pulse-time 1 ! access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 ! dialer-list 1 list 101
The following example illustrates how DDR can be used on an asynchronous interface in an IP environment. The same configuration could be used on an asynchronous serial interface by changing "interface serial 1" to specify an asynchronous interface (for example, "interface async 0").
interface serial 1 ip address 172.30.126.1 255.255.255.0 dialer in-band ! The next command sets the dialer idle time-out to 10 minutes dialer idle-timeout 600 ! The next command inserts the phone number dialer string 555-1234 ! The next command gives the modem enough time to recognize that ! DTR has dropped so the modem disconnects the call pulse-time 1 ! The next command adds this interface to the dialer access group defined with ! the dialer-list command dialer-group 1 ! ! The first access list statement, below, specifies that IGRP updates are not ! interesting packets. The second access-list statement specifies that all ! other IP traffic such as Ping, Telnet, or any other IP packet are interesting ! packets. The dialer-list command then creates dialer access group 1 and ! states that access list 101 is to be used to classify packets as interesting ! or uninteresting. The ip route commands ! specify that there is a route to network 131.108.29.0 and to network ! 131.108.1.0 via 131.108.126.2. This means that several destination networks ! are available through an access server that is dialed from interface async 1. ! access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 dialer-list 1 list 101 ip route 172.30.29.0 131.108.126.2 ip route 172.30.1.0 131.108.126.2
With many modems, the pulse-time command must be used so that DTR is dropped for sufficient time to allow the modem to disconnect.
The redistribute static command can be used to advertise static route information for DDR applications. See the redistribute static ip command, described in the "IP Commands" chapter in the Access and Communication Servers Command Reference publication. Without this command, static routes to the hosts or network that the access server can access with DDR will not be advertised to other access servers with which the access server is communicating. This can block communication because some routes will not be known.
The following example illustrates how DDR can be in an IPX environment to allow the local access server with the DDR link to idle out the link and still make the server believe the clients are active by responding to the watchdog packets on behalf of the clients. The same configuration could be used on an asynchronous serial interface by changing "interface serial 1" to specify an asynchronous interface (for example, "interface async 0").
bottomright(config)#interface serial 1bottomright(config-if)#dialer in-bandbottomright(config)#no ipx route cachebottomright(config-if)#ipx watchdog-spoof
The following example demonstrates how to specify multiple destination dial strings (phone numbers):
interface serial 1 ip address 172.30.126.1 255.255.255.0 dialer in-band dialer wait-for-carrier-time 100 pulse-time 1 dialer-group 1 dialer map ip 172.30.126.10 555-8899 dialer map ip 172.30.126.15 555-5555 ! access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 dialer-list 1 LIST 101
A pulse time is assigned, and a dialer access group is specified.
The first dialer map command specifies that the number 555-8899 is to be dialed for IP packets with a next-hop-address of 172.30.126.10. The second dialer map then specifies that the number 555-5555 will be called when an IP packet with a next-hop-address of 172.30.126.15 is detected.
The following configuration places interfaces serial 1 and 2 into dialer rotary group 1, defined by the interface dialer 1 command.
! PPP encapsulation is enabled for interface dialer 1.
interface dialer 1
encapsulation ppp
dialer in-band
ip address 172.30.2.1 255.255.255.0
ip address 172.30.2.1 255.255.255.0 secondary
! The first dialer map command allows remote site YYY and the
! central site to call each other. The second dialer map command, with no
! dialer string, allows remote site ZZZ to call the central site but
! the central site can not call remote site ZZZ (no phone number).
dialer map ip 172.30.2.5 name YYY 14155553434
dialer map ip 172.30.2.55 name ZZZ
! The DTR pulse signals for three seconds on the interfaces in dialer
! group 1. This holds the DTR low so the modem can recognize that DTR has been
! dropped.
pulse-time 3
! Interfaces serial 1 and 2 are placed in dialer rotary group 1. All of
! the interface configuration commands (the encapsulation and dialer map commands shown
! earlier in this example) applied to interface dialer 1 apply
! to these interfaces.
interface serial 1
dialer rotary-group 1
interface serial 2
dialer rotary-group 1
Assume your configuration is as shown in Figure 7-7 and your access server receives a packet with a next hop address of 1.1.1.1:
If the interface on your access server is configured to call a single site with phone number 5555555, it will send the packet to that site, assuming that the next hop address 1.1.1.1 indicates the same remote device as phone number 5555555. The dialer string command is used to specify the string (telephone number) to be called.
interface serial 1 dialer in-band dialer string 5555555
If the interface is configured to dial multiple sites, the interface or dialer rotary group must be configured so that the correct phone number, 5555555, is mapped to the address 1.1.1.1. If this mapping is not configured, the interface or dialer rotary group would not know what phone number to call to deliver the packet to its correct destination, which is the address 1.1.1.1. In this way, a packet with a destination of 2.2.2.2 will not be sent to 5555555. The dialer map command is used to map next hop addresses to phone numbers.
interface serial 1 dialer in-band dialer map ip 1.1.1.1 5555555 dialer map ip 2.2.2.2 6666666
In the following example, an access server is configured for X.25 encapsulation and DTR dialing:
interface serial 0 ip address 172.30.170.19 255.255.255.0 encapsulation x25 x25 address 12345 x25 map ip 172.30.171.20 67890 broadcast dialer dtr dialer-group 1 ! access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 ! dialer-list 1 list 101
Figure 7-8 shows the following configuration:
chat-script dial ABORT ERROR "" "AT Z" OK "ATDT \T" TIMEOUT 30 CONNECT \c chat-script login ABORT invalid TIMEOUT 15 name: billw word: wewpass ">" "slip default" interface async 10 dialer in-band dialer map ip 10.55.0.1 modem-script dial system-script login 96837890
In the following chat script example, quotation marks (" ") mean expect anything and \r means send a return.
" " \r "name:" "myname" "ord":" "mypassword" ">" "slip default"
The following example shows a configuration in which, when there is traffic, a random line will be used. The dialer code will try to find a script that matches both the modem script ".*-v32" and the system script "cisco." If there is no match for both the modem script and the system script, you will see a "no matching chat script found" message.
interface dialer 1 ! v.32 rotaries are in rotary 1 dialer rotary-group 1 ! Use v.32 generic script dialer map ip 1.0.0.1 modem-script .*-v32 system-script cisco 1234
The following example shows line chat scripts being specified for lines connected to Telebit and
US Robotics modems:
! Some lines have telebit modems line 1 6 modem chat-script telebit.* ! Some lines have US robotics modems line 7 12 modem chat-script usr.*
The following example shows a dialing chat script and a login chat script. The dialer in-band command enables DDR on asynchronous interface 10 and the dialer map command dials 96837890 after finding the specified dialing and the login scripts.
chat-script dial ABORT ERROR "" "AT Z" OK "ATDT \T" TIMEOUT 30 CONNECT \c
chat-script login ABORT invalid TIMEOUT 15 name: billw word: wewpass ">"
"slip default"
interface async 10
dialer in-band
dialer map ip 172.30.0.1 modem-script dial system-script login 96837890
When a packet is received for 172.30.0.1, the first thing that happens is that the modem script is implemented. Table 7-2 shows the functions that are implemented with each expect-send pair in the modem script called "dial."
| Expect and Send Pairs | Execution |
|---|---|
| ABORT ERROR | End the script execution if the text "ERROR" is found. You can have as many active abort entries as you like. |
| " " "AT Z" | Without expecting anything, send an "AT Z" command to the modem. Note the use of quotes to allow a space in the send string. |
| OK "ATDT \T" | Wait to see "OK." Send "ATDT 96837890." |
| TIMEOUT 30 | Wait up to 30 seconds for next expect string. |
| CONNECT \c | Expect "connect," but do not send anything. Note that \c is effectively nothing. Double quotation marks ("") would have been nothing followed by a carriage return. |
After the modem script is successfully executed, the login script is executed. Table 7-3 shows the functions that are executed with each expect-send pair in the system script "login."
| Expect and Send Pairs | Implementation |
|---|---|
| ABORT invalid | End the script execution if the message "invalid username or password" is displayed. |
| TIMEOUT 15 | Wait up to 15 seconds. |
| name: billw | Look for "name:" and send "billw." Using just "name:" will help avoid any capitalization issues. |
| word: wewpass | Wait for "word:" and send the password. |
| ">" "slip default" | Wait for the router prompt, and then put the line into slip mode with its default address. |
The following example shows the use of chat scripts, implemented with the system-script and modem-script options of the dialer map command.
If there is traffic for IP address 172.30.3.4, the access server will dial the 91800 number using the usrobotics-v32 script, matching the regular expression in the modem chat script. Then the access server will run the unix-slip chat script as the system script to log in.
If there is traffic for 172.30.2.1, the access server will dial 8899 using usrobotics-v32, matching both the modem script and modem chat script regular expressions. The access server will then log in using the cisco-compressed script.
! script for dialing a usr v.32 modem:
chat-script usrobotics-v32 ABORT ERROR "" "AT Z" OK "ATDT \T" TIMEOUT 30
CONNECT \c
!
! Script for logging into a unix system and starting up slip:
chat-script unix-slip ABORT invalid TIMEOUT 15 name: billw word: wewpass ">"
"slip default"
! Script for logging into a cisco comm server and starting up TCP header
! compression
chat-script cisco-compressed...
!
Line 15
modem chat-script usrobotics-*
!
Interface async 15
dialer map ip 172.30.3.4 system-script unix-slip 918005551212
dialer map ip 172.30.2.1 modem-script *-v32 system-script cisco-compressed 8899
The following example shows a configuration in which several aspects of DDR are used to provide DDR capabilities between local and remote access servers. The following features are shown in this example:
See the "Interface Configuration Commands," in the Access and Communication Servers Command Reference publication for a description of the pulse-time command.)
! Enable PPP encapsulation and CHAP on interface dialer 1.
interface dialer 1
ip address 172.30.2.1 255.255.255.0
ip address 172.304.1 255.255.255.0 secondary
encapsulation ppp
ppp authentication chap
! Specify dial-on-demand routing supported on a line and
! assign a set of access-list expressions.
dialer in-band
dialer group 1
! The first dialer map command indicates that calls between the remote site
! YYY and the central site will be placed at either end. The second dialer
! map command, with no dialer string, indicates that remote site ZZZ will call
! the central site but the central site will not call out.
dialer map ip 172.30.2.5 name YYY 14155553434
dialer map ip 172.30.4.5 name ZZZ
! The DTR pulse holds the DTR low for three seconds, so the modem can recognize
! that DTR has been dropped.
pulse-time 3
! Place asynchronous serial interfaces 1 and 2 in dialer rotary group 1. The
! interface subcommands applied to dialer rotary group 1 (for example,
! PPP encapsulation and CHAP) apply to these interfaces.
interface async 1
dialer rotary-group 1
interface async 2
dialer rotary-group 1
! CHAP passwords are specified for remote servers.
username YYY password theirsystem
username ZZZ password thatsystem
Figure 7-9 shows a configuration in which remote access servers YYY and ZZZ and local access server XXX are using dial-on-demand routing, as configured in the previous example. In this configuration, remote access servers YYY and ZZZ can call access server XXX. Access server XXX has dialer string information only for access server YYY and cannot call access server ZZZ.
In the example shown in Figure 7-10, Router A and Router B (or Access Servers with router functionality) are connected to a public switched telephone network (PSTN). Router A is configured for DTR dialing. Remote Router B is configured for in-band dialing so it can disconnect an idle call.
interface serial 0 ip address 172.30.170.19 255.255.255.0 dialer dtr dialer-group 1 ! access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 ! dialer-list 1 list 101
interface serial 0 ip address 172.30.170.20 255.255.255.0 dialer in-band dialer string 9876543 pulse-time 1 ! access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 ! dialer-list 1 list 101
The following example configures snapshot routing on a DDR interface on the client router. In this configuration, a single client router can call multiple server routers. It dials to all different locations during each active period to get routes from all those remote locations.
The absence of the suppress-statechange-updates keyword means that routing updates will be exchanged each time the line protocol goes from "down" to "up" or from "dialer spoofing" to "fully up." The dialer keyword on the snapshot client command allows the client router to dial the server router in the absence of regular traffic if the active period time expires.
interface serial 0 dialer rotary-group 3 ! interface dialer 3 dialer in-band snapshot client 5 360 dialer snapshot retry-interval 5 dialer map snapshot 2 4155556734 dialer map snapshot 3 7075558990
The following commands configure the server router:
interface serial 2 snapshot server 5 dialer
The examples in this section present various combinations of interfaces, Frame Relay features, and DDR features.
In this example, a router is configured for IP over Frame Relay using in-band dialing. A Frame Relay static map is used to associate the next-hop protocol address to the DLCI. The dialer string allows dialing to only one destination.
interface Serial0 ip address 172.30.1.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 1.1.1.2 100 broadcast dialer in-band dialer string 4155551212 dialer-group 1 ! access-list 101 deny igrp any host 255.255.255.255 access-list 101 permit ip any any ! dialer-list 1 protocol ip list 101
In the following example, the router is configured for LAPB encapsulation and in-band dialing:
interface serial 0 ip address 172.30.170.19 255.255.255.0 encapsulation lapb dialer in-band dialer string 4155551212 dialer-group 1 ! access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 ! dialer-list 1 protocol ip list 101
In the following example, a router is configured to support X.25 and DTR dialing:
interface serial 0 ip address 172.30.170.19 255.255.255.0 encapsulation x25 x25 address 12345 x25 map ip 172.30.171.20 67890 broadcast dialer dtr dialer-group 1 ! access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 ! dialer-list 1 list 101
In the following example, DDR is configured for AppleTalk access using an ISDN BRI. Two access lists are defined: one for IP and IGRP, and one for AppleTalk. AppleTalk packets from network 2141 only (except broadcast packets) can initiate calls.
interface BRI0 ip address 172.30.20.107 255.255.255.0 encapsulation ppp appletalk cable-range 2141-2141 2141.65 appletalk zone SCruz-Eng no appletalk send-rtmps dialer map ip 172.30.20.106 broadcast 1879 dialer map appletalk 2141.66 broadcast 1879 dialer-group 1 ! access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 access-list 601 permit cable-range 2141-2141 broadcast-deny access-list 601 deny other-access ! dialer-list 1 list 101 dialer-list 1 list 601
The examples in this section present various combinations of interfaces, Frame Relay features, and DDR features.
In the following example, an access server is configured for IP over Frame Relay using in-band dialing. A Frame Relay static map is used to associate the next-hop protocol address to the DLCI. The dialer string allows dialing to only one destination.
interface Serial0 ip address 1.1.1.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 1.1.1.2 100 broadcast dialer in-band dialer string 4155551212 dialer-group 1 ! access-list 101 deny igrp any host 255.255.255.255 access-list 101 permit ip any any ! dialer-list 1 protocol ip list 101
You can set up a one-way client-to-server dial-on-demand (DDR) so that the client can dial into the server but the server does not have dial-in access to the client. This configuration is demonstrated in the following two subsections.
The following example configuration is performed on the remote side of the connection:
interface ethernet 0 ip address 172.30.44.1 255.255.255.0 ! interface async 7 ip unnumber e 0 async mode interactive encap ppp dialer in-band dialer map IP 172.30.44.1 modem-script generic 1234 dialer-group 1 ! ip route 172.30.43.0 255.255.255.0 async 7 ip default-network 128.150.0.0 chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT dialer-list 1 protocol ip permit ! line 7 no exec modem InOut speed 38400 flowcontrol hardware modem chat-script generic
The following example configuration is performed on the local side of the connection:
interface ethernet 0 ip address 172.30.43.1 255.255.255.0 ! interface async 7 ip unnumber e 0 async mode dedicated async default ip address 128.150.43.0 encap ppp ! ip route 172.30.44.0 255.255.255.0 async 7 ! line 7 modem RI-is-CD speed 38400 flowcontrol hardware
You can set up a two-way reciprocal dial-on-demand (DDR) without authentication in which both the client and server have dial-in access to each other. This configuration is demonstrated in the following two subsections.
The following example configuration is performed on the remote side of the connection:
interface ethernet 0 ip address 172.30.44.1 255.255.255.0 ! interface async 7 ip address 172.30.45.2 255.255.255.0 async mode dedicated async default ip address 172.30.45.1 encap ppp dialer in-band dialer string 1234 dialer-group 1 ! ip route 172.30.43.0 255.255.255.0 async 7 ip default-network 172.30.0.0 chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT dialer-list 1 protocol ip permit ! line 7 no exec modem InOut speed 38400 flowcontrol hardware modem chat-script generic
The following example configuration is performed on the local side of the connection:
interface ethernet 0 ip address 172.30.43.1 255.255.255.0 ! interface async 7 async mode dedicated async default ip address 172.30.45.2 encapsulation ppp dialer in-band dialer string 1235 dialer rotary-group 1 ! interface async 8 async mode dedicated async default ip address 172.30.45.2 dialer rotary-group 1 ! ip route 172.30.44.0 255.255.255.0 async 7 ip address 172.30.45.2 255.255.255.0 encap ppp ppp authentication chap dialer in-band dialer map ip 172.30.45.2 name remote 4321 dialer load-threshold 80 ! ip route 172.30.44.0 255.255.255.0 128.150.45.2 chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT dialer-list 1 protocol ip permit ! route igrp 109 network 172.30.0.0 redistribute static passive-interface async 7 ! line 7 modem InOut speed 38400 flowcontrol hardware modem chat-script generic
You can set up a two-way dial-on-demand (DDR) with authentication in which both the client and server have dial-in access to each other. This configuration is demonstrated in the following two subsections.
The following example configuration is performed on the remote side of the connection. It provides authentication by identifying a password that must be provided on each end of the connection.
username local password secret1 username remote password secret2 interface ethernet 0 ip address 172.30.44.1 255.255.255.0 ! interface async 7 ip address 172.30.45.2 255.255.255.0 async mode dedicated async default ip address 172.30.45.1 encap ppp dialer in-band dialer string 1234 dialer-group 1 ! ip route 172.30.43.0 255.255.255.0 async 7 ip default-network 172.30.0.0 chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT dialer-list 1 protocol ip permit ! line 7 no exec modem InOut speed 38400 flowcontrol hardware modem chat-script generic
The following example configuration is performed on the local side of the connection. As with the remote side configuration, it provides authentication by identifying a password for each end of the connection.
username remote password secret1 username local password secret2 ! interface ethernet 0 ip address 172.30.43.1 255.255.255.0 ! interface async 7 async mode dedicated async default ip address 172.30.45.2 dialer rotary-group 1 ! interface async 8 async mode dedicated async default ip address 172.30.45.2 dialer rotary-group 1 ! interface dialer 1 ip address 172.30.45.2 255.255.255.0 encap ppp ppp authentication chap dialer in-band dialer map ip 172.30.45.2 name remote 4321 dialer load-threshold 80 ! ip route 172.30.44.0 255.255.255.0 172.30.45.2 chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT ! route igrp 109 network 172.30.0.0 redistribute static passive-interface async 7 ! line 7 modem InOut speed 38400 flowcontrol hardware modem chat-script generic
You can set up dial-on-demand (DDR) to provide service to multiple remote sites. In a hub-and-spoke configuration, you can use a generic configuration script to set up each remote connection. Figure 7-11 illustrates a typical hub-and-spoke configuration.
This configuration is demonstrated in the following two subsections.
The following example configuration is performed on the remote side of the connection. (A different spoke password must be specified for each remote client.) It provides authentication by identifying a password that must be provided on each end of the connection.
interface ethernet 0 ip address 172.30.44.1 255.255.255.0 ! interface async 7 async mode dedicated async default ip address 128.150.45.1 ip address 1172.30.45.2 255.255.255.0 encap ppp ppp authentication chap dialer in-band dialer map ip 172.30.45.1 name hub system-script hub 1234 dialer map ip 172.30.45.255 name hub system-script hub 1234 dialer-group 1 ! ip route 172.30.43.0 255.255.255.0 172.30.45.1 ip default-network 172.30.0.0 chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT chat-script hub "" "" name: spoke1 word" <spoke1-passwd> PPP dialer-list 1 protocol ip permit ! username hub password <spoke1-passwd> ! router igrp 109 network 172.30.0.0 passive-interface async 7 ! line 7 modem InOut speed 38400 flowcontrol hardware modem chat-script generic
The following example configuration is performed on the local side of the connection--the hub server. It configures the server for communication with three clients and provides authentication by identifying a unique password for each "spoke" in the hub-and-spoke configuration.
interface ethernet 0 ip address 172.30.43.1 255.255.255.0 ! interface async 7 async mode interactive async dynamic address dialer rotary-group 1 ! interface async 8 async mode interactive async dynamic address dialer rotary-group 1 ! interface dialer 1 ip address 172.30.45.2 255.255.255.0 no ip split-horizon encap ppp ppp authentication chap dialer in-band dialer map ip 172.30.45.2 name spoke1 3333 dialer map ip 172.30.45.2 name spoke2 4444 dialer map ip 172.30.45.2 name spoke3 5555 dialer map ip 172.30.45.255 name spoke1 3333 dialer map ip 172.30.45.255 name spoke2 4444 dialer map ip 172.30.45.255 name spoke3 5555 dialer-group 1 ! ip route 172.30.44.0 255.255.255.0 172.30.45.2 ip route 172.30.44.0 255.255.255.0 172.30.45.3 ip route 172.30.44.0 255.255.255.0 172.30.45.4 dialer-list 1 list 101 access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT ! username spoke1 password <spoke1-passwd> username spoke2 password <spoke2-passwd> username spoke3 password <spoke3-passwd> username spoke1 autocommand ppp 172.30.45.2 username spoke2 autocommand ppp 172.30.45.3 username spoke3 autocommand ppp 172.30.45.4 ! router igrp 109 network 172.30.0.0 redistribute static ! line 7 login tacacs modem InOut speed 38400 flowcontrol hardware modem chat-script generic
You can set dial-on-demand (DDR) for Novell IPX so that both the client and server have dial-in access to each other. This configuration is demonstrated in the following two subsections.
The following example configuration is performed on the remote side of the connection:
username local password secret ipx routing ! interface ethernet 0 ipx network 40 ! interface async ip unnumbered e0 encap ppp async mode dedicated async dynamic routing ipx network 45 ipx watchdog-spoof dialer in-band dialer map ipx 45.0000.0cff.d016 broadcast name local 1212 dialer-group 1 ppp authentication chap ! access-list 901 deny 0 FFFFFFFF 452 access-list 901 deny 0 FFFFFFFF 453 access-list 901 deny 0 FFFFFFFF 457 access-list 901 deny 0 FFFFFFFF 0 FFFFFFFF 452 access-list 901 deny 0 FFFFFFFF 0 FFFFFFFF 453 access-list 901 deny 0 FFFFFFFF 0 FFFFFFFF 457 access-list 901 permit 0 ipx route 41 45.0000.0cff.d016 ipx route 50 45.0000.0cff.d016 ipx sap 4 SERVER 50.0000.0000.0001 451 2 chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT ! dialer-list 1 list 901 ! line 7 modem InOut speed 38400 flowcontrol hardware modem chat-script generic
The following example configuration is performed on the local side of the connection:
username remote password secret ipx routing ! interface ethernet 0 ipx network 41 ! interface async ip unnumbered e0 encap ppp async mode dedicated async dynamic routing ipx network 45 ipx watchdog-spoof dialer in-band dialer map ipx 45.0000.0cff.d016 broadcast name remote 8888 dialer-group 1 ppp authentication chap ! access-list 901 deny 0 FFFFFFFF 452 access-list 901 deny 0 FFFFFFFF 453 access-list 901 deny 0 FFFFFFFF 457 access-list 901 deny 0 FFFFFFFF 0 FFFFFFFF 452 access-list 901 deny 0 FFFFFFFF 0 FFFFFFFF 453 access-list 901 deny 0 FFFFFFFF 0 FFFFFFFF 457 access-list 901 permit 0 ipx route 40 45.0000.0cff.d016 chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT ! dialer-list 1 list 901 ! line 7 modem InOut speed 38400 flowcontrol hardware modem chat-script generic
You can set up a fully meshed dial-on-demand (DDR) for Novell IPX so that both clients and server have DDR access to other members of the network. This configuration is illustrated in Figure 7-12.
This configuration is demonstrated in the following example.
The following example configuration for three fully meshed sites is performed on the host side of the connection:
ip routing
ipx routing
!
interface ethernet 0
ip address 172.30.41.1 255.255.255.0
ipx network 41
!
interface async 7
async mode interactive
async dynamic address
async dynamic routing
dialer rotary-group 1
!
interface async 8
async mode interactive
async dynamic address
dialer rotary-group 1
!
interface dialer 1
ip address 128.150.45.1 255.255.255.0
ipx network 45
ipx watchdog-spoof
encap ppp
dialer in-band
dialer map ip 172.30.45.2 name site2 system-script site2 2222
dialer map ip 172.30.45.3 name site3 system-script site3 3333
dialer map ipx 45.0000.0cff.d012 broadcast name site2 system-script site2 2222
dialer map ipx 45.0000.0cff.d013 broadcast name site3 system-script site3 3333
dialer-group 1
ppp authentication chap
!
ip route 172.30.44.0 255.255.255.0 172.30.45.2
ip route 172.30.48.0 255.255.255.0 172.30.45.3
ipx route 42 45.0000.0cff.d012
ipx route 43 45.0000.0cff.d013
ipx route 52 45.0000.0cff.d012
ipx route 53 45.0000.0cff.d013
ipx sap 4 SITE2 52.0000.0000.0001 451 2
ipx sap 4 SITE3 53.0000.0000.0001 451 2
dialer-list 1 list 101
dialer-list 1 list 901
access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
access-list 901 deny 0 FFFFFFFF 452
access-list 901 deny 0 FFFFFFFF 453
access-list 901 deny 0 FFFFFFFF 457
access-list 901 deny 0 FFFFFFFF 0 FFFFFFFF 452
access-list 901 deny 0 FFFFFFFF 0 FFFFFFFF 453
access-list 901 deny 0 FFFFFFFF 0 FFFFFFFF 457
access-list 901 permit 0
!
username site2 password site1&2
username site3 password site1&3
username site2 autocommand ppp 128.150.45.2
username site3 autocommand ppp 128.150.45.3
!
chat-script site2 " " " " name: site2 word: site1&2 PPP
chat-script site3 " " " " name: site3 word: site1&3 PPP
chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT
!
router igrp 109
network 172.30.0.0
redistribute static
!
line 7 8
login tacacs
modem InOut
speed 38400
flowcontrol hardware
modem chat-script generic
|
|