Configuring and Troubleshooting Dialer Profiles

Introduction

This document provides tips for configuring and troubleshooting Dialer profiles.

Prerequisites

Requirements

Readers of this document should be knowledgeable of the following:

• Legacy DDR (dialer maps and dialer rotary-groups)

• PPP Challenge Handshake Authentication Protocol (CHAP) and Password Authentication Protocol (PAP)

• Caller ID (CLID) and Dialed Number Identification Service (DNIS)

Components Used

The information in this document is based on the software and hardware versions below.

• Dialer profiles were first introduced in Cisco IOS® Software Release 11.2.

• The instructions in this document are for Cisco IOS Software Release 12.0(7)T and later. Dialer Profile behavior in previous Cisco IOS software versions is not discussed in this document.

• Due to changes made to Dialer profiles, we recommend that you run Cisco IOS Software Release 12.1 or later. Dialer profiles can be used with any Cisco routers which have an ISDN interface.

The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.

Use the Software Advisor tool (registered customers only) to verify that the Cisco IOS software version you are running supports this feature.

Tip: In the Software Advisor tool, search for the feature named Dynamic Multiple Encapsulation for Dial-in over ISDN.

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Background Information

Legacy dial-on-demand routing (DDR), although useful in many scenarios, is restrictive in instances where you want to differentiate users by defining different characteristics for different users. This cannot be accomplished with Legacy DDR. Dialer profiles have been designed as a new DDR model to allow a user-specific profile to be configured on the router; the profile would determine the characteristics of a particular user, and the profile would be dynamically bound to a physical interface (for example, asynchronous or basic rate interface - BRI) for incoming or outgoing DDR calls. Dialer profiles support Point-to-Point Protocol (PPP), high-level data link control (HDLC), Frame Relay, or X.25 encapsulation for inbound or outbound dialing. PPP encapsulation is the recommended choice and this document focuses on PPP.

Are Dialer Profiles Right for You?

Answer the following questions to determine if Dialer profiles are the best option for your configuration. Any question answered with a 'don't care' should be interpreted as a 'No'. You should apply the answers to the following questions to the flowchart shown below to determine the best method to use.

1. Is there a per-user requirement? In other words, will it be necessary to apply features differently between users, for example compression, idle timeouts, Layer 3 addressing, or any other service or feature?

2. Will there be connections to more than 200 sites, regardless of call direction?

   Note: 200 sites is an arbitrary number beyond which network scaling becomes a significant issue.

3. Will there be a requirement for outbound dialing?

Use the flowchart below to obtain the best DDR implementation method.

DDR solution comparison flowchart

For more information on Legacy DDR, refer to the Cisco IOS Dial Technologies Configuration Guide chapter on Dial-on-Demand Routing Configuration.

For more information on Virtual Profiles (VP), refer to the Cisco IOS Dial Technologies Configuration Guide chapter on Virtual Templates, Profiles, and Networks.

For more information on Large-Scale Dial-Out (LSDO), refer to the Cisco IOS Dial Technologies Configuration Guide chapter on Configuring Large-scale Dial-Out.

Advantages of Dialer Profiles Over Legacy DDR

• Unlike Legacy DDR, the Dialer profile is a point-to-point interface. This fact alleviates the requirement for a Layer 3 to Layer 2 map and the added complexities of managing the multiple maps.

• Configure different members of a physical interface with different Layer 3 network addresses.

• Dialer profiles allow physical interfaces to take on different characteristics based on incoming or outgoing call requirements.

• Allow a back-up interface to be non-dedicated and useable when the primary interface is operational.

• Control the number of minimum or maximum connections into and out from a DDR interface.

• Different DDR parameters can be set for each B channel of an ISDN interface.

Sample Situations

Common situations where Dialer profiles are useful include:

• Router needs to connect to multiple sites and the peers are on different subnets.

• Physical interface must be used for normal DDR as well as provide backup to a WAN link

• Some B channels need to be reserved for a particular connection

• Peers run different encapsulation (for example, HDLC and PPP).

  Note: This feature requires Cisco IOS Software Version 12.0(7)T or later

• Some connections may require multiple channels while others need only a single channel

• Each connection requires different idle-timeout values.

• Each connection requires different interesting traffic definitions

