Configuring DDR

This chapter describes how to configure your router 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 Router Products Command Reference publication.

Cisco's Implementation of Dial Backup and DDR

Dial backup provides protection against WAN downtime by allowing you to configure a backup serial line circuit-switched connection. Dial backup software keeps the secondary line inactive (DTR inactive) until one of the following conditions is met:

• The primary line goes down.

• The transmitted traffic load on the primary line exceeds a defined limit.

When the software detects a lost Carrier Detect signal from the primary line device or finds that the line protocol is down, it activates DTR on the secondary line. At that time, the DCE must be set to dial the remote site. When the connection is made, the routing protocol defined for the serial line will take over the task of transmitting traffic over the dialup line.

DDR provides network connections across the Public Switched Telephone Network (PSTN). Traditionally, networks have been interconnected using dedicated lines for wide-area network (WAN) connections. With DDR, you can use modems, Integrated Service Data Network (ISDN) terminal adapters (TAs), or integrated ISDN capabilities to establish low-volume, periodic network connections over public circuit-switched networks. You can also establish dial-up connections over X.25 or Frame Relay packet-switched networks by using LAPB, X.25, or Frame Relay encapsulations.

The following protocols can be routed over DDR: AppleTalk, Banyan VINES, CLNS, DECnet, IP, IPX, and XNS. For more information see the appropriate protocol configuration chapters.

Synchronous and asynchronous interfaces can be configured for DDR connections to one or more destination networks. When a packet is received for a remote network, the router uses dialing commands to send the phone number of the destination network to a modem. The modem (DCE device) then dials the destination DCE device and establishes a connection.

Figure 8-1 illustrates a typical DDR interconnection configuration.

Fast Call Rerouting for ISDN

When DDR calls using an ISDN interface are not accepted, dialer is able to place the call again or proceed to other calls almost immediately, and does not have to wait for the dialer wait-for-carrier timer to expire. The ISDN software learns within a few seconds that a call was not accepted and always informs the dialer software, thus greatly reducing delays.

This feature is automatically enabled for all ISDN interfaces when the router software begins to run.

You can still modify the dialer wait-for-carrier timer for DDR interfaces, and the show dialer command still shows the destination number, if connected.

DDR Fast Switching

In the past, only process switching was available on interfaces configured for DDR. Process switching provided an acceptable level of performance because DDR was used on low-speed lines. Now, however, fast switching is required to take advantage of ISDN PRI and multiple BRI platforms.

Fast switching is enabled by default on DDR interfaces. It is enabled for two routed protocols, IP and IPX, and for two encapsulations, HDLC and PPP.

Fast-switching can be disabled and reenabled on a protocol-by-protocol basis on a DDR interface. For information on disabling and reenabling fast switching of protocols, see the "Disable and Reenable DDR Fast Switching" section later in this chapter.

Placing Calls Using DDR

On the router, DDR places calls using the following methods: 

• Chat scripts on the auxiliary port

• V.25bis over synchronous interfaces

• DTR dialing for synchronous interfaces

Chat Scripts on the Auxiliary Port

A chat script is a string of text that defines the login "conversation" that occurs between two systems. It consists of expect-send pairs that define the string that the local system expects to receive from the remote system and what the local system should send as a reply.

On asynchronous lines, our routers support chat scripts used to send commands for modem dialing and logging on to remote systems. To dial a call on an asynchronous line, a chat script must be defined. If multiple chat scripts are defined, regular expressions are used for powerful pattern matching to select between many scripts. See the "Regular Expressions" appendix in the Router Products Command Reference publication for information about regular expressions.

V.25bis over Synchronous Interfaces

Our routers support connections from the synchronous serial interface to any DCE device that supports V.25bis. These devices include ISDN TAs for ISDN B-channel connections. V.25bis is an International Telecommunication Union Telecommunication Standardization Sector (ITU-T) recommendation for initiating calls using in-band signaling. Depending on the type of modem or CSU/DSU you are using, ITU-T V.25bis options might be supported.

The V.25bis specification describes two modes of establishing or receiving calls: the direct call mode and the addressed call mode. Routers support connections using the addressed call mode and synchronous, bit-oriented operation. The addressed call mode allows control signals and commands to be sent over the DCE data interface to establish and terminate calls. These commands are packaged in High-Level Data Link Control (HDLC) synchronous data frames.

