Dial Configuration Guide, Cisco IOS Release 15.5M&T

New Dialer Profile Model

In earlier releases of the Cisco IOS software, dialer profiles in the same dialer pool needed encapsulation-specific configuration information entered under both the dialer profile interface and the ISDN interface. If any conflict arose between the logical and the physical interfaces, the dialer profile failed to work.

In the new dialer profile model introduced by the Dynamic Multiple Encapsulations feature in Cisco IOS Release 12.1, the configuration on the ISDN interface is ignored and only the configuration on the profile interface is used, unless PPP name binding is used. Before a successful bind by CLID occurs, no encapsulation type and configuration are assumed or taken from the physical interfaces.

When PPP is used and a caller identification (CLID) bind fails, a dialer profile still can be matched by PPP name authentication. In the new dialer profile model, multiple attempts are made to find a matching profile.

The dialer profile software binds an incoming call on a physical dialer interface according to the following events, and in the order listed:

1. There is only one dialer profile configured to use the pool of which the physical interface is a member; this condition is the default bind. The physical interface must be a member of only this one pool. A default bind is possible only to a dialer profile when there are no dialer caller or dialer called commands configured on that profile.

2. The CLID matches what is configured in a dialer caller command on a dialer profile using a pool of which the physical interface is a member.

3. The DNIS that is presented matches what is configured in a dialer called command on a dialer profile using a pool of which the physical interface is a member.

4. If a bind has not yet occurred but the physical interface is configured for PPP encapsulation and CHAP or PAP authentication, and the CHAP or PAP name presented matches a dialer remote-name command configuration on a dialer profile using a pool of which the physical interface is a member, then the dialer profile software binds to that dialer profile.

If none of the above events are successful, the call is not answered. The call is also disconnected during any of the first three events when, after the bind occurs and the physical interface is configured for PPP encapsulation and CHAP or PAP authentication, the CHAP or PAP name presented does not match what is configured in a dialer remote-name command on the dialer profile that was bound to the call.

PPP encapsulation on an ISDN link is different from other encapsulation types because it runs on the B channel rather than the dialer profile interface. There are two possible configuration sources in a profile bind: the D and the dialer profile interfaces. Hence, a configuration conflict between the sources is possible. If a successful bind is accomplished by name authentication, the configuration used to bring PPP up is the one on the D interface. This is the name used to locate a dialer profile for the bind. The configuration on an ISDN interface goes under the D rather than a B channel, although B channels inherit the configuration from their D interface.

However, the configuration on this found dialer profile could be different from the one on the D interface. For example, the ppp multilink command is configured on the D interface, but not on the dialer profile interface. The actual per-user configuration is the one on the dialer profile interface. In this case, per-user configuration is not achieved unless link control protocol (LCP) and authentication are renegotiated. Because PPP client software often does not accept renegotiation, this workaround is not acceptable. Therefore, the D interface configuration takes precedence over the dialer profile interface configuration. This is the only case where the configuration of the dialer profile is overruled.

Dialer Interface

A dialer interface configuration includes all settings needed to reach a specific destination subnetwork (and any networks reached through it). Multiple dial strings can be specified for the same dialer interface, each dial string being associated with a different dialer map class.

Dialer Map Class

The dialer map class defines all the characteristics for any call to the specified dial string. For example, the map class for one destination might specify a 56-kbps ISDN speed; the map class for a different destination might specify a 64-kbps ISDN speed.

Dialer Pool

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

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

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

Figure 1 shows a typical application of dialer profiles. Router A has dialer interface 1 for DDR with subnetwork 10.1.1.0, and dialer interface 2 for DDR with subnetwork 10.2.2.0. The IP address for dialer interface 1 is its address as a node in network 10.1.1.0; at the same time, that IP address serves as the IP address of the physical interfaces used by the dialer interface 1. Similarly, the IP address for dialer interface 2 is its address as a node in network 10.2.2.0.

Figure 1 Typical Dialer Profiles Application

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

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

Figure 2 Relations Among Dialer Interfaces, Dialer Pools, and Physical Interfaces

Configuring a Dialer Profile

To configure a dialer profile, perform the tasks in the following sections as required:

• Configuring a Dialer Interface (Required)
• Fancy Queueing and Traffic Shaping on Dialer Profile Interfaces (Optional)
• Configuring a Map Class (Optional)
• Configuring the Physical Interfaces (Required)

