Полезная информация

cc/td/doc/product/software/ios112/112cg_cr
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Configuring DDR

Configuring DDR

This chapter describes how to configure the Cisco IOS software 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 Wide-Area Networking Command Reference. The Point-to-Point Protocol (PPP) is mentioned in several places in this chapter. For information about configuring PPP, refer to the "Configuring PPP for Wide-Area Networking" chapter of this manual. For information about the PPP commands that are used in this chapter, refer to the "PPP Commands for Wide-Area Networking" chapter of the Wide-Area Networking Command Reference.

Beginning with Cisco IOS Release 11.2, our software includes two implementations of DDR:

In this release, most routed protocols are supported; however, Frame Relay, ISO CLNS, LAPB, and snapshot routing are not supported.

Dialer Profiles allow the configuration of physical interfaces to be separated from the logical configuration required for a call, and also allow the logical and physical configurations to be bound together dynamically on a per-call basis. This release supports PPP and HDLC encapsulation on the physical interface. All other settings are part of a logical configuration used and applied to the physical interface as needed for specific calls. Configuration of dial backup is also simplified if you use Dialer Profiles.

Legacy DDR is limited by the static binding between the per-destination call specification and the physical interface configuration. Problems arising from this limitation include the following:


Note If you are configuring DDR for the first time, use the simpler and more flexible Dialer Profiles method for configuring DDR. If you have legacy DDR configurations, you can keep them.

This chapter is divided into two parts:

For more information about configuring dialer profiles, see the "Dialer Profiles and Backup Configuration Task List" section in this chapter.
For more information about configuring legacy DDR, see the "Legacy DDR Configuration Task Overview" section in this chapter.

Note If you choose to use the new dialer profiles, you do not need to refer to the legacy DDR section. Conversely, if you choose to use legacy DDR, you do not need to refer to the dialer profiles section.

Dialer Profiles and Backup Configuration Task List

To configure dialer profiles, perform the tasks in the following sections. The backup task is not required.

Perform the tasks in the following sections, as needed for your network:

See the "Dialer Profile Examples" section for comprehensive Dialer Profile examples.

Understand Dialer Interfaces and Dialer Profiles

Dialer profiles allow the configuration of physical interfaces to be separated from the logical configuration required for a call, and also allow the logical and physical configurations to be bound together dynamically on a per-call basis.

A dialer profile consists of the following elements:

All calls going to from the same destination subnetwork use the same dialer profile.

A dialer interface configuration includes all settings needed to reach a specific destination subnetwork (and any networks reached through it). Multiple dial strings can be specified for the same dialer interface, each dial string being associated with a different dialer map-class. The dialer map-class defines all the characteristics for any call to the specified dial string. For example, the map-class for one destination might specify a 56-kbps ISDN speed; the map-class for a different destination might specify a 64-kbps ISDN speed.

Each dialer interface uses a dialer pool, a pool of physical interfaces ordered on the basis of the priority assigned to each physical interface. A physical interface can belong to multiple dialer pools, contention being resolved by priority. ISDN BRI and PRI interfaces can set a limit on the minimum and maximum number of B channels reserved by any dialer pools. A channel reserved by a dialer pool remains idle until traffic is directed to the pool.

When dialer profiles are used to configure DDR, a physical interface has no configuration settings except encapsulation and the dialer pools the interface belongs to.


Note The preceding paragraph has one exception: commands that apply before authentication is complete must be configured on the physical (or BRI or PRI) interface and not on the dialer profile. Dialer profiles do not copy PPP authentication commands (or LCP commands) to the physical interface.

Figure 16 shows a typical application of dialer profiles. Router A has dialer interface 1 for dial-on-demand routing with subnetwork 1.1.1.0, and dialer interface 2 for dial-on-demand routing with subnetwork 2.2.2.0.


Figure 16: Typical Dialer Profiles Application


A dialer interface uses only one dialer pool. A physical interface, however, can be a member of one or many dialer pools, and a dialer pool can have several physical interfaces as members.

Figure 17 illustrates the relations among the concepts of dialer interface, dialer pool, and physical interfaces. Dialer interface 0 uses dialer pool 2. Physical interface BRI 1 belongs to dialer pool 2 and has a specific priority in the pool. Physical interface BRI 2 also belongs to dialer pool 2. Because contention is resolved on the basis of priority-levels of the physical interfaces in the pool, BRI 1 and BRI 2 have to be assigned different priorities in the pool. Perhaps BRI 1 is assigned priority 100 and BRI 2 is assigned priority 50 in dialer pool 2 (a priority of 50 is higher than a priority of 100). BRI 2 has a higher priority in the pool and its calls will be placed first.


Figure 17:
Relations Among Dialer Interfaces, Dialer Pools, and Physical Interfaces


Configure Dialer Profiles

To configure dialer profiles, perform the tasks in the following sections. The first, second, and last are required. Map-class configuration is optional.

Disable Validation of Source Addresses

To enable routing to work with Dialer Profiles, you need to disable validation of source addresses. For example, for IP RIP routing, complete the following tasks beginning in global configuration mode:

Task Command
Enable routing. router rip
Disable validation of source addresses. no validate-update-source
Specify the network address. network address

Configure a Dialer Interface

Any number of dialer interfaces can be created for a router. Each dialer interface is the complete configuration for a destination subnetwork and any networks reached through it. The router on the destination subnetwork sends traffic on to the appropriate shadowed network.

To configure a dialer interface, complete the following tasks beginning in global configuration mode:

Task Command
Step 1 Create a dialer interface. interface dialer number
Step 2 Specify the IP address and mask of the destination network to be called. ip address address mask
Step 3 Specify PPP encapsulation. encapsulation ppp
Step 4 Specify the remote router CHAP authentication name. dialer remote-name name
Step 5 Specify the remote destination to call and the map class that defines characteristics for calls to this destination. dialer-string string class class-name
Step 6 Specify the dialing pool to use for calls to this destination. dialer pool number
Step 7 Assign the dialer interface to a dialer group. dialer-group number
Step 8 Specify an access-list by list-number or by protocol and list number to define the "interesting" packets that can trigger a call. dialer-list dialer-group list access-list-number
or
dialer-list dialer-group protocol protocol-name {permit | deny | list access-list-number}

Configure a Map Class

Map class configuration is optional but allows you to specify different characteristics for different types of calls on a per-call-destination basis. For example, you can specify higher priority and a lower wait-for-carrier time for an ISDN-calls map class than for a modem-calls map class. You can also specify a different speed for some ISDN calls than for other ISDN calls.

A specific map class is tied to a specific call destination by the use of the map-class name in the dialer-string command with the class keyword.

To specify a map class and define its characteristics, complete the following tasks beginning in global configuration mode:

Task Command
Specify a map class and enter map-class configuration mode. map-class dialer class-name
Specify the fast idle timer value. dialer fast-idle seconds
Specify the idle time before the calls in this map class are disconnected. dialer idle-timeout seconds
Specify the length of time to wait for a carrier when dialing out to the dial string associated with the map class dialer wait-for-carrier-time seconds
For ISDN only, specify the bit rate used on the B channel associated with a specified map class or specify that an ISDN semipermanent connection is to not be used for calls associated with this map. dialer isdn [speed speed] [spc]

Configure the Physical Interfaces

To configure a physical interface, complete the following tasks beginning in global configuration mode:

Task Command
Step 1 Specify the physical interface. interface type number
Step 2 Enable PPP encapsulation. encapsulation ppp
Step 3 Specify PPP CHAP authentication, if you also want to receive calls on this interface. ppp authentication chap
Step 4 Put the interface in a dialing pool and, optionally, assign the interface a priority.

For ISDN interfaces, you can also optionally specify the minimum number of channels reserved and maximum number of channels that can be for this dialing pool.
dialer pool-member number [priority priority]


dialer pool-member
number [priority priority] [min-link minimum] [max-link maximum]
Step 5 (Optional) Repeat Step 3 if you want to put the interface in additional dialing pools. dialer pool-member number [priority priority]
or
dialer pool-member number [priority priority] [min-link minimum] [max-link maximum]

Repeat this procedure for additional physical interfaces that you want to use with dialer profiles.

When you specify a min-link number, that number of channels is reserved for that dialer pool; the channels remain idle when no calls are active.

Configure a Dial Backup Interface for Leased Line Interfaces

Dialer interfaces can be configured as the logical intermediary between one or more physical interfaces and another physical interface that is to function as backup.

Dialer interfaces can be configured to use a specific dialing pool; in turn physical interfaces can be configured to belong to the same dialing pool.

To configure a dialer interface and a specific physical interface to function as backup to other physical interfaces, perform the following steps:

