Introduction

This document helps you to troubleshoot ISDN Basic Rate Interface (BRI) dialup
access. In the flowchart and sample output shown below, we have set up an ISDN
BRI connection to another using Dialer Profiles. However, the same troubleshooting
steps apply to connections to other routers (such as branch offices) and when
using Legacy Dial-on-Demand Routing (DDR).

Flowchart

Click on a link below to get more information about the item. Use your browser's
back button to return to this flowchart.

Troubleshooting: How to Log In and Capture These Debugs

You can connect to your router either through the console cable attached to your
PC's Serial port, or by using telnet.

If you need to connect to your router through the console, please refer to
Applying
Correct Terminal Emulator Settings for Console Connections. If your router
is already set up for connectivity on the Ethernet and you want to connect to
your router using telnet, simply use a telnet client to connect to the router's
Ethernet IP address.

In any case (console or telnet), it is better to use a client that allows
you to keep a history of the output received during the session, as you may
have to scroll back in your debug output to look for particular messages.

Activate milliseconds on the debug output and log messages. When prompted,
enter the password configured on your router and enter enable mode:

Symptom: The Router does not Attempt to Dial

If your router is not attempting to dial, there are several possibilities:

No Debug Output at all

If there is no debug output at all, this is most likely because the IP packet
you are sending is not even routed to the Dialer interface. The most common
causes for this are:

Verify that IP is configured on the Dialer interface. You should either
have an ip address on the dialer interface or ip unnumbered interface
(where interface is an up/up interface such as ethernet x, loopback
x etc) or ip address negotiated (if the client will obtain an
IP address from the NAS). If you use legacy DDR, then the IP address should
be configured on the physical interface (example, interface BRI 0).

Verify that 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 routing.

Verify that there is a static route pointing at the dialer interface or
next hop (if using dialer maps).

The following example (for dialer profile) 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

The following example (for legacy DDR) is a static route for 172.22.53.0/24
with next hop 172.16.1.1. The next hop address should match the ip address
in the dialer map statement that is used for the dial:

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

Verify that the dialer or physical interface is not in administratively
down or standby state. Use the show interface dialer X or show
interface bri X command to ensure that the interface is in the
state up/up (spoofing).

If the interface is administratively down, then use the no shutdown
command in interface configuration mode.

If the interface is in standby state, then the dialer or BRI interface is
a backup to a connection that is up. You can either remove the backup interface
command under the primary interface or pull the cable from the primary interface.

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 output in order to find out why the call attempt is not
made. Below are some sample debug outputs and their possible reasons:

Example 1

The traffic generated does not match the interesting traffic definition.
For this example, modify access-list 101.

A simple interesting traffic defintion would be to permit all IP traffic
as in:

maui-soho-01(config)#dialer-list 1 protocol ip permit

Warning: Marking all IP traffic as interesting may cause the ISDN
link to stay up indefinitely, especially if you have a routing protocol or
other periodic traffic. Adjust the interesting traffic definition to suit
your needs.

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 X is configured in the physical
interface and dialer pool X is configured in the Dialer interface. Example:

Verify that the ISDN circuit is properly functioning. Use the show isdn
status command to verify that Layer 1 is ACTIVE, Layer 2 is MULTIPLE_FRAME_ESTABLISHED
and the SPIDs (if needed) are valid. For more information refer to the document
Using the show isdn status
Command for BRI Troubleshooting.

If you have the output of a show isdn status command from your Cisco
device, you can use
to display potential issues and fixes. To use
, you must be a registered user, be logged in, and
have JavaScript enabled. You can use Output Interpreter to display
potential issues and fixes. To use Output Interpreter, you must be a registered
user, be logged in, and have JavaScript enabled.

Verify that the configured ISDN dialer string is correct. Keep in mind that
you may have to add a leading zero, nine or other digits to get an outside
line when you are connected through a PBX.

If the connection uses a long distance carrier contact your local telco
and long distance provider to verify that the service is activated. Often,
the local Telco has the ISDN circuit misconfigured such that outbound ISDN
long distance calls are not switched over to the appropriate long distance
provider network. You should also verify that the long distance providers
network is functioning.