• IP address of the peer is not known

• ISDN B channels (in a PRI) need different configurations

Notice that most of the situations described above are per-user related issues for which Dialer profiles are ideal. Keep in mind that the above list does not cover all situations where Dialer profiles can be used.

Constraints

Dialer profiles have known limitations. For example:

• PPP Authentication and Multilink must be enabled on the physical interfaces as well as the dialer interfaces, unless CLID-based binding is enabled (requires Cisco IOS Software Release 12.0(7)T or later).

• Each dialer interface takes an interface description block (IDB) which is the internal structure that manages an interface. There is a finite number of IDBs allowed (it depends upon the Cisco IOS software version and platform); this implies that Dialer profiles may not scale for large DDR applications. For more information on the IDB limits of various platforms, refer to Maximum Number of Interfaces and Subinterfaces for Cisco IOS Platforms: IDB Limits.

• Within Dialer profile, there is no method to configure a generic dialer profile (or even a default profile) for a group of users that shares the same characteristics. Each user must have its own profile.

  Tip: Use Virtual profiles in conjunction with Dialer profiles. Virtual profiles can provide an excellent "default profile".

• For incoming connections, there is no way to limit the amount of incoming calls to a profile without answering the call first and incurring a charge.

Dialer Profile Components

A Dialer profile consists of the following elements:

• Dialer interface - A logical entity that defines a user-specific dialer profile. All configuration settings specific to the user go under the dialer interface configuration; for example, the Layer 3 protocol addresses, interesting traffic, timeouts. Notice that this dialer interface is completely different from a dialer interface used as a rotary group with Legacy DDR. For the purpose of this discussion, a dialer profile and a dialer interface should be considered synonymous.

• Dialer pool - Each dialer interface is a member of a single dialer pool; the pool is a group of one or more physical interfaces. There can be any combination of interfaces (asynchronous, ISDN, serial) within a pool. Outbound dialing contention for a specific physical interface is resolved with the dialer pool-member priority command.

• Physical interface - Interfaces (such as BRI and async) are configured as members of one or more pools, and are minimally configured for encapsulation parameters and identification of the dialer pools that the interface belongs to. PPP authentication and Multilink PPP (if applicable) must also be configured on the physical interface, unless Caller ID (CLID)-based binding is enabled.

The diagram below depicts a sample interaction among these various elements of dialer profiles.

Understanding the Binding Process using Dialer Profiles

We will now elaborate on the concept of dynamically binding dialer profiles to physical interfaces on a per-call basis.

The configuration information for a particular peer is contained within a dialer profile. Once that particular peer is dialed into or is dialed out through a physical port, the router must bind the remote's dialer profile to the physical interface. Since there will likely be multiple dialer profiles configured on the router, it must properly choose which profile to bind for any given call (either incoming or outgoing). In discussing this subject with dialing out or dialing in, we provide a step-by-step procedure followed by a flowchart. Please reference the flowchart when using the step-by-step procedure.

Dialing Out

This scenario is very similar to the operation of a dialer rotary group; the physical interface assumes the characteristics of the dialer profile for a particular connection. The binding process is as follows:

1. An incoming packet arrives on the router; a routing table lookup indicates its destination address over a dialer interface.

2. The Cisco IOS software notes the dialer interface is a dialer profile. If there is not an existing connection for this profile, the pool that the dialer interface is associated with is identified.

3. If there is an existing connection, the packet is queued to the physical interface and if the traffic is "interesting", the idle timer is reset.

4. If there is no existing connection, the traffic is checked against the dialer-list to determine if it is interesting. If it is not, the packet is dropped. If it is interesting traffic, proceed to step 5.

5. Without an existing connection, the Cisco IOS software searches for the physical interface that belongs to the dialer interface with the highest dialer pool priority. This is the interface that will be used for dialing. This interface is bound to the dialer interface, causing the physical interface to assume the configuration of the dialer interface.

6. Cisco IOS software dials the phone number for the dialer profile, and at this point the normal DDR steps occur.

7. If the authenticated name of the peer does not match the dialer remote-name in the outgoing dialer profile, the call is disconnected.

Dialing Out Flow Chart

This sequence is the same regardless if the dialer pool is comprised of ISDN interfaces, asynchronous interfaces, or a mixture of both.