Step 1 Configure a dialer interface; make sure it uses a specific dialing pool.

Step 2 Configure the physical interface that is to function as backup to belong to the same dialing pool.

Step 3 Configure one or more interfaces to use a backup interface.

See the "Dialer Profile for ISDN BRI Backing Up Two Leased Lines Example" for a comprehensive backup example using dialer profiles. In this example, one BRI functions as backup to two serial lines and can make calls to two different destinations.

Configure DDR over X.25

X.25 interfaces can now be configured to support DDR. Synchronous serial and ISDN interfaces on our routers and access servers can be configured for X.25 addresses, X.25 encapsulation, and mapping of protocol addresses to a remote host's X.25 address. In-band, DTR, and ISDN dialers can be configured to support X.25 encapsulation, but rotary groups cannot. On ISDN dialers configured for X.25 encapsulation, only one B channel can be used.

To configure an interface to support X.25, perform the following X.25-specific tasks in interface configuration mode and also complete the DDR configuration of the interface:

Task Command
Step 1 Configure the interface to use X.25 encapsulation. encapsulation x25 [dte | dce] [ietf]1  
Step 2 Assign an X.25 address to the interface. x25 address x.121-address1
Step 3 Set up the mapping of LAN protocol addresses to the remote host X.121 address. x25 map protocol address [protocol2 address2 [...[protocol9 address9]]] x.121-address [option]1

1 This command is documented in the "X.25 and LAPB Commands" chapter in the Wide-Area Networking Command Reference.

The order of DDR and X.25 configuration tasks is not critical; you can configure DDR before or after X.25, and you can even mix the DDR and X.25 commands.

For an example of configuring an interface for X.25 encapsulation and then completing the DDR configuration, see the section "X.25 Support Configuration Example" later in this chapter.

Configure DDR for Routed Protocols

DDR supports the following routed protocols: AppleTalk, Banyan VINES, DECnet, IP, Novell IPX, and XNS.

To configure DDR for a routed protocol, perform the tasks in the relevant section:

Configure DDR for AppleTalk

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 "Control Access to a DDR Interface" section for more information about defining dialer lists.

Configure DDR for Banyan VINES

To configure DDR for Banyan VINES, perform one of the following tasks in global configuration mode:

Task Command
Specify a VINES standard access list.

or

Specify a VINES extended access list.

vines access-list access-list-number {permit | deny} source source-mask1

vines access-list access-list-number {permit | deny} source source-mask [destination] [destination-mask] 1


1 This command is documented in the "Banyan VINES Commands" chapter in the Network Protocols Command Reference, Part 2.

After you specify VINES standard or extended access lists, define DDR dialer lists as described in the "Control Access to a DDR Interface" section. 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.

You can configure Banyan VINES on DDR synchronous and ISDN interfaces, as well as dialer rotary groups.


Note The Banyan VINES "neighbor" command is not supported for LAPB and X.25 encapsulations.

See the "Control Access to a DDR Interface" section for more information about defining dialer lists.

Configure DDR for DECnet

To configure DDR for DECnet, perform one of the following tasks in global configuration mode:

Task Command
Specify a DECnet standard access list.

or

Specify a DEcnet extended access list.

access-list access-list-number {permit | deny} source source-mask1

access-list access-list-number {permit | deny} source source-mask [destination] [destination-mask]1


1 This command is documented in the "DECnet Commands" chapter in the Network Protocols Command Reference, Part 2.

After you specify DECnet standard or extended access lists, define DDR dialer lists as described in the "Control Access to a DDR Interface" section. 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.

You classify DECnet control packets, including hello packets and routing updates, using one or more of the following commands: dialer-list protocol decnet_router-L1 permit, dialer-list protocol decnet_router-L2 permit, and dialer-list protocol decnet_node permit.

You can configure DECnet on DDR synchronous and ISDN interfaces, and dialer rotary groups.

See the "Control Access to a DDR Interface" section for more information about defining dialer lists.

Configure DDR for IP

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]1

access-list access-list-number {deny | permit} protocol source source-mask destination destination-mask [operator operand]1


1 This command is documented in the "IP Commands" chapter in the Network Protocols Command Reference, Part 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 in the Network Protocols Command Reference, Part 1.

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 in the Network Protocols Configuration Guide, Part 1 for more information.

Configure DDR for Novell IPX

On DDR links for Novell IPX, the link may come up often even when all client sessions are idle because the server sends watchdog or keepalive packets to all the clients approximately every 5 minutes. You can configure a local router or 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. 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

1 This command is documented in the "Novell IPX Commands" chapter in the Network Protocols Command Reference, Part 1.

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

1 This command is documented in the "Novell IPX Commands" chapter in the Network Protocols Command Reference, Part 1.

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

1 This command is documented in the "Novell IPX Commands" chapter in the Network Protocols Command Reference, Part 2

Configure XNS over DDR

To configure XNS for DDR, perform one of the following tasks in global configuration mode:

Task Command
Specify a standard XNS access list.


or

Specify an extended XNS access list.

access-list access-list-number {deny | permit}
source-network[.source-address  [source-address-mask]]
[
destination-network[.destination-address
[destination-address-mask]]]

