|
|
This chapter presents the decisions and preparations leading to a 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:
For a complete description of the global dialer commands in this chapter, refer to the "DDR Preparation Commands" chapter of the Dial Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
This section provides a flowchart of the decisions to be made before and while you configure DDR and notes to the flowchart.
Figure 105 presents the entire decision flowchart. The decision phases are shown in separate boxes. Numbers in parentheses refer to notes, which are located on the next page.
Notes to the Flowchart. 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 manuals. The numbers in this list correspond to the circled numbers in the flowchart.
The DDR chapters provide complete configuration information about the simple spoke and hub DDR configurations, about the Dialer Profiles implementation of DDR, and about preparations required for configuring asynchronous interfaces for DDR.
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 include
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 manual. You must also decide whether a simple DDR configuration meets your business needs or whether to add on other features.
The Dialer Profiles implementation of DDR is based on a separation between logical and physical interface configuration. Dialer Profiles also allows the logical and physical configurations to be bound together dynamically on a per-call basis.
Dialer Profiles is advantageous 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 (except encapsulation in the first phase of Dialer Profiles), when you want to bridge to many destinations, and for avoiding split horizon problem.
Most routed protocols are supported; however, Frame Relay, ISO CLNS, and LAPB are not supported.
For detailed Dialer Profiles information, see the "Configuring Peer-to-Peer DDR with Dialer Profiles" chapter.
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.
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 "Cost Control Solutions" and "Large-Scale Solutions" parts of this manual.
Some preparations are global in nature 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:
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 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:
To prepare for transparent bridging over DDR, complete the tasks in the following sections:
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 |
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 either the Network Protocols Configuration Guide, Part 1, Network Protocols Configuration Guide, Part 2, and Network Protocols Configuration Guide, Part 3.
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} |
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.
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] |
| Define a dialer list for the specified access list. | dialer-list dialer-group protocol bridge list access-list-number |
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, see the "Ethernet Types Codes" appendix in the Bridging and IBM Networking Command Reference.
| Task | Command |
|---|---|
| Define a dialer list that treats all transparent bridge packets as interesting. | dialer-list dialer-group protocol bridge permit |
DDR supports the following routed protocols: AppleTalk, Banyan VINES, DECnet, IP, Novell IPX, ISO CLNS, and XNS.
To prepare for routing a protocol over DDR, perform the tasks in the relevant section:
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.
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. See the "Configuring IP Addressing" chapter in the Network Protocols Configuration Guide, Part 1 for more information.
At a minimum, you must complete the following tasks.
To disable validation of source addresses, complete the following tasks beginning in global configuration mode:
| Task | Command |
|---|---|
| Specify the routing protocol; RIP, for example. | router rip |
| Disable validation of source addresses. | no validate-update-source |
| Specify the IP address. | network number |
For more information about IP routing protocols, see the Network Protocols Command Reference, Part 1.
To configure IP access lists, perform one of the following tasks in global configuration mode:
| Task | Command |
|---|---|
| Specify an IP standard access list. or Specify an IP extended access list. | access-list access-list-number {deny | permit} source [source-mask] access-list access-list-number {deny | permit} protocol source source-mask destination destination-mask [operator operand] |
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 Services Commands" chapter in the Network Protocols Command Reference, Part 1.
For an example of configuring DDR for IP, see the "Configuring a Legacy DDR Spoke" or "Configuring a Legacy DDR Hub" chapter.
You can configure IP routing on DDR asynchronous, synchronous serial, and ISDN interfaces, as well as dialer rotary groups.
To configure routing of IPX over DDR, you must complete both global and interface-specific tasks:
Step 1 Enable IPX routing globally.
Step 2 Enable IPX watchdog spoofing, or enable SPX keepalive spoofing on the interface.
To enable IPX routing, complete the following task in global configuration mode:
| Task | Command |
|---|---|
| Enable IPX routing. | ipx routing [node] |
To enable IPX watchdog spoofing on the interface, complete the following task in interface configuration mode:
| Task | Command |
|---|---|
| Enable IPX watchdog spoofing. | ipx watchdog-spoof |
To enable SPX keepalive spoofing, perform the following tasks in interface configuration mode:
| Task | Command |
|---|---|
| Enable SPX keepalive spoofing. | ipx spx-spoof |
| Set the idle time after which SPX spoofing begins. | ipx spx-idle-time delay-in-seconds |
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, see the "IPX over DDR Example" section in the "Configuring Novell IPX" chapter of the Network Protocols Configuration Guide, Part 1.
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 "Configuring a Legacy DDR Spoke" chapter or "Configuring a Legacy DDR Hub" chapter for more information and examples.
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] |
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 "Configuring a Legacy DDR Spoke" chapter or "Configuring a Legacy DDR Hub" chapter for more information and examples.
You can configure Banyan VINES on DDR asynchronous, synchronous serial, and ISDN interfaces, as well as dialer rotary groups.
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] |
You can configure DECnet on DDR asynchronous, synchronous serial, and ISDN interfaces, as well as dialer rotary groups.
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 name [permit | deny] template |
| Step 2 Specify the interface to apply the filter to. | interface type number |
| 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 out |
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 "Configuring a Legacy DDR Spoke" chapter or "Configuring a Legacy DDR Hub" chapter 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.
You must enable XNS routing and then define an access list.
To define an XNS access list, 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 |
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 "Configuring a Legacy DDR Spoke" chapter or "Configuring a Legacy DDR Hub" chapter for more information and examples.
You can configure XNS on DDR asynchronous, synchronous serial, and ISDN interfaces, as well as dialer rotary groups.
DDR supports the following routed protocols: AppleTalk, Banyan VINES, DECnet, IP, Novell IPX, ISO CLNS, and XNS.
| 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} |
For the dialer-list protocol list command form, acceptable access list numbers are
|
|