The number of outbound calls from a profile can be managed with a minimum and maximum threshold (using the dialer pool-member pool_number max-link number min-link number command). The minimum threshold serves as a reservation system, while the maximum threshold prevents over-utilization of a profile. Once the threshold has been reached, no more outgoing calls are allowed on that profile.

Dialing In

Dialer profile binding for incoming calls is more complicated since the incoming interface can potentially be a member of multiple pools, and these pools can be associated with multiple dialer profiles. If dynamic binding is not possible, the call is disconnected. The binding process is as shown below:

Note: This process is shown in order of execution and the call will be bound to the dialer interface when the first match is found.

1. If the physical interface is a member of only one pool, and only one dialer profile is associated with this dialing pool, then bind the physical interface to this dialer profile.

   Note: This step is only performed if the single configured dialer profile does not have the dialer caller or dialer called command. If either command is configured, this binding will only be performed if there is a successful match.

2. Attempt to match the Caller ID (CLID) from the call with the dialer caller command in the dialer interface; only profiles that are associated with the pool to which the physical interface is a member will be checked. If a match is found, bind the physical interface to the matched dialer profile. If this check fails for whatever reason, proceed to the next step in a further attempt to bind. For more information on dialer caller, refer to the document ISDN Authentication and Callback with Caller ID. This step is skipped if CLID is not provided by the telco or dialer caller is not configured under the dialer profile.

3. Attempt to bind using DNIS-plus-ISDN-subaddress information provided by the telco in the incoming call Q.931 setup message. This incoming call DNIS and subaddress information will be checked against the dialer called command under each dialer profile. If a match is found, binding succeeds; otherwise, it moves to the next criteria.

   Note: DNIS binding is allowed only when the ISDN subaddress information is present in the incoming call Q.931 setup message, and the dialer called command is properly configured in a dialer profile. ISDN subaddresses are used mainly in Europe and Australia and are not common in North America.

4. If the physical interface is configured for PPP authentication, answer the call and authenticate the remote peer. Use the authenticated name to identify the dialer profile that has the same name configured (with the dialer remote-name command). Only profiles that are associated with the pool to which the physical interface is a member will be checked. If a match is found, bind the physical interface to the matched dialer interface. If this check fails for whatever reason, the bind attempt algorithm fails and the call is disconnected.

Notice that a bind does not imply a successful connection. It simply means that the physical interface now has a configuration to utilize. However, the call can still be disconnected for other reasons (IP Control Protocol (IPCP) failure, for example).

Once the binding is successful and the devices authenticate, the router checks whether the dialer remote-name matches the authenticated username of the peer. If the names do not match, the call is disconnected.

Only synchronous ISDN calls can be bound using the caller id or DNIS. There is currently no effort made to use the supplied CLID/DNIS for binding modem calls in the case where the modem call happens to be delivered over an ISDN BRI or PRI connection.

The number of inbound calls from a profile can be managed with a maximum threshold (the max-link option in the dialer pool-member command). The maximum threshold prevents over-utilization of a profile. The router answers the call to determine which profile the call is for, and whether or not the profile maximum connection limit has been reached. If the maximum has been reached, the call is disconnected.

Dialer Profile Configuration Task Summary

To configure dialer profiles, perform the following tasks:

1. Configure one or more dialer interfaces. All configuration settings specific to the destination go into the dialer interface configuration.

   Step	Command	Purpose
   1.	interface dialer number	Create a Dialer interface.
   2.	ip address ip_address subnet_mask or ip unnumbered interface or ip address negotiated	Specify the IP address and mask of the Dialer interface as a node in the destination network to be called. You can also unnumber the interface to another Up/Up interface on the router or you can have the address obtained during IPCP negotiation
   3.	encapsulation ppp	Specify PPP encapsulation.
   4.	(Optional)ppp authentication chap | pap [callin]	Specify the PPP authentication method. This is only needed if you are not doing CLID or DNIS-based binding. Refer to the section Dialing In for more information
   5.	dialer caller number	Configure the Caller ID (CLID) of the peer (used for binding). Ensure that the telco provides CLID in the incoming call SETUP message.
   6.	(Optional)dialer called DNIS:subaddress	Specifies DNIS and subaddress information that can be used for binding. This is primarily used in Europe and Australia. Note: Configure both the DNIS and subaddress; otherwise, every DNIS binding attempt to this profile will fail.
   7.	dialer remote-name username	Specify the remote router authentication name. If the username is not specified correctly, the call will be disconnected.
   8.	dialer string dial-string class class-name	Specify the remote destination to call and the map class that defines characteristics for calls to this destination. The map-class is optional. This command is only needed if the router is making outbound calls.
   9.	dialer pool pool-number	Specify the dialing pool to use for calls to this destination.
   10.	dialer-group group-number	Assign the Dialer interface to a dialer group. This applies the interesting traffic definition to the interface
   11.	dialer-list group-number protocol protocol-name {permit | deny | list} access-list-number	Specify an access list (in global configuration mode) by list number or by protocol and list number to define the "interesting" packets that can trigger a call. The group-number must be the same as in Step 9