Devices used by the router for dialing out must support certain hardware signals in addition to V.25bis. When the router drops DTR, the device must disconnect any calls that are currently connected. When the device connects to the remote end, Data Carrier Detect (DCD) must be automatically asserted.

Table 8-1 lists V.25bis options. The V.25bis options are supported in the dial string (telephone number) only if you have enabled DDR using the dialer in-band command. These options are not supported in the dial string for native ISDN Basic Rate Interfaces (BRIs). The functions of these options are nation-specific, and they might have different implementations in your country. Refer to your modem or ISDN TA manual for a list of supported options.

DTR Dialing for Synchronous Interfaces

Our routers also support connections from synchronous serial lines through non-V.25bis modems. Routers connected by non-V.25bis modems must use data terminal ready (DTR) EIA signaling only.

For more information about configuring the router to support DTR dialing, see the "Configure Calls to a Single Site" section later in this chapter.

Controlling Access for DDR

DDR supports a variety of security and access control methods including the following:

• Dialer access lists and dialer access groups--Based on the access lists configured, access groups control access for DDR.

Packets that are permitted entry according to the access list are identified as "interesting" or "packets of interest." Packets that are not permitted entry or are denied entry by an access list are deemed "uninteresting."

A router activates the dial-on-demand feature when it receives an interesting packet destined for a location that can be reached over a dialed connection through a PSTN. After the router dials the destination phone number and establishes a connection, packets can be transmitted. When the transmission is complete, after a configured period of line time during which there is no interesting traffic on the line, the line is automatically disconnected.

• Address mapping--Interfaces can be configured to map a next hop address to a phone number. This allows the router to forward packets to the correct destinations and to determine if a connection is already established to that destination.

• CHAP--Access control using Challenge Handshake Authentication Protocol (CHAP) can be configured on serial interfaces that have PPP encapsulation enabled. CHAP reduces the risk of security violations on your router. CHAP also serves a method to identify incoming calls.

Dial Backup Configuration Task List

When you configure dial backup, you must first decide whether you want to back up when the primary line goes down, when traffic load on the primary line exceeds the defined threshold, or both. The tasks you perform depend on your decision. Perform one or more of the tasks in the following sections to configure dial backup:

• Select Backup Line

• Define the Traffic Load Threshold

• Define Backup Line Delays

Select Backup Line

To configure dial backup, set a secondary serial interface as a backup to a primary serial interface. An external data communications equipment (DCE) device, such as a modem attached to a circuit-switched service, must be connected to the secondary serial interface. The external device must be capable of responding to a DTR signal (DTR active) by auto-dialing a connection to a preconfigured remote site. To select a backup line, perform the following task in interface configuration mode:

The interface specified in the backup interface command can only back up one interface. For examples of selecting a backup line, see the "Dial Backup Using the Auxiliary Port 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 five-minute moving average. If this average exceeds the value you set for the line, the secondary line is activated and, depending upon how the line is configured, some or all of the traffic will flow onto the secondary dialup line.

To define how much traffic should be handled at one time on an interface, perform the following task in interface configuration mode:

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:

• A delay that applies after the primary line goes down but before the secondary line is activated

• A delay that applies after the primary line goes up but before the secondary line is activated

To define these delays, perform the following task in interface configuration mode:

For examples of how to define backup line delays, see the sections "Dial Backup Using the Auxiliary Port Example" and "Dial Backup Using DDR and ISDN Example" later in this chapter.

DDR Configuration Task Overview

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

• Specify line speed.

• Set flow control, if any.

• Specify your modem type.

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

• Configure an Interface to Place Calls

• Configure an Interface to Receive Calls

• Configure an Interface to Place and Receive Calls

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

• Configure Multilink PPP

• Configure PPP Callback

• Configure Snapshot Routing

• Configure DDR over LAPB

• Configure DDR over X.25

• Configure DDR over Frame Relay

• Configure DDR for Routed Protocols

• Configure DDR for Transparent Bridging

• Customize the DDR Network

• Monitor DDR Connections and Snapshot Routing

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

Step 1 Create chat scripts (asynchronous interfaces only).

Step 2 Specify a chat script for DDR (asynchronous interfaces only).

Step 3 Configure to call a single site or multiple sites.

Step 4 Configure calling from dialer rotary groups.

The following sections describe these tasks.

Create Chat Scripts for Asynchronous Interfaces

You must define a chat script for dialing out on asynchronous lines, specifically the asynchronous interface on the auxiliary port. Chat scripts are used to send commands for modem dialing and logging on to remote systems.

