Table of Contents

DDR Decision Flowchart
DDR Topology Decisions
DDR-Independent Implementation Decisions
DDR-Dependent Implementation Decisions

Dialer Profiles
Legacy DDR
Simple or Complex DDR Configuration

Global and Interface Preparations for DDR

Global Preparations
Preparations Depending on the Selected Interface Type

Preparations for Routing or Bridging over DDR

Preparing for Transparent Bridging over DDR

Defining the Protocols to Bridge
Specifying the Bridging Protocol
Controlling Bridging Access

Preparing for Routing over DDR

Configuring the Protocol for Routing and Access Control
Associating the Protocol Access List with a Dialer Group

Legacy DDR Configuration Examples

Point-to-Point DDR Without Authentication
Point-to-Point DDR with Authentication

Preparing to Configure DDR

This chapter presents the decisions and preparations leading to a dial-on-demand routing (DDR) configuration and shows where some advanced features fit into the DDR configuration steps. It distinguishes between the topology decisions and the implementation of the decisions. In the implementation phase, it distinguishes the DDR-independent decisions from the DDR-dependent decisions.

This chapter provides the following information:

• DDR Decision Flowchart---A flowchart of topology and implementation decisions you will need to make before you configure DDR.

• DDR Topology Decisions, DDR-Independent Implementation Decisions, and DDR-Dependent Implementation Decisions---References to sources of detailed information for the configuration steps associated with each decision.

• Global and Interface Preparations for DDR---Brief description indicating which preparations are global and which are interface-specific.

• Preparations for Routing or Bridging over DDR---A description of the required steps to be completed for bridging or routing over DDR.

The section "Legacy DDR Configuration Examples" at the end of this chapter provides examples of configuring DDR in your network, and includes line configuration and chat script samples.

For a complete description of the global dialer commands in this chapter, refer to the Cisco IOS Dial Services Command Reference publication. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

DDR Decision Flowchart

This section provides a flowchart of the decisions to be made before and while you configure DDR, and notes to the flowchart.

Figure 62 presents the entire decision flowchart. The decision phases are shown in separate boxes. Numbers in parentheses refer to notes, which follow the figure.

DDR Topology Decisions

Topology decisions determine which routers will use DDR, which media and interfaces each one will use for DDR, and how each interface will function when using DDR. For example, if you choose a hub-and-spoke topology, one router will communicate with multiple routers. You must decide whether that router will use one interface or multiple interfaces for DDR, and whether it will receive calls only (forcing the spokes to initiate and bear the cost of calls). If it will use multiple interfaces, you must decide whether they will be of different types or the same type.

DDR-Independent Implementation Decisions

DDR-independent implementation decisions include the following:

• Using a specific interface or combination of interfaces for DDR.

For complete configuration steps for the various media and interfaces, see the chapters in the "Dial-In Port Setup" part of this publication.

• Using nondefault encapsulations.

The default encapsulation is High-Level Data Link Control (HDLC). However, PPP is widely used for situations in which authentication is desired, especially situations in which an interface will receive calls from multiple sites. Detailed PPP encapsulation requirements are described in the "Configuring Media-Independent PPP and Multilink PPP" and "Configuring Asynchronous PPP and SLIP" chapters of this publication.

If you decide to send DDR traffic over Frame Relay, X.25, or Link Access Procedure, Balanced (LAPB) networks, the interface must be configured with the appropriate encapsulation. For configuration details, see the related chapters in the Cisco IOS Wide-Area Networking Configuration Guide.

• Routing or bridging the DDR traffic.

Legacy DDR supports bridging to only one destination, but the dialer profiles support bridging to multiple destinations.

If you decide to bridge traffic over a dial-on-demand connection, configure the interface for transparent bridging. For detailed information, see the "Configuring Transparent Bridging" chapter of the Cisco IOS Bridging and IBM Networking Configuration Guide.

• Supporting one or more specific routed protocols, if you decide to route traffic.