access-list access-list-number {deny | permit} protocol [source-network[.source-host
[source-network-mask.]source-host-mask] source-socket [destination-network [.destination-host [destination-network-mask.destination-host-mask] destination-socket[/pep]]]
1


1 This command is documented in the "XNS Commands" chapter in the Network Protocols Command Reference, Part 2.

After you specify an XNS access list, define a DDR dialer list, as described in the "Control Access to a DDR Interface" section. 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.

You can configure XNS on DDR serial synchronous and ISDN interfaces, as well as dialer rotary groups.

See the "Control Access to a DDR Interface" section for more information about defining dialer lists.

Configure DDR for Transparent Bridging

The Cisco IOS software supports transparent bridging over DDR and provides you some flexibility in controlling access and configuring the interface.

To configure DDR for bridging, complete the tasks in the following sections:

For an example of configuring DDR for transparent bridging, see the "DDR for Transparent Bridging Examples" section.

Define the Protocols to Bridge

IP packets are routed by default unless they are explicitly bridged; all others are bridged by default unless they are explicitly routed. To bridge IP packets, complete the following task in global configuration mode:

Task Command
Disable IP routing. no ip routing 1

1 This command is documented in the "IP Commands" chapter in the Configuration Fundamentals Command Reference.

If you choose not to bridge another protocol, use the relevant command to enable routing of that protocol. For more information about tasks and commands, refer to the relevant protocol chapter in either the Network Protocols Configuration Guide, Part 1 or the Network Protocols Configuration Guide, Part 2.

Specify the Bridging Protocol

You must specify the type of spanning tree bridging protocol to use and also identify a bridge group. To specify the spanning tree protocol and a bridge group number, complete the following task in global configuration mode:

Task Command
Define the type of spanning tree protocol and identify a bridge group. bridge bridge-group protocol {ieee | dec}1

1 This command is documented in the "Transparent Bridging Commands" chapter in the Bridging and IBM Networking Command Reference.

The bridge-group number is used when you configure the interface and assign it to a bridge group. Packets are bridged only among members of the same bridge group.

Control Access for Bridging

You can control access by defining any transparent bridge packet as interesting, or you can use the finer granularity of controlling access by Ethernet type codes. To control access for DDR bridging, complete one of the following tasks in global configuration mode:


Note Spanning tree bridge protocol data units (BPDUs) are always treated as uninteresting.

Permit All Bridge Packets

To identify all transparent bridge packets as interesting, complete the following task in global configuration mode:

Task Command
Define a dialer list that treats all transparent bridge packets as interesting. dialer-list dialer-group protocol bridge permit

Control Bridging Access by Ethernet Type Codes

To control access by Ethernet type codes, complete the following tasks in global configuration mode:

Task Command
Identify interesting packets by Ethernet type codes (access list numbers must be in the range 200-299). access-list access-list-number {permit | deny} type-code [mask]1
Define a dialer list for the specified access list. dialer-list dialer-group protocol bridge list access-list-number

1 This command is documented in the "Transparent Bridging Commands" chapter in the Bridging and IBM Networking Command Reference.

For a table of some common Ethernet types codes, see the "Ethernet Types Codes" appendix in the Bridging and IBM Networking Command Reference.

Configure an Interface for Bridging

You can configure serial interfaces or ISDN interfaces for DDR bridging. To configure an interface for DDR bridging, complete all the tasks in the following sections:

Specify the Interface

To specify the interface and enter interface configuration mode, complete the following task, starting in global configuration mode:

Task Command
Specify the serial or ISDN interface and enter interface configuration mode. interface type number1

1 This command is documented in the "Interface Commands" chapter in the Configuration Fundamentals Command Reference.

Configure the Destination

You can configure the destination by specifying a dial string for unauthenticated calls to a single site, or by specifying a dialer bridge map when you want to use authentication.

To configure the destination for bridging over a specified interface, complete the following task in interface configuration mode:

Task Command
Configure the dial string to call. dialer string dial-string

Note You can define only one dialer bridge map for the interface. If you enter a different bridge map, the previous one is replaced immediately.

Assign the Interface to a Bridge Group

Packets are bridged only among interfaces that belong to the same bridge group. To assign an interface to a bridge group, complete the following task in interface configuration mode:

Task Command
Assign the specified interface to a bridge group. bridge-group bridge-group1

1 This command is documented in the "Transparent Bridging Commands" chapter in the Bridging and IBM Networking Command Reference.

Monitor and Maintain DDR Dialer Profile Connections

To monitor DDR dialer profile connections, perform the following tasks in privileged EXEC mode:

Task Command
Display information for the interfaces configured for DDR dialer profiles. show dialer interface
Display information about the ISDN interface. show interfaces bri 01
Display status about the IPX interface. show ipx interface [type number]2
Display information about the IPX packets transmitted by the router or access server, including watchdog counters. show ipx traffic2
Display information about the AppleTalk packets transmitted by the router or access server. show appletalk traffic3
Display information about the Banyan VINES packets transmitted by the router or access server. show vines traffic4
Display information about the DECnet packets transmitted by the router or access server. show decnet traffic 5
Display information about the XNS packets transmitted by the router or access server. show xns traffic6
Clear the values of the general diagnostic statistics. clear dialer

1 This command is documented in the "ISDN Commands" chapter in the Wide-Area Networking Command Reference.
2 This command is documented in the "Novell IPX Commands" chapter in the Network Protocols Command Reference, Part 1.
3 This command is documented in the "AppleTalk Commands" chapter in the Network Protocols Command Reference, Part 1
4 This command is documented in the "Banyan VINES Commands" chapter in the Network Protocols Command Reference, Part 2
5 This command is documented in the "DECnet Commands" chapter in the Network Protocols Command Reference, Part 2
6 This command is documented in the "XNS Commands" chapter in the Network Protocols Command Reference, Part 2

Dialer Profile Examples

This section provides the following comprehensive examples:

Multiple Remote Sites with ISDN Access Only

The following example shows the configuration of a central site that can place or receive calls from three remote sites over four ISDN BRI lines. Each remote site is on a different IP subnet and has different bandwidth requirements. Therefore three dialer interfaces and three dialer pools are defined.

! This is a Dialer Profile for reaching remote subnetwork 1.1.1.1.
interface Dialer1
ip address 1.1.1.1 255.255.255.0
encapsulation ppp
dialer remote-name Smalluser
dialer string 4540
dialer pool 3
dialer-group 1
! This is a Dialer Profile for reaching remote subnetwork 2.2.2.2.
interface Dialer2
ip address 2.2.2.2 255.255.255.0
encapsulation ppp
dialer remote-name Mediumuser
dialer string 5264540 class Eng
dialer load-threshold 50 either
dialer pool 1
dialer-group 2
! This is a Dialer Profile for reaching remote subnetwork 3.3.3.3.
interface Dialer3
ip address 3.3.3.3 255.255.255.0
encapsulation ppp
dialer remote-name Poweruser
dialer string 4156884540 class Eng
dialer hold-queue 10
dialer load-threshold 80
dialer pool 2
dialer-group 2
! This map class ensures that these calls use an ISDN speed of 56 kbps.
map-class dialer Eng
isdn speed 56
interface BRI0
encapsulation PPP
! BRI 0 has a higher priority than BRI 1 in dialer pool 1.
dialer pool-member 1 priority 100
ppp authentication chap
interface BRI1
encapsulation ppp
dialer pool-member 1 priority 50
dialer pool-member 2 priority 50
! BRI 1 has a reserved channel in dialer pool 3; the channel remains inactive
! until BRI 1 uses it to place calls.
dialer pool-member 3 min-link 1
ppp authentication chap
interface BRI2
encapsulation ppp
! BRI 2 has a higher priority than BRI 1 in dialer pool 2.
dialer pool-member 2 priority 100
ppp authentication chap
interface BRI3
encapsulation ppp
! BRI 3 has the highest priority in dialer pool 2.
dialer pool-member 2 priority 150
ppp authentication chap

Dialer Profile for ISDN BRI Backing Up Two Leased Lines Example

The following example shows the configuration of a site that backs up two leased lines using one BRI. Two dialer interfaces are defined. Each serial (leased line) interface is configured to use one of the dialer interfaces as a backup. Both of the dialer interfaces use dialer pool 1, which has BRI 0 as a member. Thus, BRI 0 can back up two different serial interfaces and can make calls to two different sites.

interface dialer0
ip unnumbered loopback0
encapsulation ppp
dialer remote-name Remote0
dialer pool 1
dialer string 5551212
dialer-group 1
interface dialer1
ip unnumbered loopback0
encapsulation ppp
dialer remote-name Remote1
dialer pool 1
dialer string 5551234
dialer-group 1
interface bri 0
encapsulation PPP
dialer pool-member 1
ppp authentication chap
interface serial 0
ip unnumbered loopback0
backup interface dialer 0
backup delay 5 10
interface serial 1
ip unnumbered loopback0
backup interface dialer1
backup delay 5 10

Legacy DDR Configuration Task Overview

Before you configure an asynchronous interface on the auxiliary port to support DDR, configure the line as follows:

To configure the Cisco IOS software for dial-on-demand routing, you must perform one of the tasks in the following sections:

You can also optionally customize and monitor DDR by performing the tasks in the following sections:

You can also enhance DDR by performing the following tasks:

The PPP configuration tasks are described in the "Configuring PPP for Wide-Area Networking" chapter of this publication.

See the "Legacy 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 as necessary:

If configuring calls to multiple sites, you can configure calling on a single line or multiple lines, or configure calling from dialer rotary groups.

The following sections describe these tasks.

Create and Specify Chat Scripts

For asynchronous interfaces only, you must create one or more chat scripts and then specify which chat script to use for the specified interface.

Create Chat Scripts

A chat script is a one-line command that is used on an asynchronous interface to send commands for modem dialing and for logging on to remote systems. Chat scripts indicate the possible responses to expect and the information to send in each case. You can create a different chat script for each type of modem in use on the router and for each system the router might need to log in to.

Chat scripts are required for dialing out on the asynchronous interface on the router's auxiliary port.

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

We recommend that you write one chat script (a "dialer" chat script) for placing a call and another one (a "login" chat script) to log on to remote systems, where required.

For an example of how to use chat scripts, see "Using Chat Scripts Example" later in this chapter and refer to the "Configuring Terminal Lines and Modem Support" chapter in the Access Services Configuration Guide.

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 method 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

After a chat script has been defined as described in the "Configuring Terminal Lines and Modem Support" chapter of the Access Services Configuration Guide, 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 allows you to specify a chat script by the type of the modem attached to that line as follows:

script dialer modem-type*

We recommend 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 technique is useful if you specify modem scripts on an interface that is used to dial multiple destinations. Procedures for dialing multiple destinations are described in the "Configure Calls to Multiple Sites" section. Regular expressions are described in the "Regular Expressions" appendix in the Access Services Command Reference.

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 the Access Services Configuration Guide.

Configure Calls to a Single Site

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.

Enable DDR

To enable DDR and specify either DTR dialing or in-band dialing, perform one of the following tasks in interface configuration mode:

Task Command
Enable DDR and configure the specified serial interface to use DTR dialing. dialer dtr
Enable DDR and configure the specified serial interface to use in-band dialing. dialer in-band [no-parity | odd-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 Cisco IOS software 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 devices 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.

Specify the Dial String for Synchronous Serial Interfaces

If you want to call only one remote system per synchronous serial interface, use the dialer string command. 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[:isdn-subaddress]

Specify Chat Scripts and Dial Strings for Asynchronous Serial Interfaces

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 place a call to a single site on an asynchronous line for which either a modem dialing script has not been assigned or for which a system script login 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]

For asynchronous interfaces that do not require a system login script, perform the following task in line configuration mode:

Task Command
Define a modem script for the associated line. script dialer

You do not need to specify a system login script if one of the following is true:

Configure Calls to Multiple Sites

You can configure the Cisco IOS software 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 the Cisco IOS software 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
Specify telephone number to dial (to configure one phone number on multiple lines only.) dialer string dial-string
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]
(Optional) Define multiple dialing destinations on an Integrated Services Digital Network (ISDN) interface. dialer map protocol next-hop-address
[speed 56 | speed 64] dial-string[:
isdn-subaddress]