To create a chat script, perform the following task in global configuration mode:

It is recommended that you write one chat script (a "modem" chat script) for placing a call and another one (a "system" or "login" chat script) to log onto remote systems, where required.

For an example of how to use chat scripts, see "Using Chat Scripts Example" later in this chapter.

Suggested Chat Script Naming Conventions

A suggested chat script naming convention is as follows:

In other words, the syntax of the chat-script command becomes the following:

For example, if you have a Telebit t3000 modem that uses V.32bis modulation, you would name your chat script as follows:

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 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 for DDR

After a chat script has been defined as described in the "Configuring Terminal Lines and Modem Support" chapter of this publication, it must be applied to a line or an interface before it can be used. To specify a chat script for a line, perform the following task in line configuration mode:

A maximum of one script dialer command can be configured per line. The chat script naming convention described in the "Configuring Terminal Lines and Modem Support" chapter of this publication allows you to specify a chat script by the type of the modem attached to that line as follows:

It is recommended that one chat script (a "dialer" chat script) be written for placing a call and another chat script (a "system" or "login" chat script) be written to log in to remote systems, where required.

UNIX-style regular expressions are used to match patterns and select between many scripts. This will be useful if you specify modem scripts on an interface that is used to dial multiple destinations. Dialing multiple destinations is described in the "Configure Calls to Multiple Sites" section. Regular expressions are described in the "Regular Expressions" appendix of the Router Products Command Reference publication.

You can also assign chat scripts to asynchronous interfaces for purposes other than DDR. For more information, refer to the chapter "Configuring Terminal Lines and Modem Support" in this publication.

Configure Calls to a Single Site

The modem chat script becomes the default chat script for an interface. This means that it becomes the default chat script for the dialer string and dialer map commands presented in this section.

To configure an interface to call a single site, perform the following steps:

Step 1 Enable DDR on the interface.

Step 2 For synchronous interfaces, specify the dial string (synchronous interfaces).
For asynchronous interfaces, specify chat scripts and dial strings.

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

To call a single site over serial lines connected by non-V.25bis modems using EIA signaling only (specifically, the Data Terminal Ready [DTR] signal), you enable DDR using the dialer dtr command. A serial interface configured for DTR dialing can place calls only; it cannot accept them. Dialer rotary group leaders cannot be configured for DTR dialing.

For information about configuring the router that will receive the DTR calls, see the "Configure 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 modems on synchronous interfaces, you enable DDR using the dialer in-band command. If using V.25bis modems, you can optionally specify parity. The 1984 version of the V.25bis specification states that characters must have odd parity. However, the default is no parity.

For an example of configuring an interface to support DTR dialing, see the section "DTR Dialing Configuration Example" later in this chapter.

For ISDN interfaces, the dialer in-band command is not required. The software automatically configures these interfaces to be dialer type ISDN.

To place a call to a single site on an asynchronous line for which a modem script has not been assigned or a system script must be specified, perform the following task in interface configuration mode:

Use the dialer map command to specify a chat script if no modem script is specified for the line or an additional (system) chat script is required to log in to the remote system.

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

• The modem script can be used to dial and log in to the remote system.

• You are calling a system that does not require a login script; that is, a system that answers and immediately goes into protocol mode.

If you want to call only one remote system per interface, the dialer string command is useful. You do not need to use the dialer map command for authentication. Dialers pass the string you have defined to the external DCE. 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:

Configure Calls to Multiple Sites

You can configure your router 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 your router 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:

To define dialing destinations, perform one of the following tasks:

If you adhered to the chat script naming convention described earlier in this chapter, use the form [modem-script *modulation-type] in the dialer map command, as in ".*-v32bis." This allows you to specify the modulation type that is best for the system you are calling, and allows the modem type for the line to be specified by the modem chat-script command.

The 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 Router Products Command Reference publication.

If there is a modem script specified in the interface configuration command (dialer map) and a modem script specified in the line configuration command (modem chat-script), the first chat script that matches both will be used. If no script matches both, an error message is logged and the connection is not established. If there is no modem chat script specified for the line, the first chat script (chat-script global configuration command) that matches the modem script regular expression will be used. If there is a system script specified in the interface configuration command, the first chat script to match the regular expression will be used.

Configure a dialer map command for each remote destination for that interface.

Calling from Dialer Rotary Groups

Perform the following steps to configure your router to place multiple calls using a dialer rotary group. 

Step 1 Define a rotary group.

Step 2 Enable DDR on the rotary interface.