In the U.S., and in situations where the Telco or long distance provider
is unable to rectify the problem, you may wish to use a Presubscribed Interexchange
Carrier (PIC). PIC codes are seven-digit prefixes which identify U.S. long
distance carriers to the local exchange carriers (LEC). This allows customers
to use different long-distance carriers for individual calls. The PIC code
is configured as a prefix to the dialed number. Most PICs are of the format
1010xxx.

Use no dialer string xxxxx or no dialer map to remove the existing
number and then configure the new number.

For example, dialer string 10103215125551111.

Look for an ISDN disconnect message.

The Cisco IOS® software decodes the cause-code in this disconnect message
and gives you a clear text message that often contains useful information
leading to the cause of the problem. Possible strings that you may find
here include:

Unallocated or unassigned number

Incompatible destination (both of which indicate that the dialled number
might be incorrect)

Referring to the Disconnect
Cause Codes document referenced previously, we can determine that the
disconnect code was caused by an attempt to connect to a non-ISDN equipment
(for example, an analog line).

A disconnect due to an improperly formatted number may be indicated with:

Referring to the document Understanding
debug isdn q931 Disconnect Cause Codes, we can determine that the disconnect
code was caused by an invalid format for the remote ISDN number. The connection
fails because the destination address is presented (to the switch) in an
unrecognizable format, or the destination address is incomplete.

The following example shows a rejected call due to an incorrect ISDN number:

If your Telco has provided you with service profile identifiers (SPIDs)
to be used, make sure these SPIDs are configured on the BRI interface. SPIDs
are commonly used only in the U.S. and with NI and DMS switchtypes (5ess switchtypes
do not need SPIDs).

If you have the output of a show isdn status command from your Cisco
device, you can use
to display potential issues and fixes. To use
, you must be a registered user, be logged in, and
have JavaScript enabled. You can use Output Interpreter to display
potential issues and fixes. To use Output Interpreter, you must be a registered
user, be logged in, and have JavaScript enabled.

The remote end not being configured for PPP. Configure the command encapsulation
ppp on the remote end

Packets not getting through the transmission media. The most common cause
for this is an ISDN speed mismatch

The nature of the problem, from an ISDN standpoint, is that one side is probably
connecting at 56k while the other side is connecting at 64k. It is possible
that the local or remote circuit will not support the default 64K connections.
Try configuring both ends to run at 56k.

For Dialer Profiles:

maui-soho-01(config)#interface Dialer1maui-soho-01(config-if)#dialer string 81560 class 56k! -- Dial 81560 and use the map-class named "56k" (defined below)maui-soho-01(config-if)#exitmaui-soho-01(config)#map-class dialer 56k! -- map-class named "56k" that was used with the dialer string
! -- in int Dialer1maui-soho-01(config-map-clas)#dialer isdn speed 56! -- Set the speed of the call to be 56k (default is 64k)

Note: Configure only the username and password for the authentication
method you and your peer employ. For example, if you both will not use PAP,
then you do not need the ppp pap sent-username command. However, if you
are unsure whether the peer support PAP or CHAP, then configure both.

Depending on your Cisco IOS software version and configuration, the password
may show up encrypted in your configuration. If this is the case, when doing
a show running-configuration command, you see the word "password" followed
by the digit 7 and then a sequence of numbers, such as in the following example:

interface Dialer1
ppp chap password 7 140005

In this case, you are not able to verify whether the configured password is
correct or not by looking at the configuration. To be sure that the password
is correct, simply enter configuration mode and remove and configure the password
once again. To identify a password failure in the debug, compare your debug
output with the sample output below.

If this router will authenticate the peer, then be sure to configure the command
usernameusernamepasswordpassword, where username
is the name supplied by the peer router for authentication.

Example 1

A message like the one below means that the CHAP password is not valid.

Tip: An incoming CHAP failure (indicated by CHAP: I FAILURE)
means that the peer was unable to authenticate the router. Use debug ppp
negotiation on the peer router to determine the exact cause of the failure.

Tip: An incoming CHAP failure (indicated by CHAP: I FAILURE)
means that the peer was unable to authenticate the router. Use debug ppp
negotiation on the peer router to determine the exact cause of the failure.

Troubleshooting: Does the PPP NCP (IPCP) Phase Complete?