Depending on the protocol, you do need to control access by entering access lists and to decide how to support network addressing on an interface to be configured for DDR. You might also need to spoof keepalive or other packets. For configuration details, see the related network protocol chapters in the appropriate network protocols configuration guide, such as the Cisco IOS AppleTalk and Novell IPX Configuration Guide.

DDR-Dependent Implementation Decisions

You must decide whether to implement legacy DDR or the newer dialer profiles; both are documented in the "Dial-on-Demand Routing" part of this publication. You must also decide whether a simple DDR configuration meets your business needs or whether to add other features.

Dialer Profiles

The dialer profiles implementation of DDR is based on a separation between logical and physical interface configuration. Dialer profiles also allow the logical and physical configurations to be bound together dynamically on a per-call basis.

Dialer profiles are advantageous in the following situations:

• When you want to share an interface (ISDN, asynchronous, or synchronous serial) to place or receive calls.

• When you want to change any configuration on a per-user basis.

• When you want to maximize ISDN channel usage using the Dynamic Multiple Encapsulations feature to configure various encapsulation types and per-user configurations on the same ISDN B channel at different times according to the type of call.

• When you want to bridge to many destinations, and for avoiding split horizon problem.

Most routed protocols are supported; however, International Organization for Standardization Connectionless Network Service (ISO CLNS) is not supported.

If you decide to configure dialer profiles, you must disable validation of source addresses for the routed protocols you support.

For detailed dialer profiles information, see the "Configuring Peer-to-Peer DDR with Dialer Profiles" chapter in this publication. For more information about Dynamic Multiple Encapsulations, see the "Dialer Profiles Configuration Task List" section in that chapter.

Legacy DDR

Legacy DDR is powerful and comprehensive, but its limitations affect scaling and extensibility. Legacy DDR is based on a static binding between the per-destination call specification and the physical interface configuration.

However, legacy DDR also has many strengths. It supports Frame Relay, ISO CLNS, LAPB, snapshot routing, and all routed protocols that are supported on Cisco routers. By default, legacy DDR supports fast switching.

For information about simple legacy DDR spoke configurations, see the "Configuring Legacy DDR Spokes" chapter. For information about simple legacy DDR hub configurations, see the "Configuring Legacy DDR Hubs" chapter. Both chapters are in this publication.

Simple or Complex DDR Configuration

You must also decide whether to implement a simple DDR configuration---whether it is a simple point-to-point (spoke-to-spoke) layout or a simple hub-and-spoke layout---or to add on features that make the implementation more complex. Add-on features include dial backup, bandwidth on demand, application of the Bandwidth Allocation Control Protocol (BACP), Multilink PPP, and many others.

For information about add-on features, see the chapters in the "Large-Scale Dial Solutions" and "Cost Control Solutions" parts of the Cisco IOS Dial Services Configuration Guide: Network Services publication.

Global and Interface Preparations for DDR

Some preparations are global and some depend on the type of interface you will configure for DDR.

Global Preparations

After you have made the required global decision whether to bridge or to route a specified protocol over a dial-on-demand link, you can make the following preparations:

Preparations Depending on the Selected Interface Type

The steps shown in this chapter assume that you have also completed the required preparatory steps for the type of interface you will configure for DDR:

• The interface is installed, the cable is connected as needed, and operational.

• Chat scripts are ready, as needed, for any asynchronous interfaces and modem scripts have been assigned to the relevant asynchronous lines.

• Asynchronous lines and modems are configured and operational, as needed.

• Any ISDN line that will be used for DDR is properly provisioned and running.

• You have decided which interfaces and how many interfaces are to be configured for DDR, and what functions each interface will perform.

Preparations for Routing or Bridging over DDR

The following tasks are DDR-independent and can be completed before you configure DDR. Minimal tasks required for each item are presented in this chapter. For detailed information about bridging, routing, and wide-area networking configurations, refer to the appropriate chapters in other manuals of the Cisco IOS documentation set.

Complete the following minimal tasks for the global decisions you have made:

• Preparing for Transparent Bridging over DDR (As Required)

• Preparing for Routing over DDR (As Required)

Preparing for Transparent Bridging over DDR

To prepare for transparent bridging over DDR, complete the tasks in the following sections:

• Defining the Protocols to Bridge (As Required)

• Specifying the Bridging Protocol (As Required)

• Controlling Bridging Access (As Required)

Defining 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, use the following command in global configuration mode:

Command	Purpose
no ip routing	Disables IP routing.

If you choose not to bridge another protocol supported on your network, use the relevant command to enable routing of that protocol. For more information about tasks and commands, refer to the relevant protocol chapter in the appropriate network protocols configuration guide, such as the Cisco IOS AppleTalk and Novell IPX Configuration Guide or Cisco IOS IP and IP Routing Configuration Guide.

Specifying 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, use the following command in global configuration mode:

Command	Purpose
bridge bridge-group protocol {ieee | dec}	Defines the type of spanning tree protocol and identifies a bridge group.

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.

Controlling Bridging Access

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 by Ethernet type codes, use the following commands in global configuration mode:

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

Preparing for Routing over DDR

DDR supports the following routed protocols: AppleTalk, Banyan VINES, DECnet, IP, Internet Protocol Exchange (IPX), ISO CLNS, and Xerox Network Systems (XNS).

To prepare for routing a protocol over DDR, perform the tasks in the relevant section:

• Configuring the Protocol for Routing and Access Control (As Required)

• Associating the Protocol Access List with a Dialer Group (As Required)

Configuring the Protocol for Routing and Access Control

This section specifies the minimal steps required to configure a protocol for routing over DDR. For more options and more detailed descriptions, refer to the relevant protocol chapter.

Configuring IP Routing

Configuring Novell IPX Routing

Configuring AppleTalk Routing

Configuring Banyan VINES Routing

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

Command	Purpose
vines access-list access-list-number {permit | deny} source source-mask1 or vines access-list access-list-number {permit | deny} source source-mask [destination] [destination-mask]	Specifies a VINES standard access list. Specifies a VINES extended access list.

After you specify VINES standard or extended access lists, 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 chapters "Configuring a Legacy DDR Spoke" or "Configuring a Legacy DDR Hub" for more information and examples.

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

---

NoteThe Banyan VINES neighbor command is not supported for LAPB and X.25 encapsulations.

---

Configuring DECnet Routing

After you specify DECnet standard or extended access lists, 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 chapters "Configuring a Legacy DDR Spoke" or "Configuring a Legacy DDR Hub" in this publication for more information and examples.

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.

Configuring ISO CLNS Routing

To configure ISO CLNS for DDR, use the following commands beginning in global configuration mode:

After you complete these CLNS-specific steps, define a dialer list for CLNS. 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. See the chapters "Configuring a Legacy DDR Spoke" or "Configuring a Legacy DDR Hub" in this publication for more information and examples.

Configuring XNS Routing

You must enable XNS routing and then define an access list. To define an XNS access list, use one of the following commands in global configuration mode:

Associating the Protocol Access List with a Dialer Group

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

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

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

---

NoteFor 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 as follows:

• Banyan VINES, DECnet, IP, and XNS standard and extended access list numbers

• Novell IPX standard, extended, and SAP access list numbers

• AppleTalk access lists numbers

• Bridge type codes

Legacy DDR Configuration Examples

The examples in this section show the following DDR configurations:

• Point-to-Point DDR Without Authentication

• Point-to-Point DDR with Authentication

Point-to-Point DDR Without Authentication

The following example sets up two-way reciprocal DDR without authentication; the client and server have dial-in access to each other.

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
peer default ip address 172.30.45.1
encapsulation 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
script dialer 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
peer 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
peer 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
encapsulation 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
script dialer generic

Point-to-Point DDR with Authentication

The following example sets up two-way DDR with authentication; 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 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
peer default ip address 172.30.45.1
encapsulation 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
script dialer 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
peer default ip address 172.30.45.2
dialer rotary-group 1
!
interface async 8
async mode dedicated
peer default ip address 172.30.45.2
dialer rotary-group 1
!
interface dialer 1
ip address 172.30.45.2 255.255.255.0
encapsulation 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
script dialer generic

Posted: Tue Jul 18 13:22:50 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.