Step 3 Define multiple dialing destinations for the rotary group.

Step 4 Assign physical interfaces to the rotary group.

Dialer rotary groups allow you to apply a single interface configuration to a set of physical interfaces. Dialer rotary groups are useful in environments that have multiple callers and calling destinations. Configure a dialer interface unless you are only using a single line for dialing out or have a single line dedicated to each destination.

A dialer rotary group is defined by specifying a "dialer interface." The dialer interface is not a physical interface; it is an entity that allows you to propagate an interface configuration to multiple interfaces. After the dialer interface is defined by a number, interface parameters are configured for the dialer interface. Finally, physical interfaces are assigned to the dialer rotary group. Physical interfaces inherit the interface dialer configuration parameters.

After an interface configuration is propagated to a set of physical interfaces, those interfaces can be used to place calls using standard DDR criteria. When many destinations are configured, any of the physical interfaces in a rotary group can be used for outgoing calls. When traffic arrives, an interface from the rotary group is dialed. When more traffic for a different host arrives, another interface is dialed. Using the dialer interface allows you to specify one set of dialer maps that can apply to multiple physical lines.

You can define up to 9 dialer interfaces. Perform the following tasks for each dialer rotary group.

To define a rotary group, perform the following task in global configuration mode:

To enable DDR for the dialer rotary group, perform the following task in interface configuration mode:

To define multiple dialing destinations for the dialer rotary group, perform one of the following tasks in interface configuration mode:

To assign a physical interface to a dialer rotary group, perform the following task in interface configuration mode:

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.

Figure 8-2 illustrates how dialer interfaces work. In this example configuration, serial interfaces 1, 2, and 3 are assigned to dialer rotary group 1. This means that these three interfaces take on the parameters configured for dialer interface 1. For example, when it is being used for dialing, the IP address of serial interface 2 is the same as the address of the dialer interface, 131.108.1.1.

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:

• Configure an Interface to Receive Calls from a Single Site

• Configure an Interface to Receive Calls from Multiple Sites

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 the receiving interface is expected to terminate a call when no traffic is received for some time, in-band dialing must be configured (along with access lists and a dummy dialer string). If the receiving interface is purely passive, no additional configuration is necessary.

To enable DDR and thus configure an interface to receive calls from a single site, perform the following task in interface configuration mode:

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 your router 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 your router 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 only using a single line for dialing out. 

A dialer rotary group is defined by specifying a "dialer interface." The dialer interface is not a physical interface; it is an entity that allows you to propagate an interface configuration to multiple interfaces. After 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, those interfaces can be used to place calls using standard DDR criteria. When many destinations are configured, any of the physical interfaces in a rotary group can be used for outgoing calls. When traffic arrives, an interface from the rotary group is dialed. When more traffic for a different host arrives, another interface is dialed. Using the dialer interface allows you to specify one set of dialer maps that can apply to multiple physical lines.

You can define up to nine dialer interfaces. For each dialer rotary group, perform the following task in global configuration mode:

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:

Configure and Configure CHAP or PAP Authentication

The Point-to-Point Protocol (PPP) with Challenge Handshake Authentication Protocol (CHAP) authentication or Password Authentication Protocol (PAP) is often used to inform the central site about which remote routers are connected to it.

With this authentication information, if another packet is received for a destination to which the router is already connected, an additional call will not be placed. However, if using rotaries, the packet will be sent out the correct port.

CHAP and PAP are specified in RFC 1334. These protocols are supported on synchronous and asynchronous serial interfaces. When using CHAP or PAP authentication, each router identifies itself by a name, which informs the other router what routers are currently connected to it. This identification process prevents a router from placing a call to another router if it is already connected to that router and prevents unauthorized access. See the "Configuring Interfaces" chapter in this manual for more information about CHAP and PAP.

When CHAP is enabled, a remote device (a PC, workstation, or router) attempting to connect to the local router is requested, or challenged, to respond. The challenge consists of a random number and the host name of the local router. This challenge is transmitted to the remote device. The required response is an encrypted version of a secret password, or secret, plus a random value and the name of the remote device.

The remote device finds the secret by looking up the host name that was received in the challenge. When the local router receives the challenge response, it verifies the response by looking up the name of the remote device given in the response. The secret passwords must be identical on the remote device and the local router. These names and secret passwords are configured using the username command.

By transmitting this response, the secret is never transmitted, preventing other devices from stealing it and gaining illegal access to the system. Without the proper response, the remote device cannot connect to the local router.