The key element negotiated in IPCP is each peer's address. Before IPCP negotiation,
each peer is in one of two possible states; either it has an IP address or it
does not. If the peer already has an address, it sends that address in a CONFREQ
to the other peer. If the address is acceptable to the other peer, a CONFACKis
returned. If the address is not acceptable, the reply is a CONFNAK containing
an address for the peer to use.

This is the only phase that cannot be properly identified by looking at just
one line. In order to be sure that IP Control Protocol (IPCP) is coming up properly,
you need to verify that IP addresses have been negotiated in both directions.
Look at your debug for the following lines:

These three sets of lines may not immediately follow each other. It is important
that you check whether there is an outgoing Configure Acknowledge (O CONFACK)
that has, among other options, an address beneath it.

There must also be an incoming Configure Acknowledge (I CONFACK) with another
IP address beneath it.

Finally, there must be a line stating that IPCP state is open. After this,
you should be able so successfully ping both IP addresses directly from your
router.

Symptom: PPP NCP (IPCP) Negotiation Does Not Succeed

Problem: IP Address Negotiation Fails

One of the reason why IPCP could fail is due to an IP address negotiation failure.
For example, the NAS may be trying to assign an address to the client while
the client router has a different IP address configured or another common problem
is when the client requests an address and the NAS does not have any addresses
available for the client.

On the Calling Router:

If the called router assigns an IP address dynamically to the calling router,
verify that you have the command ip address negotiated in the dialer
interface.

If NAS Provider/ISP has given you a static IP address, verify that this ip
address (and subnet mask) is configured in the dialer interface with the command
ip address address subnet_mask.

On the Called Router:

Ensure interface controlling the connection (for example, int Dialer x) has
an IP address and is assigning an address to the peer using the peer default
ip address address command.

Note: If the client router has an IP address configured then you do
not need to assign an address using the peer default ip address command

Problem: The Called router fails Dialer Profile Binding

If the authenticated username does not match the dialer remote-name
configured under the dialer interface, then the call will be disconnected by
the called router. The following is a sample debug dialer output for such an
error:

On the Calling Router:

The following debug shows a disconnect caused by a bad dialer profile binding
on the called router;

Configure the dialer pool number command on the dialer interface.
The pool number must match the pool number configured on the physical interface.

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 maui-soho-03.

Post-Connection Problems

Symptom: Call Disconnects Prematurely or Call Does
Not Disconnect at All

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

In the above example, OSPF hellos are uninteresting per access-list 101, while
the second packet is interesting per access-list 101.

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.

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:

Symptom: Router Periodically Dials the Connection

In certain situations, you may observe that the router periodically dials the
connection, even though there is no apparent user traffic requiring the link
to be up. This can result in high toll charges where ISDN service is charged
on a per-minute basis.

The most common cause is that a proccess that generates periodic traffic (such
as a routing protocol, ntp, snmp etc.) may be inadvertently designated as interesting.
Troubleshooting this is a two-step issue:

Identify the traffic that causes the link to dial.

Designate that traffic as uninteresting.

Identify the Traffic that Causes the Link to Dial.

To identify the traffic that causes the link to dial, you need to enable debug
dialer packet. Monitor the router while the ISDN link is down and watch
for some periodic interesting traffic that attempts to bring up the link.

The only way to identify that the above packet is an OSPF hello is from the
destination address (d=224.0.0.5) which is defined for OSPF. The following table
lists the addresses used for some common routing protocols:

Routing Protocol

Destination Address for Periodic
Updates or Keepalives

RIPv1

255.255.255.255

RIPv2

224.0.0.9

EIGRP

224.0.0.10

OSPF

224.0.0.5

The traffic causing the router to dial (routing procol or other periodic traffic)
should be marked as uninteresting.

Designate the Periodic Traffic as Uninteresting

Change the interesting traffic definition (configured with the dialer-list
command). In this example, define OSPF and NTP traffic as uninteresting. Here
is a sample interesting traffic definition:

IP Connectivity Issues

If the ISDN link comes up but you cannot pass traffic accross the link then
the issue is probably a routing or NAT related problem. Refer to the Cisco Support Community for more troubleshooting information.