2. (Optional) Configure a map-class to specify different characteristics for different types of calls on a per-call-destination basis. Refer to the section Configuring the map-class dialer Command for more information.

3. Configure the physical interfaces.

   Step	Command	Description
   1.	interface interface_type number	Configure the physical interface parameters for dialer profiles
   2.	(Optional)encapsulation ppp	Specify PPP encapsulation as the default. You can also configure x25, Frame Relay, HDLC, etc. Although the physical interface employs PPP encapsulation, the actual encapsulation running over the B channels are determined by the one configured on the dialer profile bound to this interface.
   3.	(Optional)ppp authentication chap | pap [callin]	Specify the PPP authentication method. This is only needed if you are not doing CLID or DNIS-based binding. Refer to the section Dialing In for more information
   4.	(Optional)ppp multilink	Permit PPP muktilink on this physical interface. This is only needed if you are not doing CLID or DNIS-based binding. Refer to the section Dialing In for more information
   5.	dialer pool-member pool-number	Assign the physical interface to a dialer pool. This pool number should be the same as that configured in Step 9 in the previous table

   Note: If every incoming connection through this physical interface is not bound using CLID or DNIS, then you must configure encapsulation ppp, ppp authentication and ppp multilink (if applicable) on the physical interface.

4. Configure the username and password for CHAP or PAP authentication. For more information on configuring PAP, see Configuring and Troubleshooting PPP Password Authentication Protocol (PAP). For CHAP information, see Understanding and Configuring PPP CHAP Authentication.

5. Configure a static route with the dialer interface as the next hop.

Configuration Example

In the illustration above:

• Dialer interface Dialer1 uses dialer pool 10

• Dialer interface Dialer2 uses dialer pool 20

• Dialer interface Dialer3 uses dialer pool 30

• BRI 0, BRI 1, BRI 2 belong to dialer pool 10

• BRI 1, BRI 2 belong to dialer pool 20

• BRI 2 belongs to dialer pool 30

If interface Dialer1 needs to establish a DDR connection, it will use one of the BRIs in dialer pool 10. In this case, a B channel from BRI 0, BRI 1, or BRI 2 will be used for the call.

If dialer interface Dialer2 needs to make a DDR connection, it uses dialer pool 20 (and by extension BRI 1, or BRI 2).

To avoid contention within a dialer pool, you can prioritize the dialer pool's physical interfaces.

Configuring Dialer Interfaces

These dialer interface configuration tasks are shown in the sample configuration below:

interface Dialer1 
 ip address 1.1.1.1 255.255.255.0

 ! -- IP Address. ! -- For simplicity keep this address in the same network as the peer.


 ! -- If needed, you can unnumber this to another interface instead.

 encapsulation ppp
 dialer remote-name Smalluser

 ! -- Authenticated remote name of the peer. 


 ! -- Verify that this name exactly matches the authenticated name of the remote.

 dialer string 5554540

 ! -- Number for outbound call. For inbound calls this is not needed.


 ! -- Multiple dial strings can be specified for the same dialer interface.

 dialer caller 5554540

 ! -- CLID information used for binding. 

 dialer pool 10

 !-- Member of dialer pool 10.


 !-- The dialer interface can only be a member of 1 pool(the reverse is not true).

 dialer-group 1

 ! -- Interesting traffic is defined by dialer-list 1.