CHAP transactions occur only at the time a link is established. The local router does not issue a challenge during the rest of the call. (The local router can, however, respond to such requests from other devices during a call.)

When PAP is enabled, the remote router attempting to connect to the local router is required to send an authentication request. If the username and password specified in the authentication request are accepted, the router sends an authentication acknowledgment.

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 requires authentication from remote devices. If the remote device does not support CHAP, 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:

Assign an Interface to a Dialer Rotary Group

To assign a physical interface to a dialer rotary group, perform the following task in interface configuration mode:

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:

• Place and Receive Calls from a Single Site

• Place and Receive Calls from Multiple Sites

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 your router to place calls to and receive calls from a single site, perform the following tasks in interface configuration mode:

Step 1 Enable DDR.

Step 2 Specify the phone number to dial.

When a dialer string is configured on an interface and CHAP is not, any incoming call is assumed to be from the configured dialer string.

To call and receive a call from a single site, you 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:

To specify a dial-string destination for an interface, perform the following task in interface configuration mode:

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 next hop to 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:

To specify one destination dial string per interface, perform the following task in interface configuration mode:

Calls from the multiple sites will need to be authenticated. Authentication can be done through CHAP. To enable CHAP on an interface and authenticate sites that are calling in, perform the following tasks in interface configuration mode:

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

Figure 8-3 shows a configuration in which the central site is calling and receiving calls from multiple sites. In this configuration, multiple sites are calling in to a central site, and the central site is calling out to the remote sites.

Configure Multilink PPP

Multilink PPP allows packets to be fragmented and the fragments to be sent at the same time over multiple point-to-point links to the same remote address. The multiple links come up in response to a dialer load threshold that you define. The load can be calculated on inbound traffic, outbound traffic, or on either, as needed for the traffic between the specific sites.

Multilink PPP is designed to work over single or multiple interfaces of the following types that are configured to support both dial-on-demand rotary groups and PPP encapsulation:

• Asynchronous serial interfaces

• Basic Rate Interfaces (BRIs)

• Primary Rate Interfaces (PRIs)

Configure Multilink PPP on Asynchronous Interfaces

To configure Multilink PPP on asynchronous interfaces, you configure the asynchronous interfaces to support DDR and PPP encapsulation, then you configure a dialer interface to support PPP encapsulation, bandwidth on demand, and Multilink PPP.

To configure an asynchronous interface to support DDR and PPP encapsulation, complete the following tasks beginning in global configuration mode:

Repeat this step for additional asynchronous interfaces, as needed.

At some point, adding more asynchronous interfaces does not improve performance, With the default MTU size, Multilink PPP should support three asynchronous interfaces using V.34 modems. However, packets might be dropped occasionally if the MTU is small or large bursts of short frames occur.

To configure a dialer interface to support PPP encapsulation and Multilink PPP, complete the following tasks beginning in global configuration mode:

Configure Multilink PPP on a Single ISDN BRI Interface

To enable multilink PPP on a single Integrated Services Digital Network (ISDN) BRI interface, you are not required to define a dialer rotary group separately because ISDN interfaces are dialer rotary groups by default. To enable PPP on an ISDN BRI interface, perform the following tasks beginning in global configuration mode:

If you do not use PPP authentication procedures (Step 8), your telephone service must pass caller ID information.

Configure Multilink PPP on Multiple ISDN BRI Interfaces

To enable multilink PPP on multiple ISDN BRI interfaces, you configure the BRIs separately and add them each to the same rotary group. Then you set up a the dialer rotary interface and configure it for multilink PPP.

To configure each of the BRIs to belong to the same rotary group, perform the following tasks beginning in global configuration mode:

Repeat Steps 1 through 7, above, for each BRI you want to belong to the same dialer rotary group.

To set up the dialer rotary interface for the BRI interfaces, perform the following tasks beginning in global configuration mode:

If you do not use PPP authentication procedures (Step 10), your telephone service must pass caller ID information.

Configure PPP Callback

PPP callback provides a client-server relationship between the end points of a point-to-point connection. PPP callback allows a router to request that a dial-up peer router call back. The callback feature can be used to control access and toll costs between the routers.

When PPP callback is configured on the participating routers, the calling router (the callback client) passes authentication information to the remote router (the callback server), which uses the host name and dialstring authentication information to determine whether to place a return call. If the authentication is successful, the callback server disconnects and then places a return call. The remote username of the return call is used to associate it with the initial call so that packets can be transmitted.