Configuring a Dialer Interface

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

To configure a dialer interface, use the following commands beginning in global configuration mode:

Fancy Queueing and Traffic Shaping on Dialer Profile Interfaces

In earlier releases of the Cisco IOS software, fancy queueing and traffic shaping were configured under the physical interfaces, therefore the same queueing or traffic shaping scheme needed to be applied to all users that were sharing the same ISDN link.

Beginning in Cisco IOS Release 12.1, you need only configure the queueing and traffic shaping schemes you desire on the dialer profile interface and the interface will take precedence over those configured on the ISDN B-channel interface. All the per-user encapsulation configuration has been moved to the dialer profile interfaces, separating it from hardware interfaces to make it dynamic and also to make per-user queueing and traffic shaping configuration possible.

Note Per-user fancy queueing and traffic shaping work with both process switching and fast switching in the new dialer profile model. However, Frame Relay Traffic Shaping (FRTS) is not supported on the new dialer profile model.

See the chapter “Policing and Shaping Overview” in the Cisco IOS Quality of Service Solutions Configuration Guide for more information about FRTS.

Configuring a Map Class

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

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

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

Note The dialer idle-timeout interface configuration command specifies the duration of time before an idle connection is disconnected. Previously, both inbound and outbound traffic would reset the dialer idle timer; now you can specify that only inbound traffic will reset the dialer idle timer.

Configuring the Physical Interfaces

To configure a physical interface, use the following commands beginning in global configuration mode:

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

Configuring Dialer Profiles for Routed Protocols

Both legacy DDR and dialer profiles support the following routed protocols: AppleTalk, Banyan VINES, DECnet, IP, Novell Internet Protocol Exchange (IPX), and Xerox Network System (XNS). To configure dialer profiles for a routed protocol, perform the tasks in the relevant section:

• Configuring Dialer Profiles for AppleTalk (As required)
• Configuring Dialer Profiles for Banyan VINES (As required)
• Configuring Dialer Profiles for DECnet (As required)
• Configuring Dialer Profiles for IP (As required)
• Configuring Dialer Profiles for Novell IPX (As required)
• Configuring XNS over DDR (As required)

Configuring Dialer Profiles for AppleTalk

To configure dialer profiles for AppleTalk, you specify AppleTalk access lists and then configure the dialer interface for dialer profiles, defining the dialer list to be used. 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 section “Configuring a Dialer Interface” earlier in this chapter for more information about defining dialer lists.

Configuring Dialer Profiles for Banyan VINES

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

After you specify VINES standard or extended access lists, configure the dialer interface for dialer profiles, defining the dialer list to be used. 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 section “Configuring a Dialer Interface” earlier in this chapter for more information about defining dialer lists.

Note The Banyan VINES neighbor command is not supported for Link Access Procedure, Balanced (LAPB) and X.25 encapsulations.

Configuring Dialer Profiles for DECnet

To configure dial-on-demand routing (DDR) for DECnet, use one of the following commands in global configuration mode:

After you specify DECnet standard or extended access lists, configure the dialer interface for dialer profiles, defining the dialer list to be used. 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 section “Configuring a Dialer Interface” earlier in this chapter for more information about defining dialer lists.

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

Configuring Dialer Profiles for IP

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

You can now also use simplified IP access lists that use the any keyword instead of the numeric forms of source and destination addresses and masks. Other forms of IP access lists are also available. For more information, see the chapter “IP Services Commands” in the Cisco IOS IP Command Reference.

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. Split horizon applies to Routing Information Protocol (RIP), Interior Gateway Routing Protocol (IGRP), and Enhanced IGRP. Depending on which routing protocol is configured, see the chapter “Configuring RIP,” “Configuring IGRP,” or “Configuring Enhanced IGRP” in this publication. Refer to the chapter “Configuring IP Routing Protocols” in the Cisco IOS IP Configuration Guide for more information.

Configuring Dialer Profiles for Novell IPX

On DDR links for Novell IPX, the link may come up often even when all client sessions are idle because the server sends watchdog or keepalive packets to all the clients approximately every 5 minutes. You can configure a local router or access server to idle out the DDR link and respond to the watchdog packets on behalf of the clients.

To modify the dialer profiles dialer interface configuration for Novell IPX, use the following commands in interface configuration mode:

Configuring XNS over DDR

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

After you specify an XNS access list, configure the dialer interface for dialer profiles, defining the dialer list to be used. 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 section “Configuring a Dialer Interface” earlier in this chapter for more information about defining dialer lists.

Configuring Dialer Profiles for Transparent Bridging

The Cisco IOS software supports transparent bridging over both legacy DDR and dialer profiles, and it provides you some flexibility in controlling access and configuring the interface.

To configure dialer profiles for bridging, perform the tasks in the following sections:

• Defining the Protocols to Bridge (Required)
• Specifying the Bridging Protocol (Required)
• Controlling Access for Bridging (Required)
• Configuring an Interface for Bridging (Required)

Defining the Protocols to Bridge

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

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 chapter in the appropriate network protocol configuration guide, such as the Cisco IOS AppleTalk and Novell IPX Configuration Guide.

Specifying the Bridging Protocol

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

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

Controlling 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, perform one of the following tasks:

• Permitting All Bridge Packets
• Controlling Bridging Access by Ethernet Type Codes

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

Permitting All Bridge Packets

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

Controlling Bridging Access by Ethernet Type Codes

To control access by Ethernet type codes, use the following commands in global configuration mode:

For a table of some common Ethernet type codes, see the “Ethernet Type Codes” appendix in the Cisco IOS Bridging and IBM Networking Command Reference.

Configuring an Interface for Bridging

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

• Specifying the Interface (Required)
• Configuring the Destination (Required)
• Assigning the Interface to a Bridge Group (Required)

Specifying the Interface

To specify the interface and enter interface configuration mode, use the following command in global configuration mode:

Configuring the Destination

You can configure the destination by specifying either of the following:

• A dial string—for unauthenticated calls to a single site
• A dialer bridge map—when you want to use authentication

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

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

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

Dialer Profile with Inbound Traffic Filter Example

The following example shows a Cisco 5200 series router that has enabled the dialer idle-timeout command with the inbound keyword. This command allows only inbound traffic that conforms to the dialer list to establish a connection and reset the dialer idle timer.

Dialer Profile for Central Site with Multiple Remote Sites Example

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

Dialer Profile for ISDN BRI Backing Up Two Leased Lines Example

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

Dynamic Multiple Encapsulations over ISDN Example

The following example shows a network access server named NAS1 with dialer profiles and LAPB, X.25, and PPP encapsulations configured. Although the BRI0 D interface uses X.25 encapsulation, the actual encapsulations running over the ISDN B channels are determined by the encapsulations configured on the profile interfaces bound to them.

When an ISDN B channel connects to remote user RU2 using CLID 60043, Dialer1 is bound to this ISDN B channel by CLID binding. The protocol used is PPP; the X.25 configuration on the
D interface has no effect. Because the ppp authentication chap command is configured, even though the binding is done by CLID, PPP authentication is still performed over the name RU2 before the protocol is allowed to proceed.

The Dialer2 interface uses DNIS-plus-ISDN-subaddress binding and is bound to a B channel with an incoming call with DNIS 60045 and ISDN subaddress 12345. Also note that the High-Level Data Link Control (HDLC) encapsulation has no username associated. It is no longer necessary to configure the dialer remote-name command, as in the previous dialer profile model.

When there is an ISDN B-channel connection to remote user RU1 using CLID 60036, LAPB encapsulation will run on this connection once CLID binding to Dialer0 takes place. This connection will operate as a standalone link independent of other activities over other ISDN B channels.

Verifying the Dynamic Multiple Encapsulations Feature

To see statistics on each physical interface bound to the dialer interface, and to verify dialer interfaces configured for binding, use the show interfaces EXEC command. Look for the reports “Bound to:” and “Interface is bound to...” while remembering that this feature applies only to ISDN.

At the end of the Dialer0 display, the show interfaces command is executed on each physical interface bound to it.

In the next example, the physical interface is the B1 channel of the BRI0 link. This example also illustrates that the output under the B channel keeps all hardware counts that are not displayed under any logical or virtual access interface. The line in the report that states “Interface is bound to Dialer0 (Encapsulation LAPB)” indicates that this B interface is bound to the dialer 0 interface and that the encapsulation running over this connection is LAPB, not PPP, which is the encapsulation configured on the D interface and inherited by the B channel.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007-2009 Cisco Systems, Inc. All rights reserved.