Note For ISDN interfaces only, you can specify an optional speed parameter for dialer map commands. If you omit the ISDN speed parameter, the default is 64 kbps.

For chat scripts on asynchronous interfaces, if you adhere 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 Access Services Command Reference.

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

Dialer rotary groups allow you to apply a single dialer 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 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 or access server. The telephone company also has rotary groups that allow you to dial one rotary phone number and connect 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 or access server.

Perform the following steps to configure the Cisco IOS software to place multiple calls using a dialer rotary group. 

Step 1 Define a dialer interface for a rotary group.

Step 2 Enable DDR on the dialer interface.

Step 3 Define multiple dialing destinations for the rotary group.

Step 4 Assign physical interfaces to the rotary group.

You define a dialer rotary group 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 defining the dialer interface by a number, you configure interface parameters for the dialer interface. Finally, 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, you can use those interfaces to place calls following standard DDR criteria. When you configure many destinations, 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 nine 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 dialer interface for 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 the dialer interface. dialer in-band

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 each interface inherits the parameters of the dialer interface in the dialer rotary group to which it was assigned.

Figure 18 illustrates how dialer interfaces work. In this example configuration, serial interfaces 1, 2, and 3 are assigned to dialer rotary group 1 and thereby 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. On access servers, these interfaces can be asynchronous as well as serial.


Figure 18:
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:


Note The Challenge Handshake Authentication Protocol (CHAP) or Password Authentication Protocol (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 you expect the receiving interface to terminate a call when no traffic is received for some time, you must configure in-band dialing (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 the Cisco IOS software 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 the Cisco IOS software 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 using a single line for dialing out only. 

You define a dialer rotary group 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, you can use those interfaces to place calls according to standard DDR criteria. When you configure many destinations, 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 and access server. The telephone company also has rotary groups that allow you to dial one rotary phone number and connect 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]
Enable and Configure CHAP or PAP Authentication

To use CHAP or PAP, you must be running PPP encapsulation. See the "Configuring PPP for Wide-Area Networking" chapter for information about configuring PPP.

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 or access server requires authentication from remote devices. If the remote device does not support the enabled protocol, 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 ppp

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

For more information about PPP and CHAP or PAP authentication, see the "Configuring PPP for Wide-Area Networking" chapter of this publication.

After you have enabled CHAP or PAP, the local router or access server 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 identification. username name password secret1

1 This command is documented in the "PPP Commands for Wide-Area Networking" chapter of this manual.

Add a username entry for each remote system from which the local router or access server requires authentication.

To configure Terminal Access Controller Access Control System (TACACS) as an alternative to host authentication, perform the following task in interface configuration mode:

Task Command
Configure TACACS. ppp use-tacacs [single-line]1
or
aaa authentication ppp2

1 This command is documented in the "System Management Commands" chapter in the Configuration Fundamentals Command Reference.
2 This command is documented in the "Interface Commands" chapter in the Configuration Fundamentals Command Reference.

Use the ppp use-tacacs command with TACACS and Extended TACACS. Use the aaa authentication ppp command with Authentication, Authorization, and Accounting (AAA)/TACACS+.

The host name of each site calling in to the local router or access server must 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 Physical Interfaces to Dialer Rotary Groups

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:

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 the Cisco IOS software 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, the Cisco IOS software recognizes each incoming call as coming 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 The Cisco IOS software identifies all incoming calls as coming 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 the next hop to a 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 must be authenticated. Authentication can be done through CHAP or PAP. To enable CHAP or PAP on an interface and authenticate sites that are calling in, perform the following tasks in interface configuration mode:

Task Command
Step 1 Configure an interface for PPP encapsulation. encapsulation ppp1
Step 2 Enable CHAP.
or
Enable PAP.
ppp authentication chap [if-needed]1
or
ppp authentication pap [if-needed]1
Step 3 Map the next hop to a host name and phone number. dialer map protocol next-hop-address name hostname [modem-script modem-regexp] [system-script system-regexp] dial-string[:isdn-subaddress]

1 This command is documented in the "PPP for Wide-Area Networking Commands" chapter in the Wide-Area Networking Command Reference.

See the "Create and Specify Chat Scripts" section and the "Specify Chat Scripts" section for an explanation of assigning chat scripts to an interface or dialer rotary group.

Figure 19 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 19: Hub-and-Spoke Configuration Using Dial-on-Demand Routing (DDR)


Configure Snapshot Routing

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. During the active period, a client router dials all the remote server routers for which it has a snapshot dialer map defined in order to get routes from all the remote locations. The server router provides information about routes to each client router that calls.

At the end of the active 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. See Figure 20.


Figure 20: Active and Quiet Periods in Snapshot Routing


When the router transitions from the quiet period to the active period, the line might not be available for a variety of reasons. For example, the line might be down or busy, or the PVC might be down. If this happens, the router has to wait through another entire quiet period before it can update its routing table entries. This wait might be a problem if the quiet period is very long--for example, 12 hours.

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:

To monitor and maintain snapshot routing, see the "Monitor DDR Connections and Snapshot Routing" section.

For an example of configuring snapshot routing, see the "Snapshot Routing Examples" section later in this chapter.

Configure the Client Router

To configure snapshot routing on the client router that is connected to a dedicated serial line, perform the following steps starting in global configuration mode:

Task Command
Step 1 Specify a serial interface. interface serial number1
Step 2 Configure the client router. snapshot client active-time quiet-time [suppress-statechange-updates] [dialer]

1 This command is documented in the "Interface Commands" chapter in the Configuration Fundamentals Command Reference.

To configure snapshot routing on the client router connected to an interface configured for DDR, perform the following steps starting in global configuration mode:

Task Command
Step 1 Specify a serial interface. interface serial number1
Step 2 Configure a dialer rotary group. dialer rotary-group number
Step 3 Specify a dialer interface. interface dialer number
Step 4 Configure the client router. snapshot client active-time quiet-time [suppress-statechange-updates] [dialer]
Step 5 Define a dialer map. dialer map snapshot sequence-number dial-string

1 This command is documented in the "Interface Commands" chapter in the Configuration Fundamentals Command Reference.

Repeat Step 5 for each map you want to define. Maps must be provided for all the remote server routers this client router is to call during each active period.

Because ISDN BRI and PRI automatically have rotary groups, you do not need to define a rotary group when configuring snapshot routing. To configure snapshot routing on the client router over an interface configured for BRI or PRI, perform the following steps:

Task Command
Step 1 Specify a BRI interface. interface bri number 1
Step 2 Configure the client router. snapshot client active-time quiet-time [suppress-statechange-updates] [dialer]
Step 3 Define a dialer map. dialer map snapshot sequence-number dial-string

1 This command is documented in the "Interface Commands" chapter in the Configuration Fundamentals Command Reference.

Repeat Step 3 for each map you want to define.

Configure the Server Router

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 number1
Step 2 Configure the server router. snapshot server active-time [dialer]

1 This command is documented in the "Interface Commands" chapter in the Configuration Fundamentals Command Reference.

To configure snapshot routing on the associated server router connected to an interface configured for DDR, perform the following steps beginning in global configuration mode:

Task Command
Step 1 Specify a serial interface. interface serial number1
Step 2 Specify a dialer interface. interface dialer number
Step 3 Configure the server router. snapshot server active-time [dialer]

1 This command is documented in the "Interface Commands" chapter in the Configuration Fundamentals Command Reference.

The active period for the client router and its associated server routers should be the same.

Configure DDR over LAPB

Dial-on-demand routing over serial lines now supports Link Access Procedure, Balanced (LAPB) encapsulation, in addition to the previously supported PPP, HDLC, and X.25 encapsulations.

LAPB encapsulation is supported on synchronous serial, ISDN, 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

1 This command is documented in the "X.25 and LAPB Commands" chapter in the Wide-Area Networking Command Reference.

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 Wide-Area Networking Command Reference.

For an example of configuring an interface for DDR over LAPB, see the "LAPB Support Configuration Example" section later in this chapter.

Configure DDR over X.25

X.25 interfaces can now be configured to support DDR. Synchronous serial and ISDN interfaces on our routers and access servers can be configured for X.25 addresses, X.25 encapsulation, and mapping of protocol addresses to a remote host's X.25 address. In-band, DTR, and ISDN dialers can be configured to support X.25 encapsulation, but rotary groups cannot. On ISDN dialers configured for X.25 encapsulation, only one B channel can be used.

To configure an interface to support X.25, perform the following X.25-specific tasks in interface configuration mode and also complete the DDR configuration of the interface:

Task Command
Step 1 Configure the interface to use X.25 encapsulation. encapsulation x25 [dte | dce] [ietf]1  
Step 2 Assign an X.25 address to the interface. x25 address x.121-address1
Step 3 Set up the LAN protocols-to-remote host address mapping. x25 map protocol address [protocol2 address2 [...[protocol9 address9]]] x.121-address [option]1

1 This command is documented in the "X.25 and LAPB Commands" chapter in the Wide-Area Networking Command Reference.

The order of DDR and X.25 configuration tasks is not critical; you can configure DDR before or after X.25, and you can even mix the DDR and X.25 commands.

For an example of configuring an interface for X.25 encapsulation and then completing the DDR configuration, see the section "X.25 Support Configuration Example" later in this chapter.

Configure DDR over Frame Relay

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 and ISDN interfaces and for rotary groups, and is available for in-band, DTR, and ISDN dialers.

Frame Relay supports multiple PVC connections over the same serial interface or ISDN B channel, but only one physical interface can be used (dialed, connected, and active) in a rotary group or with ISDN.

Configuration Restrictions

The following restrictions apply to DDR used over Frame Relay:


Note Frame Relay subinterfaces work the same on dial-up connections as they do on leased lines.

Configuration Overview

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 example, enter the IP address and mask, the IPX network number, and the AppleTalk cable range and zone.
As a minimum, you must enable Frame Relay encapsulation and decide whether you need to do static or dynamic address mapping. If you decide to do dynamic mapping, you do not need to enter a command because Inverse ARP is enabled by default. If you decide to do static mapping, you must enter Frame Relay mapping commands.
You can then configure various options as needed for your Frame Relay network topology.
At a minimum, you must decide and configure the interface for outgoing calls only, incoming calls only, or both outgoing and incoming calls.
You can also configure DDR for your routed protocols (as specified in the "Configure DDR for Routed Protocols" section of this chapter) and for snapshot routing (as specified in the "Configure Snapshot Routing" section of this chapter). You can also customize DDR on your router or access server (as described in the "Customize the DDR Network" section later in this chapter).

For examples of configuring various interfaces for DDR over Frame Relay, see the "Frame Relay Support Examples" section later in this chapter.

Configure DDR for Routed Protocols

DDR supports the following routed protocols: AppleTalk, Banyan VINES, DECnet, IP, Novell IPX, ISO CLNS, and XNS.

To configure DDR for a routed protocol, perform the tasks in the relevant section:

Configure DDR for AppleTalk

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 "Control 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.

Configure DDR for Banyan VINES

To configure DDR for Banyan VINES, perform one of the following tasks in global configuration mode:

Task Command
Specify a VINES standard access list.

or

Specify a VINES extended access list.

vines access-list access-list-number {permit | deny} source source-mask1

vines access-list access-list-number {permit | deny} source source-mask [destination] [destination-mask] 1


1 This command is documented in the "Banyan VINES Commands" chapter in the Network Protocols Command Reference, Part 2.

After you specify VINES standard or extended access lists, define DDR dialer lists as described in the "Control Access to a DDR Interface" section. 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.

You can configure Banyan VINES on DDR synchronous and ISDN interfaces, as well as dialer rotary groups.


Note The Banyan VINES "neighbor" command is not supported for LAPB and X.25 encapsulations.

See the "Control Access to a DDR Interface" section for more information about defining dialer lists.

For an example of configuring Banyan VINES over DDR, see the "Banyan VINES Configuration Example" section.

Configure DDR for DECnet

To configure DDR for DECnet, perform one of the following tasks in global configuration mode:

Task Command
Specify a DECnet standard access list.

or

Specify a DEcnet extended access list.

access-list access-list-number {permit | deny} source source-mask1

access-list access-list-number {permit | deny} source source-mask [destination] [destination-mask]1


1 This command is documented in the "DECnet Commands" chapter in the Network Protocols Command Reference, Part 2.

After you specify DECnet standard or extended access lists, define DDR dialer lists as described in the "Control Access to a DDR Interface" section. 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.

You classify DECnet control packets, including hello packets and routing updates, using one or more of the following commands: dialer-list protocol decnet_router-L1 permit, dialer-list protocol decnet_router-L2 permit, and dialer-list protocol decnet_node permit.

You can configure DECnet on DDR synchronous and ISDN interfaces, and dialer rotary groups.

See the "Control Access to a DDR Interface" section for more information about defining dialer lists. For an example of configuring DECnet over DDR, see the "DECnet Configuration Example" section later in this chapter.

Configure DDR for IP

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]1