Both routers on a point-to-point link must be configured for PPP callback. The callback client must be configured to initiate PPP callback and the callback server must be configured to accept PPP callback.

This feature implements the following callback specifications of RFC 1570:

• For the client--Option 0, location is determined by user authentication.

• For the server--Option 0, location is determined by user authentication; option 1, dialing string; option 3, E.164 number.

Return calls are made using the same dialer rotary group but not necessarily the same line as the initial call.

Configure a Router as a Callback Client

To configure a router interface as a callback client, complete the following tasks beginning in global configuration mode:

Configure a Router as a Callback Server

To configure a router as a callback server, complete the following tasks beginning in global configuration mode:

Configure Snapshot Routing

Snapshot routing, which is available on serial and ISDN lines, is a method of learning remote routes dynamically and then keeping the routes available for a period of time while regular routing updates are not being exchanged. This might be during periods when a remote site is not dialed into the local site or when a remote site has a dedicated connection to the local site but wishes to avoid the overhead of exchanging routing updates. Snapshot routing allows you to avoid configuring static routes when using dial-on-demand routing. It also eliminates the overhead required for sending periodic updates over dedicated serial lines.

When configuring snapshot routing, you choose one router on the interface to be the client router and one or more other routers to be server routers. The client router determines the frequency at which routing information is exchanged between routers.

Routing information is exchanged during an active period. 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 8-4.

• Configure the Client Router

• Configure the Server Router

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

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:

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

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

ISDN BRI and PRI automatically have rotary groups, so 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:

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:

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

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

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 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 be configured to support X.25 encapsulation. 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:

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

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 connections (PVCs) 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 over Frame Relay:

• Frame Relay is not available for asynchronous dialers.

• Like HDLC, LAPB, and X.25, Frame Relay does not provide authentication. However, ISDN dialers can offer some authentication through the caller ID feature.

• Only one ISDN B-channel can be dialed at any one time. When configuring a rotary group, you can use only one serial interface.

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:

• Specify the interface.

• Specify the protocol identifiers for the interface.

For example, enter the IP address and mask, the IPX network number, and the AppleTalk cable range and zone.

• Configure Frame Relay, as described in the "Configuring Frame Relay" chapter.

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.