!
interface Dialer2
 ip address 2.2.2.2 255.255.255.0
 encapsulation ppp
 dialer remote-name Mediumuser

 !-- Note that the remote-name is different from the other profiles.


 !-- Do not configure two dialer profiles with the same remote-name.

 dialer string 5554541
 dialer caller 5554541
 dialer load-threshold 50 either

 ! -- Load threshold (50/255=20%) for multilink ppp.

 dialer pool 20
 dialer-group 2
 ppp multilink

 ! -- Dialer 2 can perform Multilink PPP.

!
interface Dialer3
 ip address 3.3.3.3 255.255.255.0
 encapsulation ppp
 dialer remote-name Poweruser
 dialer string 5554542 class Eng

 !--- Dial 5554542 and use the map-class named "Eng" (defined below).

 dialer caller 5554542
 dialer hold-queue 10
 dialer load-threshold 80

 ! -- Load threshold (80/255=32%) for multilink ppp.

 dialer pool 30
 dialer-group 2
 ppp multilink

 ! -- Dialer 3 can perform Multilink PPP.

!
map-class dialer Eng

!--- Map-class named "Eng" that was used with the dialer string in Dialer3.

 isdn speed 56

Note: Configure a dialer interface for every remote device you need to connect to.

Minimum Commands Needed to Configure the Dialer Interface:

• Use the dialer remote-name user-name command to specify the remote destination. This is the remote router name passed for authentication.

• Use the dialer string string command to specify the number to dial (for outbound calls). If necessary, you can configure a map-class.

• Use the dialer caller lookup command to specify the CLID of the peer.

• Use the dialer pool number command to bind a dialer interface to a dialer pool. Note that a dialer interface can only be associated with one dialer pool, but a dialer pool can be associated with many dialer interfaces.

• The dialer-group group-number command is used to reference a dialer list which defines the "interesting" traffic.

Note: The dialer-list dialer-group protocol protocol-name {permit | deny | list access-list-number} command specifies a protocol or an access list number that defines "interesting" packets to trigger a call.

Configuring the map-class dialer Command

You can use the map-class dialer class-name command to specify a map-class and enter the map-class configuration mode. The table below shows the options:

Command	Description
dialer isdn [speed <56>] | [no-spc]	Specifies the ISDN line speed 56 Kbps. Note: 64 Kbps is the default. The speed parameter is used only with 56 Kbps line speed; 64 is not a valid option. Note: Contact your telco to determine if this is necessary.
dialer idle-timeout number	Specifies the idle timer values to use when placing a call. The default is 120 seconds. Note: you can configure the idle-timeout in the dialer interface as well.
dialer fast-idle number	Specifies the fast idle timer values to use when placing a call. This is used when there is congestion for a physical interface. The default is 20 seconds.
dialer wait-for-carrier-time number	Specifies the carrier time value to use when placing a call.

Note: Some of the dialer commands shown above can be configured under the dialer interface or the map-class directly. The same command may appear more than once, possibly with different parameters. The order of precedence is from highest to lowest:

• map-class parameters

• interface parameters

Configuring Physical Interfaces

Use the dialer pool-member number command to assign a physical interface to a dialer pool. You can assign an interface to multiple dialer pools by using this interface configuration command to specify several dialer pool numbers.

Use the priority option of this command to set the interface's priority within a dialer pool.

interface BRI0
   no ip address
   encapsulation ppp
  
 ! -- Specify that the default encapsulation for this interface is ppp. ! -- Although BRI0 employs ppp encapsulation, the actual encapsulation ! -- running over the B-channels are determined by the one configured ! -- on the dialer profile bound to this interface. 
   dialer pool-member 10 priority 100

 ! -- BRI 0 is a member of pool 10.

  !
  interface BRI1
   no ip address
   encapsulation ppp
   dialer pool-member 10 priority 50
   
! -- BRI 1 is a member of pool 10. ! -- Note that the priority is less than BRI 0. 
   dialer pool-member 20 priority 100
   