access-list access-list-number {deny | permit} protocol source source-mask destination destination-mask [operator operand]1


1 This command is documented in the "IP Commands" chapter in the Network Protocols Command Reference, Part 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 in the Network Protocols Command Reference, Part 1.

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 in the Network Protocols Configuration Guide, Part 1 for more information.

For an example of configuring DDR for IP, see the "Configuring DDR in an IP Environment Example" section.

Configure ISO CLNS over DDR

To configure ISO CLNS for DDR, perform the following tasks, beginning in global configuration mode:

Task Command
Step 1 Specify one or more CLNS filters, repeating this command as needed to build the filter list associated with the filter name. clns filter-set sname [permit | deny] template1
Step 2 Specify the interface to apply the filter to. interface type number2
Step 3 Filter CLNS traffic going out of the interface, on the basis of the filter specified and named in Step 1. clns access-group name out1

1 This command is documented in the "ISO CLNS Commands" chapter in the Network Protocols Command Reference, Part 3.
2 This command is documented in the "Interface Commands" chapter in the Configuration Fundamentals Command Reference.

After you complete these CLNS-specific steps, define a dialer list for CLNS, as described in the "Control Access to a DDR Interface" section. 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. Use the access-group argument with this command, because ISO CLNS uses access groups but does not use access lists

You classify CLNS control packets, including hello packets and routing updates, using the dialer-list protocol clns_is permit and/or dialer-list protocol clns_es permit command.

You can configure ISO CLNS on DDR serial synchronous and ISDN interfaces, as well as dialer rotary groups.

See the "Control Access to a DDR Interface" section for more information about defining dialer lists.

For an example of configuring ISO CLNS over DDR, see the "ISO CLNS Configuration Example" section.

Configure DDR for Novell IPX

On DDR links for Novell IPX, the link may come up often even when all client sessions are idle because the server sends watchdog or keepalive packets to all the clients approximately every 5 minutes. You can configure a local router or 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. 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

1 This command is documented in the "Novell IPX Commands" chapter in the Network Protocols Command Reference, Part 2.

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


1 This command is documented in the "Novell IPX Commands" chapter in the Network Protocols Command Reference, Part 2.

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

1 This command is documented in the "Novell IPX Commands" chapter in the Network Protocols Command Reference, Part 2.

For detailed DDR for IPX configuration examples, see the "IPX over DDR Example" section in the "Configuring Novell IPX" chapter of the Network Protocols Configuration Guide, Part 1.

Configure XNS over DDR

To configure XNS for DDR, perform one of the following tasks in global configuration mode:

Task Command
Specify a standard XNS access list.


or

Specify an extended XNS access list.

access-list access-list-number {deny | permit}
source-network[.source-address  [source-address-mask]]
[
destination-network[.destination-address
[destination-address-mask]]]