• Configure DDR, as specified in the Router Products Configuration Guide.

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 (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 "Configure DDR over Frame Relay" section of 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

• Configure DDR for Banyan VINES

• Configure DDR for DECnet

• Configure DDR for IP

• Configure ISO CLNS over DDR

• Configure DDR for Novell IPX

• Configure XNS over DDR

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:

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.

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:

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.

DECnet control packets, including hello packets and routing updates, are classified 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 in this chapter.

Configure DDR for IP

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

For an example of configuring DDR for IP, see the "Configure DDR for IP" section.

Configure ISO CLNS over DDR

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

After you complete the CLNS-specific steps listed above, 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

CLNS control packets, including hello packets and routing updates, are classified using the dialer-list protocol clns_is permit and/or dialer-list protocol clns_es permit commands.

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/keepalive packets to all the clients approximately every five minutes. A local router with the DDR link can be configured to idle out the link and still make the server believe the clients are active by responding to the watchdog packets on behalf of the clients. To do so, perform the following tasks in interface configuration mode:

Step 1 Enable DDR.

Step 2 Disable IPX fast switching.

Step 3 Enable either IPX watchdog spoofing or SPX keepalive spoofing.

You enable DDR using the dialer-in-band command. Dialers specified by this command use chat scripts on asynchronous interfaces and V.25bis on synchronous interfaces. If using V.25bis, you can optionally specify parity. The 1984 version of the V.25bis specification states that characters must have odd parity. However, the default is no parity. To enable DDR, perform the following task in interface configuration mode:

You must also disable IPX fast switching. To disable fast switching, perform the following task in interface configuration mode:

Configure XNS over DDR

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

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

Our routers support transparent bridging over DDR and provide you some flexibility in controlling access and in configuring the interface.

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

• Define the Protocols to Bridge

• Specify the Bridging Protocol

• Control Access for Bridging

• Configure an Interface for Bridging

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:

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.

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:

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:

• Permit All Bridge Packets

• Control Bridging Access by Ethernet Type Codes

Permit All Bridge Packets

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

Control Bridging Access by Ethernet Type Codes

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

For a table of some common Ethernet types codes, see the "Ethernet Types Codes" appendix in the Router Products Command Reference publication.

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

• Configure the Destination

• Assign the Interface to a Bridge Group

Specify the Interface

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

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:

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:

Customize the DDR Network

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

• Set Line-Idle Time

• Set Idle Time for Busy Interfaces

• Set Line-Down Time

• Set Carrier-Wait Time

• Control Access to a DDR Interface

• Set Dialer Interface Priority

• Configure a Dialer Hold Queue

• Configure Bandwidth on Demand

• Disable and Reenable DDR Fast Switching

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:  

Set Idle Time for Busy Interfaces

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

If the line has been idle for the configured amount of time, the current call is disconnected immediately and the new call is placed. If the line has not yet been idle as long as the fast idle timer, the packet is dropped because there is no way to get through to the destination. (After the packet is dropped, the fast-idle timer remains active and the current call is disconnected as soon as it has been idle for as long as the fast idle timeout). If, in the meantime, there is another packet transmitted to the currently connected destination, and it is classified as interesting, the fast-idle timer 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:

This command applies both to inbound and outbound calls.

Set Line-Down Time

To set the length of time an interface stays down before it is available to dial again after a line is disconnected or fails, perform the following task in interface configuration mode:

This command applies both to inbound and outbound calls.

Set Carrier-Wait Time

To set how long to wait for the telephone service (carrier), perform the following task in interface configuration mode:

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

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 Router Products Command Reference publication for detailed information.

Before you perform the tasks outlined in this section, see the appropriate chapters for information about defining Banyan VINES, DECnet, IP, IPX, ISO CLNS, and XNS access lists. Define access lists 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 one of the following tasks in global configuration mode:

For the dialer-list protocol list command form, acceptable access list numbers are Banyan VINES, DECnet, IP, and XNS standard and extended access list numbers; Novell IPX standard, extended, and SAP access list numbers; AppleTalk access lists numbers; and bridge type codes. 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:

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.

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:

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 server 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:

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:

Monitor DDR Connections and Snapshot Routing

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

DDR Configuration Examples

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

• Dial Backup Using the Auxiliary Port Example

• Dial Backup Using DDR and ISDN Example

• Configuring DDR in an IP Environment Example

• Configuring Multiple Destination Dial Strings Example

• Configuring Dialer Rotary Groups Example

• Dialing a Single Site or Multiple Sites Example

• Using Chat Scripts Example

• Writing and Implementing Chat Scripts Example

• Chat Scripts and Dialer Mapping Example

• System Scripts and Modem Scripts Example

• Dial-on-Demand PPP Configuration Example

• DTR Dialing Configuration Example

• Snapshot Routing Examples

• LAPB Support Configuration Example

• X.25 Support Configuration Example

• Frame Relay Support Examples

• AppleTalk Configuration Example

• Banyan VINES Configuration Example

• DECnet Configuration Example

• ISO CLNS Configuration Example

• XNS Configuration Example

• DDR for Transparent Bridging Examples

Dial Backup Using the Auxiliary Port Example

The following is an example for dial backup using the auxiliary port (async 1):

interface serial 0
ip address 1.2.3.4 255.255.255.0
backup interface async1
backup delay 10 10
!
interface async 1
ip address 1.2.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 foo "" "atdt 5551212" TIMEOUT 60 "CONNECT"
!
line aux 0
modem chat-script foo
modem inout
speed 9600

Dial Backup Using DDR and ISDN Example

The following is an example for dial backup using DDR and ISDN:

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

Configuring DDR in an IP Environment Example

The following example illustrates how to use DDR on an asynchronous 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

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 of the Router Products Command Reference publication. 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 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 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 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 8-5 and your router receives a packet with a next hop address of 1.1.1.1.

interface serial 1
dialer in-band
dialer string 5555555

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 8-6 shows the following configuration:

• The configuration is on Router A.

• The chat script "dial" is used to dial Router B's modem.

• The chat script "login" is used to log in to Router B.

• The phone number is the number of the modem attached to Router B.

• The IP address is the address of Router B.

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, " " 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 dialing chat script and a login chat script. The dialer in-band command enables DDR on asynchronous interface 10 and the dialer map command dials 96837890 after finding the specified dialing and the login scripts.

chat-script dial ABORT ERROR "" "AT Z" OK "ATDT \T" TIMEOUT 30 CONNECT \c
chat-script login ABORT invalid TIMEOUT 15  name: 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 8-2 shows the functions that are implemented with each expect-send pair in the modem script called "dial."

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

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 10.6 on the next page 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:

• The dialer map command

• PPP encapsulation

• CHAP

• Dialer rotary groups

• The pulse-time command

See the "Interfaces Commands" chapter in the Router Products Command Reference publication for a description of the pulse-time command.

! Enable PPP encapsulation and CHAP on interface dialer 1. 
interface dialer 1
ip address 131.108.2.1 255.255.255.0
ip address 131.126.4.1 255.255.255.0 secondary
encapsulation ppp
ppp authentication chap
! Specify dial-on-demand routing supported on a line and
! assign a set of access-list expressions.
dialer in-band
dialer group 1
! The first dialer map command indicates that calls between the remote site
! YYY and the central site will be placed at either end. The second dialer
! map command, with no dialer string, indicates that remote site ZZZ will call
! the central site but the central site will not call out.
dialer map ip 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 rotary group 1. The 
! interface commands applied to dialer rotary group 1 (for example,
! PPP encapsulation and CHAP) apply to these interfaces. 
interface async 1
dialer rotary-group 1
interface async 2
dialer rotary-group 1
! CHAP passwords are specified for remote servers. 
username YYY password theirsystem
username ZZZ password thatsystem

Figure 8-7 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.

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 8-8.)

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