! -- BRI 1 is a member of pool 20. ! -- Note that the priority is higher than BRI 2. 
  !  
  interface BRI2
   no ip address
   encapsulation x25
  
 ! -- Although BRI2 employs X25 encapsulation, ! -- the actual encapsulation running over the B-channels ! -- are determined by the one configured on the dialer profile ! -- bound to this interface. 
   dialer pool-member 10 priority 10

 ! -- BRI 1 is a member of pool 10. ! -- Note that the priority is less than BRI 0 and BRI 1. 
   dialer pool-member 20 priority 50

 ! -- BRI 2 is a member of pool 20. ! -- Note that the priority is lower than BRI 1. 
   dialer pool-member 30
   ...
   ...
   ...

Note: If you cannot do CLID or DNIS-based binding, you must configure the commands encapsulation ppp, ppp authentication chap | pap [callin] and ppp multilink (if applicable) under the physical interface.

The dialer pool-member optional command parameters include:

Parameter	Description
number	Sets the dialer pooling number. This is a decimal value from 1 to 255.
priority number	Sets the priority of the physical interface within the dialer pool. Interfaces with a priority number are selected first for dial out. This is a decimal value from 1 to 255. A larger value indicates a higher priority. This is only needed if there is contention on physical interfaces for outbound calls.
min-link number	ISDN B channels on an interface reserved for this dialer pool. This is a number from 1 to 255. This can be used as a simple channel reservation system.
max-link number	Sets the maximum number of ISDN B channels on an interface reserved for this dialer pool. This is a number from 1 to 255.

Dialer Profile Sample Configuration

For a comprehensive sample configuration using dialer profiles, refer to Configuring ISDN DDR with Dialer Profiles.

For non-PPP configuration examples, refer to the following documents:

• HDLC: ISDN DDR using HDLC Encapsulation with Dynamic Multiple Encapsulations

• X.25 and Frame Relay: Dynamic Multiple Encapsulations for Dial-In over ISDN

Tuning and Optional Commands

Refer to the document Peer-to-Peer DDR with Dialer Profiles Commands for more information on tuning and optional commands.

Verifying Dialer Profiles Operation

The show interface dialer1 command displays information on incoming and outgoing calls:

Router# show interfaces dialer1
Dialer1 is up, line protocol is up (spoofing)

! -- The dialer interface is up/up(spoofing). ! -- Dialer interface is always up(spoofing) so that the route ! -- to the dialer interface remains in the routing table. ! -- Refer to the Note below. 
  Hardware is Unknown
  Internet address is 1.1.1.1/24

 ! -- IP address for the dialer interface.

  MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation PPP, loopback not set

 ! -- Encapsulation on the dialer interface.

  DTR is pulsed for 1 seconds on reset
  Interface is bound to BRI0:1

 ! -- This dialer is bound to 1 B-channel. 

  Last input 00:00:38, output never, output hang never
  Last clearing of "show interface" counters 00:05:36
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     38 packets input, 4659 bytes
     34 packets output, 9952 bytes
Bound to:
BRI0:1 is up, line protocol is up


! -- B-channel to which Dialer1 is bound to.

  Hardware is BRI
  MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation PPP, loopback not set, keepalive not set
  Interface is bound to Dialer1 (Encapsulation PPP)

 ! -- Encapsulation applied by the dialer profile.

  LCP Open, multilink Open
  Last input 00:00:39, output 00:00:11, output hang never
  Last clearing of "show interface" counters never
  Queueing strategy: FIFO
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     78 packets input, 9317 bytes, 0 no buffer
     Received 65 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     93 packets output, 9864 bytes, 0 underruns
     0 output errors, 0 collisions, 7 interface resets
     0 output buffer failures, 0 output buffers swapped out
     4 carrier transitions

Note: The dialer interface will always be at least up/up (spoofing). The word spoofing indicates that the line really is not up, but the dialer is forcing the line to masquerade as "up" so that upper level protocols will continue to operate as expected. Spoofing is a state added to allow DDR to work. The interface "dials on demand" in response to packets being routed to it. But because no packets are routed to "down" interfaces, the interface must pretend to be up (spoof) so packets will be routed to it even when it is not connected. Spoofing is the normal state on a dial-on-demand interface.

Troubleshooting Dialer Profiles

Symptom	debug command	Resolution
Dialing never occurs	debug dialer	Confirm interesting traffic, routing configuration, dialer phone number and dialer pool settings.
Incoming calls do not connect properly	debug dialer	Confirm whether one of the three binding steps will succeed.
Calls are disconnected prematurely, or calls never disconnect	debug dialer packet	Confirm interesting packet configuration