access-list access-list-number {deny | permit} protocol [source-network[.source-host
[source-network-mask.]source-host-mask] source-socket [destination-network [.destination-host [destination-network-mask.destination-host-mask] destination-socket[/pep]]]
1


1 This command is documented in the "XNS Commands" chapter in the Network Protocols Command Reference, Part 3.

After you specify an XNS access list, define a DDR dialer list, as described in the "Control Access to a DDR Interface" section. 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.

You can configure XNS on DDR serial synchronous and ISDN interfaces, as well as dialer rotary groups.

See the "Control Access to a DDR Interface" section for more information about defining dialer lists. For an example of configuring XNS over DDR, see the "XNS Configuration Example" section.

Configure DDR for Transparent Bridging

The Cisco IOS software supports transparent bridging over DDR and provides you some flexibility in controlling access and configuring the interface.

To configure DDR for bridging, complete the tasks in the following sections:

For an example of configuring DDR for transparent bridging, see the "DDR for Transparent Bridging Examples" section.

Define the Protocols to Bridge

IP packets are routed by default unless they are explicitly bridged; all others are bridged by default unless they are explicitly routed.

To bridge IP packets, complete the following task in global configuration mode:

Task Command
Disable IP routing. no ip routing 1

1 This command is documented in the "IP Commands" chapter in the Configuration Fundamentals Command Reference.

If you choose not to bridge another protocol, use the relevant command to enable routing of that protocol. For more information about tasks and commands, refer to the relevant protocol chapter in either the Network Protocols Configuration Guide, Part 1 or the Network Protocols Configuration Guide, Part 2.

Specify the Bridging Protocol

You must specify the type of spanning tree bridging protocol to use and also identify a bridge group. To specify the spanning tree protocol and a bridge group number, complete the following task in global configuration mode:

Task Command
Define the type of spanning tree protocol and identify a bridge group. bridge bridge-group protocol {ieee | dec}1

1 This command is documented in the "Transparent Bridging Commands" chapter in the Bridging and IBM Networking Command Reference.

The bridge-group number is used when you configure the interface and assign it to a bridge group. Packets are bridged only among members of the same bridge group.

Control Access for Bridging

You can control access by defining any transparent bridge packet as interesting, or you can use the finer granularity of controlling access by Ethernet type codes. To control access for DDR bridging, complete one of the following tasks in global configuration mode:


Note Spanning tree bridge protocol data units (BPDUs) are always treated as uninteresting.

Permit All Bridge Packets

To identify all transparent bridge packets as interesting, complete the following task in global configuration mode:

Task Command
Define a dialer list that treats all transparent bridge packets as interesting. dialer-list dialer-group protocol bridge permit

Control Bridging Access by Ethernet Type Codes

To control access by Ethernet type codes, complete the following tasks in global configuration mode:

Task Command
Identify interesting packets by Ethernet type codes (access list numbers must be in the range 200-299). access-list access-list-number {permit | deny} type-code [mask]1
Define a dialer list for the specified access list. dialer-list dialer-group protocol bridge list access-list-number

1 This command is documented in the "Transparent Bridging Commands" chapter in the Bridging and IBM Networking Command Reference.

For a table of some common Ethernet types codes, see the "Ethernet Types Codes" appendix in the Bridging and IBM Networking Command Reference.

Configure an Interface for Bridging

You can configure serial interfaces or ISDN interfaces for DDR bridging. To configure an interface for DDR bridging, complete all the tasks in the following sections:

Specify the Interface

To specify the interface and thus enter interface configuration mode, complete the following task, starting in global configuration mode:

Task Command
Specify the serial or ISDN interface and enter interface configuration mode. interface type number1

1 This command is documented in the "Interface Commands" chapter in the Configuration Fundamentals Command Reference.

Configure the Destination

You can configure the destination by specifying a dial string for unauthenticated calls to a single site, or by specifying a dialer bridge map when you want to use authentication.

To configure the destination for bridging over a specified interface, complete the following task in interface configuration mode:

Task Command
Configure the dial string to call.
or
Configure a dialer bridge map.
dialer string dial-string

dialer map bridge [name hostname] [broadcast] dial-string[:isdn-subaddress]

Note You can define only one dialer bridge map for the interface. If you enter a different bridge map, the previous one is replaced immediately.

Assign the Interface to a Bridge Group

Packets are bridged only among interfaces that belong to the same bridge group. To assign an interface to a bridge group, complete the following task in interface configuration mode:

Task Command
Assign the specified interface to a bridge group. bridge-group bridge-group1

1 This command is documented in the "Transparent Bridging Commands" chapter in the Bridging and IBM Networking Command Reference.

Customize the DDR Network

Perform the tasks in the following sections as needed to customize DDR in your network:

Set Line-Idle Time

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

Set Idle Time for Busy Interfaces

The dialer fast idle timer is activated if there is contention for a line. Contention occurs when a line is in use, a packet for a different next hop address is received, and the busy line is required to send the competing packet.

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 timeout period, 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, another packet is transmitted to the currently connected destination, and it is classified as interesting, the fast-idle timer is restarted.

To 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 command applies both to inbound and outbound calls.

Set Line-Down Time

To set the length of time the 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 command applies both to inbound and outbound calls.

Set Carrier-Wait Time

To set the length of time an interface waits for the telephone service (carrier), perform the following task in interface configuration mode:

Task Command
Set the length of time the interface waits for the carrier to come up when a call is placed. dialer wait-for-carrier-time seconds

For asynchronous interfaces, this command sets the total time to wait for a call to connect. This time is set to allow for running the chat script.

Control Access to a DDR Interface 

Protocol access lists and dialer 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 dialer 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.


Note Access lists and dialer lists apply to outgoing interfaces.

Acceptable access list protocols include various routing protocols, plus bridging. With the dialer-list protocol list command form, you can also specify Banyan VINES, ISO CLNS, and XNS access lists. See the dialer-list protocol command in the Wide-Area Networking Command Reference for detailed information.

Before you perform the tasks outlined in this section, see the appropriate chapters in the Network Protocols Configuration Guide, Part 1 and the Network Protocols Configuration Guide, Part 2 for information about defining Banyan VINES, DECnet, IP, IPX, ISO CLNS, and XNS access lists. Define access lists as follows if you want to control access on DDR interfaces by access lists rather than by protocols:

Step 1 Associate a protocol or access list with the dialer access group.

Step 2 Set a dialer access group number or, for ISO CLNS, an access group name.

You can permit or deny access to an entire protocol, or you can specify an access list for more refined control. To associate a protocol or access list with a dialer group, perform the following task in global configuration mode:

Task Command
Associate a protocol access list number or access group name with the dialer group. dialer-list dialer-group protocol protocol-name {permit | deny | list access-list-number | access-group}
or
dialer-list dialer-group list access-list-number

Note For a given protocol and a given dialer group, only one access list can be specified in the dialer-list command.

For the dialer-list protocol list command form, acceptable access list numbers are

ISO CLNS does not use access lists, but does allow filters and access groups to be specified. For the dialer-list list command, Banyan VINES and ISO CLNS are not available.

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

Set Dialer Interface Priority

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 faster, more reliable modem. In this way, the higher-priority interface will be used as often as possible.

The range of values for n is 0 through 255. Zero is the default value and lowest priority; 255 is the highest priority. This command applies to outgoing calls only.

Configure a Dialer Hold Queue

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, hunt group leaders can be configured with a dialer hold queue. If a hunt group leader (of a rotary dialing group) 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.

Configure Bandwidth on Demand

You can configure a dialer rotary group to use additional bandwidth by placing additional calls to a single destination if the load for the interface exceeds a specified weighted value. Parallel communication links are established based on traffic load. The number of parallel links that can be established to one location is not limited.

To set the dialer load threshold for bandwidth on demand, perform the following task in interface configuration mode:

Task Command
Configure the dialer rotary group to place additional calls to a single destination, as indicated by interface load. dialer load-threshold load

Disable and Reenable DDR Fast Switching

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.

Reenable IP fast switching over a DDR interface.

Disable distributed IP fast switching over a DDR interface. This feature works in Cisco 7500 routers with a Versatile Interface Processor (VIP) card.

Enable distributed IP fast switching over a DDR interface This feature works in Cisco 7500 routers with a Versatile Interface Processor (VIP) card.

no ip route-cache1

ip route cache1

no ip route-cache distributed1



ip route-cache distributed1

Disable IPX fast switching over a DDR interface.

Reenable IPX fast switching over a DDR interface.

no ipx route-cache2

ipx route-cache2


1 This command is documented in the "IP Commands" chapter in the Network Protocols Command Reference, Part 1.
2 zThis command is documented in the "Novell IPX Commands" chapter in the Network Protocols Command Reference, Part 1.

Configure Legacy DDR Dial Backup

When you configure dial backup, you must first decide whether you want to back up the primary line when it goes down, when the 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 the Backup Interface

To configure dial backup, select an interface as a backup to a primary serial interface. The backup interface can be an ISDN interface or a different serial interface.

For a backup serial interface, an external data communications equipment (DCE) device, such as a modem attached to a circuit-switched service, must be connected to the backup serial interface. The external device must be capable of responding to a DTR signal (DTR active) by automatically dialing a connection to a preconfigured remote site.

To select a backup interface, perform the following task in interface configuration mode:

Task Command
Select a backup interface. backup interface type number
or
backup interface type slot/port
(For the Cisco 7000 or Cisco 7200 series)

Note When you use a Basic Rate Interface (BRI) with dial backup, neither of the B channels can be used while the interface is in a standby mode. In addition, when a BRI is 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 back up only one interface. For examples of selecting a backup line, see the "Dial Backup Using an Asynchronous Interface 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 5-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:

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 an Asynchronous Interface Example" and "Dial Backup Using DDR and ISDN Example" later in this chapter.

Monitor DDR Connections and Snapshot Routing

To monitor DDR connections and snapshot routing, perform the following tasks in privileged EXEC mode:

Task Command
Display general diagnostics about the DDR interface. show dialer [interface type number]
Display information about the ISDN interface. show interfaces bri 01
Terminate the snapshot routing quiet period on the client router within two minutes. clear snapshot quiet-time interface
Display information about snapshot routing parameters. show snapshot interface
Display status about the IPX interface. show ipx interface [type number]2
Display information about the IPX packets transmitted by the router or access server, including watchdog counters. show ipx traffic2
Display information about the AppleTalk packets transmitted by the router or access server. show appletalk traffic3
Display information about the Banyan VINES packets transmitted by the router or access server. show vines traffic4
Display information about the DECnet packets transmitted by the router or access server. show decnet traffic 5
Display information about the XNS packets transmitted by the router or access server. show xns traffic6
Clear the values of the general diagnostic statistics. clear dialer

1 This command is documented in the "ISDN Commands" chapter in the Wide-Area Networking Command Reference.
2 This command is documented in the "Novell IPX Commands" chapter in the Network Protocols Command Reference, Part 2.
3 This command is documented in the "AppleTalk Commands" chapter in the Network Protocols Command Reference, Part 2.
4 This command is documented in the "Banyan VINES Commands" chapter in the Network Protocols Command Reference, Part 3.
5 This command is documented in the "DECnet Commands" chapter in the Network Protocols Command Reference, Part 3
6 This command is documented in the "XNS Commands" chapter in the Network Protocols Command Reference, Part 3

Legacy DDR Configuration Examples

The examples provided in this section show various DDR configurations as follows:

Dial Backup Using an Asynchronous Interface Example

The following is an example for dial backup using the auxiliary port (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

Dial Backup Using DDR and ISDN Example

The following example of uses an ISDN interface to back up a serial interface:

interface serial 1
backup delay 0 0
backup interface bri 0
ip address 1.2.3.4 255.255.255.0
!
interface bri 0
ip address 1.2.3.5 255.255.255.0
dialer string 5551212
dialer-group 1
!
dialer-list 1 protocol ip permit

Note When you use a BRI interface for dial backup, neither of the B channels can be used while the interface is in a standby mode.

Note Dialing will occur only after a packet is received to be output on BRI 0. We recommend using the dialer-list command with the protocol and permit keywords specified to control access for dial backup. Using this form of access control specifies that all packets are interesting.

Configuring DDR in an IP Environment Example

The following example illustrates how to use DDR on an synchronous interface in an IP environment. You could use the same configuration 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 131.108.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 5551234
! 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 a router 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 131.108.29.0 131.108.126.2
ip route 131.108.1.0 131.108.126.2
ip local pool dialin 101.102.126.2 101.102.126.254

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 Routing Commands" chapter in the Network Protocols Command Reference, Part 1. Without this command, static routes to the hosts or network that the router can access with DDR will not be advertised to other routers with which the router is communicating. This behavior can block communication because some routes will not be known.

Configuring Multiple Destination Dial Strings Example

The following example demonstrates how to specify multiple destination dial strings (phone numbers):

interface serial 1
ip address 131.108.126.1 255.255.255.0
dialer in-band
dialer wait-for-carrier-time 100
pulse-time 1
dialer-group 1
dialer map ip 131.108.126.10 5558899
dialer map ip 131.108.126.15 5555555
!
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 

As in the "Configuring DDR in an IP Environment Example" section, a pulse time is assigned and a dialer access group specified.

The first dialer map command specifies that the number 555-8899 is to be dialed for IP packets with a next-hop-address value of 131.108.126.10. The second dialer map then specifies that the number 5555555 will be called when an IP packet with a next-hop-address value of 131.108.126.15 is detected.

Configuring Dialer Rotary Groups Example

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 131.108.2.1 255.255.255.0
ip address 131.126.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 131.108.2.5 name YYY 1415553434
dialer map ip 131.126.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

Dialing a Single Site or Multiple Sites Example

Assume that your configuration is as shown in Figure 21 and your router receives a packet with a next hop address of 1.1.1.1.


Figure 21: Sample Dialer String or Dialer Map Configuration


If the interface on your router 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 does 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

Using Chat Scripts Example

Figure 22 shows the following configuration:


Figure 22: Chat Script Configuration and Function


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

Writing and Implementing Chat Scripts Example

In the following example chat script, a pair of empty quotation marks (" ") means 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.*

Chat Scripts and Dialer Mapping Example

The following example shows a chat script dial and a chat script login. 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: myname word: mypassword ">"
                "slip default"
interface async 10
dialer in-band
dialer map ip 10.55.0.1 modem-script dial system-script login 96837890

When a packet is received for 10.55.0.1, the first thing that happens is that the modem script is implemented. Table 1 shows the functions that are implemented with each expect-send pair in the modem script called dial.


Table  1: Example Modem Script Execution  
Expect and Send Pair Implementation
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 quotation marks 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; " " would have indicated nothing followed by a carriage return.)

After the modem script is successfully executed, the login script is executed. Table 2 shows the functions that are executed with each expect-send pair in the system script called login.


Table  2: Example System Script Execution
Expect and Send Pair Implementation
ABORT invalid End the script execution if the message "invalid username or password" is displayed.
TIMEOUT 15 Wait up to 15 seconds.
name: myname Look for "name:" and send "billw." (Using just "name:" will help avoid any capitalization issues.)
word: mypassword Wait for "word:" and send the password.
">" "slip default" Wait for the ts prompt and put the line into SLIP mode with its default address.

System Scripts and Modem Scripts Example

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 1.2.3.4, the router will dial the 91800 number using the usrobotics-v32 script, matching the regular expression in the modem chat script. Then the router will run the unix-slip chat script as the system script to log in.

If there is traffic for 4.3.2.1, the router will dial 8899 using usrobotics-v32, matching both the modem script and modem chat script regular expressions. The router 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 1.2.3.4 system-script unix-slip 918005551212
dialer map ip 4.3.2.1 modem-script *-v32 system-script cisco-compressed 8899

Dial-on-Demand PPP Configuration Example

The following example shows a configuration for XXX, the local router shown in Figure 23 in which several aspects of DDR are used to provide DDR capabilities between local and remote routers. The following features are shown in this example:

See the "Interfaces Commands" chapter in the Configuration Fundamentals Command Reference for a description of the pulse-time command.

! Create a dialer interface with PPP encapsulation and CHAP authentication. 
interface dialer 1
ip address 131.108.2.1 255.255.255.0
ip address 131.126.4.1 255.255.255.0 secondary
encapsulation ppp
ppp authentication chap
! Enable dial-on-demand routing on the dialer interface.
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 131.108.2.5 name YYY 1415553434
dialer map ip 131.126.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 group 1. 
! The interface commands applied to dialer 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 23 shows a configuration in which local Router XXX and remote Routers YYY and ZZZ are using dial-on-demand routing, as configured in the previous example. In this configuration, remote Routers YYY and ZZZ can call Router XXX. Router XXX has dialer string information only for Router YYY and cannot call Router ZZZ.


Figure 23: Dial-on-Demand Routing Configuration


DTR Dialing Configuration Example

In the following example, Router A and Router B 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. (See Figure 24.)


Figure 24:
DTR Dialing through a PSTN


Configuration for Router A
interface serial 0
ip address 131.108.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
Configuration for Router B
interface serial 0
ip address 131.108.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

Snapshot Routing Examples

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
dialer map snapshot 2 4155556734
dialer map snapshot 3 7075558990

The following commands configure the server router:

interface serial 2
snapshot server 5 dialer

LAPB Support Configuration Example

In the following example, the router is configured for LAPB encapsulation and in-band dialing:

interface serial 0
ip address 131.108.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

X.25 Support Configuration Example

In the following example, a router is configured to support X.25 and DTR dialing:

interface serial 0
ip address 131.108.170.19 255.255.255.0
encapsulation x25
x25 address 12345
x25 map ip 131.108.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

Frame Relay Support Examples

The examples in this section present various combinations of interfaces, Frame Relay features, and DDR features.

Frame Relay Access with In-Band Dialing (V.25bis) and Static Mapping Example

In the following 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 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

Frame Relay Access with ISDN Dialing and DDR Dynamic Maps Example

The following example shows a BRI interface configured for Frame Relay and for IP, IPX, and AppleTalk routing. No static maps are defined because this setup relies on Frame Relay local management interface (LMI) signaling and Inverse ARP to determine the network addresses-to-DLCI mappings dynamically. (Because Frame Relay Inverse ARP is enabled by default, no command is required.)

interface BRI0
ip address 1.1.1.1 255.255.255.0
ipx network 100
appletalk cable-range 100-100 100.1
appletalk zone ISDN
no appletalk send-rtmps
encapsulation frame-relay IETF
dialer map ip 1.1.1.2 broadcast 4155551212
dialer map apple 100.2 broadcast 4155551212
dialer map ipx 100.0000.0c05.33ed broadcast 4085551234
dialer-group 1
!
access-list 101 deny igrp any host 255.255.255.255
access-list 101 permit ip any any
access-list 901 deny -1 FFFFFFFF 452
access-list 901 deny -1 FFFFFFFF 453
access-list 901 deny -1 FFFFFFFF 457
access-list 901 deny -1 FFFFFFFF 0 FFFFFFFF 452
access-list 901 deny -1 FFFFFFFF 0 FFFFFFFF 453
access-list 901 deny -1 FFFFFFFF 0 FFFFFFFF 457
access-list 901 permit -1
access-list 601 permit cable-range 100-100 broadcast-deny
access-list 601 deny other-access
!
dialer-list 1 protocol ip list 101
dialer-list 1 protocol novell list 901
dialer-list 1 protocol apple list 601

Frame Relay Access with ISDN Dialing and Subinterfaces Example

The following example shows a BRI interface configured for Frame Relay and for IP, IPX, and AppleTalk routing. Two logical subnets are used; a point-to-point subinterface and a multipoint subinterface are configured. Frame Relay Annex A (LMI type Q933a) and Inverse ARP are used.

interface BRI0
no ip address
encapsulation frame-relay
dialer string 4155551212
dialer-group 1
frame-relay lmi-type q933a
!
interface BRI0.1 multipoint
ip address 1.1.100.1 255.255.255.0
ipx network 100
appletalk cable-range 100-100 100.1
appletalk zone ISDN
no appletalk send-rtmps
frame-relay interface-dlci 100
frame-relay interface-dlci 110
frame-relay interface-dlci 120
!
interface BRI0.2 point-to-point
ip address 1.1.200.1 255.255.255.0
ipx network 200
appletalk cable-range 200-200 200.1
appletalk zone ISDN
no appletalk send-rtmps
frame-relay interface-dlci 200 broadcast IETF
!
access-list 101 deny igrp any host 255.255.255.255
access-list 101 permit ip any any
access-list 901 deny -1 FFFFFFFF 452
access-list 901 deny -1 FFFFFFFF 453
access-list 901 deny -1 FFFFFFFF 457
access-list 901 deny -1 FFFFFFFF 0 FFFFFFFF 452
access-list 901 deny -1 FFFFFFFF 0 FFFFFFFF 453
access-list 901 deny -1 FFFFFFFF 0 FFFFFFFF 457
access-list 901 permit -1
access-list 601 permit cable-range 100-100 broadcast-deny
access-list 601 permit cable-range 200-200 broadcast-deny
access-list 601 deny other-access
dialer-list 1 protocol ip list 101
dialer-list 1 protocol novell list 901
dialer-list 1 protocol apple list 601

AppleTalk Configuration Example

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 130.1.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 130.1.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 

Banyan VINES Configuration Example

In the following example, a router is configured for VINES and IP DDR with in-band dialing. The VINES access list does not allow RTP routing updates to place a call, but any other data packet is interesting.

vines routing BBBBBBBB:0001
!
hostname RouterA
!
username RouterB password 7 030752180500
username RouterC password 7 00071A150754
!
interface serial 0
ip address 131.108.170.19 255.255.255.0
encapsulation ppp
vines metrics 10
vines neighbor AAAAAAAA:0001 0
dialer in-band
dialer map ip 131.108.170.151 name RouterB broadcast 4155551234
dialer map vines AAAAAAAA:0001 name RouterC broadcast 4155551212
dialer-group 1
ppp authentication chap
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
!
vines access-list 107 deny RTP 00000000:0000 FFFFFFFF:FFFF 00000000:0000 FFFFFFFF:FFFF
vines access-list 107 permit IP 00000000:0000 FFFFFFFF:FFFF 00000000:0000 FFFFFFFF:FFFF
!
dialer-list 1 protocol ip list 101
dialer-list 1 protocol vines list 107

Although it is not used in this example, the dialer-list 1 list 101 command is still acceptable for IP.

DECnet Configuration Example

In the following example, a router is configured for DECnet DDR with in-band dialing:

decnet routing 10.19
!
username RouterB password 7 030752180531
!
interface serial 0
no ip address
decnet cost 10
encapsulation ppp
dialer in-band
dialer map decnet 10.151 name RouterB broadcast 4155551212
dialer-group 1
ppp authentication chap
pulse-time 1
!
access-list 301 permit 10.0 0.1023 0.0 63.1023
!
dialer-list 1 protocol decnet list 301

ISO CLNS Configuration Example

In the following example, a router is configured for CLNS DDR with in-band dialing:

username RouterB password 7 111C140B0E
clns net 47.0004.0001.0000.0c00.2222.00
clns routing
clns filter-set ddrline permit 47.0004.0001....
!
interface serial 0
no ip address 
encapsulation ppp
dialer in-band
dialer map clns 47.0004.0001.0000.0c00.1111.00 name RouterB broadcast 1212
dialer-group 1
ppp authentication chap
clns enable
pulse-time 1
!
clns route default serial 0
dialer-list 1 protocol clns list ddrline

XNS Configuration Example

In the following example, a router is configured for XNS DDR with in-band dialing. The access lists deny broadcast traffic to any host on any network, but allow all other traffic.

xns routing 0000.0c01.d8dd
username RouterB password 7 111B210A0F
interface serial 0
no ip address 
encapsulation ppp
xns network 10
dialer in-band
dialer map xns 10.0000.0c01.d877 name RouterB broadcast 4155551212
dialer-group 1
ppp authentication chap
pulse-time 1
!
access-list 400 deny -1 -1.ffff.ffff.ffff 0000.0000.0000
access-list 400 permit -1 10
!
dialer-list 1 protocol xns list 400

DDR for Transparent Bridging Examples

The following two examples differ only in the packets that cause calls to be placed. The first example specifies by protocol (any bridge packet is permitted to cause a call to be made); the second example allows a finer granularity by specifying the Ethernet type codes of bridge packets.

The first example configures the serial 1 interface for DDR bridging. Any bridge packet is permitted to cause a call to be placed.

no ip routing
!
interface Serial1
 no ip address
 encapsulation ppp
 dialer in-band
 dialer enable-timeout 3
 dialer map bridge name urk broadcast 8985
 dialer hold-queue 10
 dialer-group 1
 ppp authentication chap
 bridge-group 1
 pulse-time 1
!
dialer-list 1 protocol bridge permit
bridge 1 protocol ieee
bridge 1 hello 10

The second example also configures the serial 1 interface for DDR bridging. However, this example includes an access-list command that specifies the Ethernet type codes that can cause calls to be placed and a dialer list protocol list command that refers to the specified access list.

no ip routing
!
interface Serial1
 no ip address
 encapsulation ppp
 dialer in-band
 dialer enable-timeout 3
 dialer map bridge name urk broadcast 8985
 dialer hold-queue 10
 dialer-group 1
 ppp authentication chap
 bridge-group 1
 pulse-time 1
!
access-list 200 permit 0x0800 0xFFF8
!
dialer-list 1 protocol bridge list 200 
bridge 1 protocol ieee
bridge 1 hello 10

Set Up Two-Way Reciprocal Client-Server DDR without Authentication Example

You can set up two-way reciprocal dial-on-demand routing (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.

Remote Configuration

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

Local Configuration

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

Set Up Two-Way DDR with Authentication Example

You can set up two-way dial-on-demand routing (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.

Remote Configuration

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

Local Configuration

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

Set Up Hub-and-Spoke DDR with Authentication Example

You can set up dial-on-demand routing (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 25 illustrates a typical hub-and-spoke configuration.


Figure 25: Hub-and-Spoke DDR Configuration


This configuration is demonstrated in the following two subsections.

Remote Configuration

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

Local Configuration

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

Set Up Two-Way DDR for Novell IPX Example

You can set dial-on-demand routing (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.

Remote Configuration

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

Local Configuration

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

Configuration for Fully Meshed DDR for Novell (IP and IPX with Authentication) Example

You can set up fully meshed dial-on-demand routing (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 26.


Figure 26: Fully Meshed DDR Configuration for Novell


This configuration is demonstrated in the following example configuration for three fully meshed sites, which 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


hometocprevnextglossaryfeedbacksearchhelp
Copyright 1989-1998 © Cisco Systems Inc.