Multilink PPP Examples

The examples in the following sections illustrate the configuration of one or multiple ISDN interfaces for multilink PPP. The second example shows that you can configure multiple ISDN interfaces to belong to the same dialer rotary group.

One ISDN Interface Configured for Multilink PPP Example

The following example enables multilink PPP on the BRI 0 interface. Because an ISDN interface is a rotary group by default, when one BRI is configured, no dialer rotary group configuration is required.

interface bri 0
description connected to ntt 81012345678902
ip address 7.1.1.7 255.255.255.0
encapsulation ppp
dialer idle-timeout 30
dialer load-threshold 40 either
dialer map ip 7.1.1.8 name atlanta 81012345678901
dialer-group 1
ppp authentication pap
ppp multilink

Multiple ISDN Interfaces Configured for Multilink PPP Example

The following example configures multiple ISDN BRIs to belong to the same dialer rotary group for multilink PPP. The dialer rotary-group command is used to assign each of the ISDN BRIs to that dialer rotary group.

interface BRI0
no ip address
encapsulation ppp
no keepalive
dialer idle-timeout 500
dialer rotary-group 0
dialer load-threshold 255 balanced
!
interface BRI1
no ip address
encapsulation ppp
no keepalive
dialer idle-timeout 500
dialer rotary-group 0
dialer load-threshold 255 balanced
!
interface BRI2
no ip address
encapsulation ppp
no keepalive
dialer idle-timeout 500
dialer rotary-group 0
dialer load-threshold 255 balanced
!
interface Dialer0
ip address 99.0.0.2 255.0.0.0
encapsulation ppp
no keepalive
dialer in-band
dialer idle-timeout 500
dialer map ip 99.0.0.1 name atlanta broadcast 81012345678901
dialer load-threshold 255 balanced
dialer-group 1
ppp authentication chap
ppp multilink

PPP Callback Example

The following example configures a PPP callback server with a client.

The PPP callback server is configured on an ISDN BRI interface on a router in Atlanta. The callback server requires an enable timeout and a map-class to be defined.

The PPP callback client is configured on an ISDN BRI interface on a router in Dallas. The callback client does not require an enable timeout and a map-class to be defined.

PPP Callback Server

interface BRI0
 ip address 7.1.1.7 255.255.255.0
 encapsulation ppp
 dialer callback-secure
 dialer enable-timeout 2
 dialer map ip 7.1.1.8 name atlanta class dial1 81012345678901
 dialer-group 1
 ppp callback accept
 ppp authentication chap
!
map-class dialer dial1
 dialer callback-server username

PPP Callback Client

interface BRI0
 ip address 7.1.1.8 255.255.255.0
 encapsulation ppp
 dialer map ip 7.1.1.7 name dallas 81012345678902
 dialer-group 1
 ppp callback request
 ppp authentication chap

Snapshot Routing 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
snapshot retry-interval 5
dialer map snapshot 2 4155556734
dialer map snapshot 3 7075558990

The following commands configure the server router:

interface serial 2
snapshot server 5 dialer

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.

In-Band Dialing (V.25bis) and Static Map

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

ISDN Dialing and Dynamic Maps

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

ISDN Dialing and Subinterfaces

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