DDR Decision Flowchart
This section provides a flowchart of the decisions to be made before and while you configure DDR and also includes the flowchart.
Figure 1 presents the entire decision flowchart. The decision phases are shown in separate boxes. Numbers in parentheses refer to notes, which follow the figure.
Figure 1 Decisions and Implementation Flow to DDR
Flowchart Notes
The DDR chapters do not provide complete configuration information for most of the items in the following list. However, detailed information is available in other chapters and publications. The numbers in this list correspond to the circled numbers in the flowchart.
1. Configuration of the dial port and interface. The port, line, and interface are expected to be configured and operational before you configure DDR. See the relevant chapters in the “Preparing for Dial Access” part of this manual.
2. Encapsulation; including encapsulation for other WANs. See the “Configuring Media-Independent PPP and Multilink PPP” chapter of this publication for PPP encapsulation and refer to the Cisco IOS Wide-Area Networking Configuration Guide for sections on Frame Relay and X.25.
3. Bridging configurations. Refer to the Cisco IOS Bridging and IBM Networking Configuration Guide.
4. Routed protocols to be supported. See the protocol-specific chapters and publications.
5. Dialer profiles and legacy DDR are described in different chapters of the “Dial-on-Demand Routing” part of this publication.
6. Complex DDR configurations. Refer to the chapter “Configuring Media-Independent PPP and Multilink PPP” in this publication.
The DDR chapters provide complete configuration information about the simple hub-and-spoke DDR configurations, about the dialer profiles implementation of DDR, and about preparations required for configuring asynchronous interfaces for DDR.
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, refer to 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, refer to 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, refer to 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 “How to Configure Dialer Profiles” 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.
Global and Interface Preparations for DDR
Some preparations are global and some depend on the type of interface you will configure for DDR. 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:
- If you choose to bridge the protocol, decide whether to allow bridge packet access by Ethernet type codes or to permit all bridge packets across the link. Allowing access by Ethernet type codes requires you to define a bridging access list in global configuration mode.
Allowing all bridge packets to trigger calls across a dial-on-demand link to a single destination is a DDR-dependent task addressed in the “Configure Dialer Access Lists to Trigger Outgoing Calls” section of both the “Configuring Legacy DDR Spokes” and “Configuring Legacy DDR Hubs” chapters in this publication.
Bridging to multiple destinations requires dialer profiles.
- If you choose to route the protocol:
– Define one or more access lists for the selected routed protocol to determine which packets should be permitted or denied access to the dial-on-demand link.
Allowing those packets to trigger calls across a dial-on-demand link is a DDR-dependent task addressed in the “Configure Dialer Access Lists to Trigger Outgoing Calls” section of both the “Configuring Legacy DDR Spokes” and “Configuring Legacy DDR Hubs” chapters in this publication.
– Define an appropriate dialer list for the protocol.
– Disable validation of source addresses, if you decide to configure dialer profiles.
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
To prepare for transparent bridging over DDR, complete the tasks in the following sections:
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:
|
|
Router(config)# 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 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:
|
|
Router(config)# 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:
|
|
|
Step 1 |
Router(config)# access-list access-list-number { permit | deny } type-code [ mask ] |
Identifies interesting packets by Ethernet type codes (access list numbers must be in the range 200–299). |
Step 2 |
Router(config)# dialer-list dialer-group protocol bridge list access-list-number |
Defines a dialer list for the specified access list. |
Packets with a specified Ethernet type code can trigger outgoing calls. Spanning tree bridge protocol data units (BPDUs) are always treated as uninteresting and cannot trigger calls.
For a table of some common Ethernet types codes, refer to the “Ethernet Types Codes” appendix in the Cisco IOS Bridging and IBM Networking Command Reference.
To identify all transparent bridge packets as interesting, use the following command in global configuration mode:
|
|
Router(config)# dialer-list dialer-group protocol bridge permit |
Defines a dialer list that treats all transparent bridge packets as interesting. |
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
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
IP routing is enabled by default on Cisco routers; thus no preparation is required simply to enable it. You might, however, need to decide your addressing strategy and complete other global preparations for routing IP in your networks. 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. Refer to the “Configuring IP Addressing” chapter in the Cisco IOS IP Configuration Guide for more information.
At a minimum, you must complete the following tasks:
- Disable validation of source addresses.
- Configure one or more IP access lists before you refer to the access lists in DDR dialer-list commands to specify which packets can trigger outgoing calls.
To disable validation of source addresses, use the following commands in global configuration mode:
|
|
Router(config)# router rip |
Specifies the routing protocol; RIP, for example. |
Router(config)# no validate-update-source |
Disables validation of source addresses. |
Router(config)# network number |
Specifies the IP address. |
For more information about IP routing protocols, refer to the Cisco IOS IP Configuration Guide.
To configure IP access lists, use one of the following commands in global configuration mode:
|
|
Router(config)# access-list access-list-number {deny | permit} source [ source-mask ] or Router(config)# access-list access-list-number { deny | permit } protocol source source-mask destination destination-mask [ operator operand ] |
Specifies an IP standard access list.
Specifies an IP extended access list. |
You can also use simplified IP access lists that use the any keyword instead of the numeric forms of source and destination addresses and masks. Other forms of IP access lists are also available. For more information, refer to the “IP Services Commands” chapter in the Cisco IOS IP Configuration Guide.
For an example of configuring DDR for IP, see the chapters “Configuring a Legacy DDR Spoke” or “Configuring a Legacy DDR Hub” in this publication.
You can configure IP routing on DDR asynchronous, synchronous serial, and ISDN interfaces, as well as dialer rotary groups.
Configuring Novell IPX Routing
To configure routing of IPX over DDR, you must complete both global and interface-specific tasks:
- Enable IPX routing globally.
- Enable IPX watchdog spoofing, or enable Sequenced Packet Exchange (SPX) keepalive spoofing on the interface.
To enable IPX routing, use the following command in global configuration mode:
|
|
Router(config)# ipx routing [ node ] |
Enables IPX routing. |
To enable IPX watchdog spoofing on the interface, use the following command in interface configuration mode:
|
|
Router(config-if)# ipx watchdog-spoof |
Enables IPX watchdog spoofing. |
To enable SPX keepalive spoofing, use the following commands in interface configuration mode:
|
|
Router(config-if)# ipx spx-spoof |
Enables SPX keepalive spoofing. |
Router(config-if)# ipx spx-idle-time delay-in-seconds |
Sets the idle time after which SPX spoofing begins. |
You can configure IPX routing on DDR asynchronous, synchronous serial, and ISDN interfaces, as well as dialer rotary groups.
For detailed DDR for IPX configuration examples, refer to the section “IPX over DDR Example” in the “Configuring Novell IPX” chapter of the Cisco IOS AppleTalk and Novell IPX Configuration Guide.
Configuring AppleTalk Routing
You must enable AppleTalk routing and then specify AppleTalk access lists. After you specify AppleTalk access lists, define 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.
You can configure AppleTalk routing on DDR asynchronous, synchronous serial, and ISDN interfaces, as well as dialer rotary groups.
See the chapters “Configuring a Legacy DDR Spoke” or “Configuring a Legacy DDR Hub” for more information and examples.
Configuring Banyan VINES Routing
To configure DDR for Banyan VINES, use one of the following commands in global configuration mode:
|
|
Router(config)# vines access-list access-list-number { permit | deny } source source-mask1 or Router(config)# 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.
Note The Banyan VINES neighbor command is not supported for LAPB and X.25 encapsulations.
Configuring DECnet Routing
To configure DDR for DECnet, use one of the following commands in global configuration mode:
|
|
Router(config)# access-list access-list-number { permit | deny } source source-mask1 or Router(config)# access-list access-list-number { permit | deny } source source-mask [ destination ] [ destination-mask ] |
Specifies a DECnet standard access list.
Specifies a DECnet extended access list. |
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.
You can configure DECnet on DDR asynchronous, synchronous serial, and ISDN interfaces, as well as dialer rotary groups.
Configuring ISO CLNS Routing
To configure ISO CLNS for DDR, use the following commands beginning in global configuration mode:
|
|
|
Step 1 |
Router(config)# clns filter-set name [ permit | deny ] template |
Specifies one or more CLNS filters, repeating this command as needed to build the filter list associated with the filter name. |
Step 2 |
Router(config)# interface type number |
Specifies the interface to apply the filter to and begins interface configuration mode. |
Step 3 |
Router(config-if)# clns access-group name out |
Filters CLNS traffic going out of the interface, on the basis of the filter specified and named in Step 1. |
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.
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 asynchronous, synchronous serial, and ISDN interfaces, as well as dialer rotary groups.
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:
|
|
Router(config)# access-list access-list-number { deny | permit } source-network [. source-address [ source-address-mask ]] [ destination-network [. destination-address [ destination-address-mask ]]] or Router(config)# 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 ]]] |
Specifies a standard XNS access list. Specifies an extended XNS access list. |
After you specify an XNS access list, define a DDR dialer list. 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 XNS on DDR asynchronous, synchronous serial, and ISDN interfaces, as well as dialer rotary groups.
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:
|
|
Router(config)# 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. |
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 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