As is the case with Legacy DDR, the most appropriate command for debugging dialer profile problems is debug dialer. In the case of a successful call, the debug will not indicate any more than the logged messages already have. In the case of a failure, there are a number of problems that can be the cause.

Dialing Never Occurs

Turn on debug dialer and generate interesting traffic to the peer. The router should attempt to dial. The following is an example output:

maui-soho-01#ping 10.1.1.1

     Type escape sequence to abort.
     Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:

     *Mar 1 00:24:47.242: BR0 DDR: rotor dialout [priority]
     *Mar 1 00:24:47.250: BR0 DDR: Dialing cause ip (s=192.168.1.1, d=10.1.1.1)
     *Mar 1 00:24:47.250: BR0 DDR: Attempting to dial 5551111

Check to see if debug dialergenerates any debug output. If there is no debug dialer output at all, or if binding fails, this is most likely because the IP packet you are sending is not even routed to the Dialer interface. Follow the procedure below. For more information on binding, refer to the Dialing Out section of this document.

Troubleshooting Binding Issues for Outbound Calls

Follow these steps to troubleshoot binding issues for outbound calls.

1. If the dialer profile is not associated with a dialer pool, debug dialer will indicate the following for an outbound call:

   *Mar 1 07:20:45.676: Di15: Cannot place call, no dialer pool set

   Solution: Configure the dialer pool command on the dialer interface.

2. If the physical interface is not associated with any pool, the debug message on the calling router will be the same as in the case where no more physical interfaces are available, causing the fast idle timer to trigger

   *Mar 1 11:54:14.937: Di15: No free dialer - starting fast idle timer

   Solution: Configure the dialer pool-member command on the physical interface to associate it to a dialer pool

Troubleshooting Routing Issues for Outbound Calls

Once you have verified that the dialer pool configuration is correct:

1. Verify that IP is configured on the Dialer interface. You should either have an ip address on the interface or ip unnumbered type number (where type number is another interface on which the router has an assigned IP address) or ip address negotiated.

2. Check whether the command ip routing is configured. When you look at your configuration using the show running-config command, you should not see the command no ip routingconfigured.

3. Ensure that there is a static route pointing at the Dialer interface. The following example is a static route for 172.22.53.0/24 with next hop Dialer 1:

   maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 dialer 1
   

4. Verify that the dialer interface is not in shutdown state. Use the show interface dialer interface command to verify the interface is up/up or check to see if no shutdown exists under the dialer interface configuration.

There is Debug Output, but No "Attempting to Dial" Message

In this case, there is probably an IP packet routed to the interface, but the router discards it and does not initiate the call for some reason. Look at the debug dialer output in order to find out why the call attempt is not made. Below are some problems indicated by debug dialer and their possible reasons:

Example 1

*Mar  1 00:07:22.255: Di1 DDR: ip (s=10.1.0.1, d=192.168.201.1), 
       100 bytes, outgoing uninteresting (no dialer-group defined).

There is no dialer-group configured on the Dialer interface. Add a dialer-group as in the following example:

 interface Dialer1
       dialer-group 1

Example 2

*Mar  1 00:08:24.919: Di1 DDR: ip (s=10.1.0.1, d=192.168.201.1), 
       100 bytes, outgoing uninteresting (dialer-list 1 not defined).

There is a dialer-group statement on the Dialer interface, but the dialer-list referred to does not exist. Configure the dialer-list as in the following example:

dialer-list group-number protocol ip permit

Note: the value for group-number should be the same as the one configured in dialer-group group-number . In this example, configure dialer-list 1.

Example 3

*Mar  1 00:25:32.551: Di1 DDR: ip (s=10.1.0.1, d=192.168.201.1), 
       100 bytes, outgoing interesting (ip PERMIT)
     *Mar  1 00:25:32.555: Di1 DDR: No free dialer - starting fast idle timer.

In this case, the outgoing packet is to be considered interesting enough to bring up the link, but there is no physical interface available to place the call. Make sure that dialer pool-member number is configured in the physical interface and dialer pool number is configured in the Dialer interface. Example:

interface BRI0
      dialer pool-member 1
     !
     interface Dialer1
      dialer pool 1

Also, verify that the physical interface is not in shutdown state. Use the no shutdown command on the physical interface.

Example 4

*Mar  1 00:37:24.235: Di1 DDR: ip (s=10.1.0.1, d=192.168.201.1), 
       100 bytes, outgoing interesting (ip PERMIT)
     *Mar  1 00:37:24.239: Di1 DDR: Cannot place call, no dialer string set.

In this case, no dialer string dial-string is configured on the Dialer interface. The router wants to place a call but does not know the number to call. Define a dialer-string:

interface Dialer1
      dialer string 8134

Incoming Calls Do Not Connect Properly

A call failure with dialer profile may be due to problems binding the physical interface with the dialer interface for that call. Verify that the router meets one of the conditions for binding as described in section Dialing In above. Follow the steps below:

1. If the dialer profile is not associated with a dialer pool, debug dialer indicates the following for an inbound call:

   *Mar 1 11:51:24.873: BRI0:1: 
   Authenticated host HQ-NAS with no matching dialer profile

   Solution: Configure the dialer pool command on the dialer interface.

2. Remember that there are four attempts to bind. Assuming that we have more than one dialer profile, the CLID and DNIS bind attempt fails and PPP authentication is not configured (pre-empting the possibility of the fourth test). The following debug dialer message will be generated on the called router.

   *Mar 1 11:59:36.521: ISDN BR0:1: Incoming call rejected, unbindable

   Solution: Configure ppp authentication chap | pap [callin] on the physical interface.

3. If PPP authentication is enabled on the physical interface, then the fourth attempt to bind will proceed. The router will use the authenticated username to attempt to bind to one of the dialer interfaces in the dialer pool. If that attempt fails, the following debug will be seen on the called router:

   *Mar 1 12:03:32.227: BRI0:1: 
   Authenticated host HQ-NAS with no matching dialer profile

   Solution: Configure the dialer remote-name command on the dialer interface. The name specified must exactly match the username provided by the remote router for authentication. In this example, the authenticated username is HQ-NAS.

Calls are Disconnected Prematurely, or Calls Never Disconnect

If the call disconnects unexpectedly or the call never disconnects, check the dialer idle-timeout and interesting traffic definition. You can use the debug dialer packet command to see if a particular packet is interesting or not. For example:

Apr 26 01:57:24.483: Di1 DDR: ip (s=192.168.1.1, d=224.0.0.5), 64 bytes,
  outgoing uninteresting (list 101)
Apr 26 01:57:26.225: Di1 DDR: ip (s=192.168.1.1, d=10.1.1.1), 100 bytes,
  outgoing interesting (list 101)

In the above example, Open Shortest Path First (OSPF) hellos are uninteresting per access-list 101, while the second packet is interesting per access-list 101.

1. Adjust the dialer idle-timeout in the dialer interface configuration. The default is 120 seconds, but you may wish to raise or lower this value depending on your needs.

2. Change the interesting traffic definition (configured with the dialer-list command). If the call disconnects prematurely, you may wish to define the interesting traffic more loosely. If the call never disconnects, change your interesting traffic definition to be more restrictive. For example, you can define routing protocol traffic as uninteresting. Here is a sample interesting traffic definition:

   access-list 101 remark Interesting traffic for dialer-list 1
   access-list 101 deny ospf any any
   
   !--- Mark OSPF as uninteresting. This will prevent OSPF hellos !--- from keeping the link up. 
   access-list 101 deny udp any any eq ntp
   
   !--- Define ntp traffic as NOT interesting. !--- This will prevent periodic ntp traffic from keeping the !--- link up indefinitely. 
   access-list 101 permit ip any any
   
   !--- All other IP traffic is interesting. Change this depending on your !--- traffic needs. 
   dialer-list 1 protocol ip list 101

For more information, refer to the document Dialup Technology: Overviews and Explanations.

Related Information

• Configuring ISDN DDR with Dialer Profiles
• Configuring a Router to Dial Multiple Sites using ISDN BRI
• ISDN BRI Troubleshooting Flowchart
• Dial-on-Demand Routing Configuration
• Technical Support & Documentation - Cisco Systems