ISDN BRI Troubleshooting Flowchart
Available Languages
Contents
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).
Note: You can also use the Cisco Support Community in order to help you resolve your ISDN issue.
For introductory information on ISDN and DDR, refer to the audio training located in the Cisco Learning Connection.
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:
router>enable Password: (enter the enable password) router# router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#service timestamps debug datetime msec router(config)#service timestamps log datetime msec
If you are connected using telnet, type terminal monitor as follows:
router#terminal monitor router#
Following this, enter the debug commands below:
router#debug isdn q931 ISDN Q931 packets debugging is on router#debug ppp negotiation PPP protocol negotiation debugging is on router#debug dialer packet Dial on demand packets debugging is on router#debug dialer Dial on demand events debugging is on router#debug ppp authentication PPP authentication debugging is on router#
Then initiate the ping on the calling router. Below is a sample debug output of a successful call. The different phases, as identified in the flowchart, are highlighted.
router#ping 194.183.201.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 194.183.201.1, timeout is 2 seconds: *Mar 1 00:06:36.383: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) ! -- The ping for 194.183.201.1 is interesting traffic and uses Dialer 1(Di1) *Mar 1 00:06:36.387: BR0 DDR: rotor dialout [priority] *Mar 1 00:06:36.391: BR0 DDR: Dialing cause ip (s=10.1.0.1, d=194.183.201.1) *Mar 1 00:06:36.395: BR0 DDR: Attempting to dial 8134 ! -- Number used to dial.
! -- This is configured using the dialer string or dialer map command
! -- If you do not see this message proceed to section
! -- Symptom: The Router Does Not Attempt to Dial *Mar 1 00:06:36.411: ISDN BR0: TX -> SETUP pd = 8 callref = 0x02 *Mar 1 00:06:36.415: Bearer Capability i = 0x8890 *Mar 1 00:06:36.423: Channel ID i = 0x83 *Mar 1 00:06:36.427: Called Party Number i = 0x80, '8134', Plan:Unknown, Type:Unknown *Mar 1 00:06:36.519: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x82 *Mar 1 00:06:36.527: Channel ID i = 0x89 *Mar 1 00:06:36.727: ISDN BR0: RX <- CONNECT pd = 8 callref = 0x82 *Mar 1 00:06:36.743: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x02 *Mar 1 00:06:36.751: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up ! -- ISDN Layer 3 CONNECT message and Link Up message ! -- If you do not see this message proceed to section ! -- Symptom: The ISDN Call Does Not Connect Successfully *Mar 1 00:06:36.767: BR0:1: interface must be fifo queue, force fifo *Mar 1 00:06:36.775: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1 *Mar 1 00:06:36.787: BR0:1 PPP: Treating connection as a callout *Mar 1 00:06:36.791: BR0:1 PPP: Phase is ESTABLISHING, Active Open ! -- LCP negotiation begins *Mar 1 00:06:36.791: BR0:1 PPP: No remote authentication for call-out *Mar 1 00:06:36.795: BR0:1 LCP: O CONFREQ [Closed] id 3 len 10 *Mar 1 00:06:36.799: BR0:1 LCP: MagicNumber 0x0012586A (0x05060012586A) *Mar 1 00:06:36.859: BR0:1 LCP: I CONFREQ [REQsent] id 59 len 15 *Mar 1 00:06:36.863: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 00:06:36.867: BR0:1 LCP: MagicNumber 0x10D36A4C (0x050610D36A4C) *Mar 1 00:06:36.871: BR0:1 LCP: O CONFACK [REQsent] id 59 len 15 *Mar 1 00:06:36.875: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 00:06:36.875: BR0:1 LCP: MagicNumber 0x10D36A4C (0x050610D36A4C) *Mar 1 00:06:36.879: BR0:1 LCP: I CONFACK [ACKsent] id 3 len 10 *Mar 1 00:06:36.883: BR0:1 LCP: MagicNumber 0x0012586A (0x05060012586A) *Mar 1 00:06:36.887: BR0:1 LCP: State is Open ! -- LCP negotiation is complete. Any LCP state other than Open indicates
! -- that LCP negotiation has failed.
! -- If you do not see this message proceed to section
! -- Symptom: PPP LCP Phase Does Not Succeed *Mar 1 00:06:36.903: BR0:1 PPP: Phase is AUTHENTICATING, by the peer *Mar 1 00:06:36.907: BR0:1 CHAP: I CHALLENGE id 38 len 24 from "ISP" ! -- Incoming CHAP challenge *Mar 1 00:06:36.915: BR0:1 CHAP: Using alternate hostname XXXXX ! -- Using alternate hostname configured with ppp chap hostname command *Mar 1 00:06:36.915: BR0:1 CHAP: Username ISP not found *Mar 1 00:06:36.919: BR0:1 CHAP: Using default password ! -- Using password configured with ppp chap password command *Mar 1 00:06:36.923: BR0:1 CHAP: O RESPONSE id 38 len 26 from "XXXXX" ! -- Sending response from "XXXXX" which is the alternate hostname for the router *Mar 1 00:06:36.939: BR0:1 CHAP: I SUCCESS id 38 len 4 ! -- NAS has succesfully authenticated the router *Mar 1 00:06:36.943: BR0:1 PPP: Phase is UP ! -- PPP Authentication is successful ! -- PPP NCP (IPCP) negotiation begins *Mar 1 00:06:36.947: BR0:1 IPCP: O CONFREQ [Not negotiated] id 3 len 10 *Mar 1 00:06:36.951: BR0:1 IPCP: Address 0.0.0.0 (0x030600000000) ! -- This router does not have an address configured, so it sends a
! -- CONFREQ with the address 0.0.0.0. This tells the other peer to assign an address
! -- which is accomplished by the sending of a CONFNAK with the proper address. *Mar 1 00:06:36.955: BR0:1 IPCP: I CONFREQ [REQsent] id 26 len 10 *Mar 1 00:06:36.963: BR0:1 IPCP: Address 194.183.201.1 (0x0306C2B7C901) ! -- Incoming CONFREQ indicating the peer's IP address *Mar 1 00:06:36.967: BR0:1 IPCP: O CONFACK [REQsent] id 26 len 10 *Mar 1 00:06:36.971: BR0:1 IPCP: Address 194.183.201.1 (0x0306C2B7C901) ! -- The router accepts the peer's IP address
! -- (since it is not trying to assign one to the peer)
! -- Once the call is connected a route to this address will be installed *Mar 1 00:06:36.975: BR0:1 IPCP: I CONFNAK [ACKsent] id 3 len 10 *Mar 1 00:06:36.979: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- The peer CONFNAKs our initial Address request of 0.0.0.0
! -- It responds with the address that this router could use
! -- The NAS can assign this using the peer default ip address or dialer map command *Mar 1 00:06:36.983: BR0:1 IPCP: O CONFREQ [ACKsent] id 4 len 10 *Mar 1 00:06:36.987: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- This router requests the address previously suggested by the NAS *Mar 1 00:06:37.011: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10 *Mar 1 00:06:37.015: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- NAS accepts the address requested by the client *Mar 1 00:06:37.015: BR0:1 IPCP: State is Open ! -- PPP NCP (IPCP) negotiation is complete ! -- If you do not see this message proceed to section
! -- Symptom: PPP NCP (IPCP) negotiation does not succeed *Mar 1 00:06:37.019: Di1 IPCP: Install negotiated IP interface address 194.183.201.2 *Mar 1 00:06:37.031: BR0:1 DDR: dialer protocol up *Mar 1 00:06:37.039: Di1 IPCP: Install route to 194.183.201.1 ! -- Route to peer is installed *Mar 1 00:06:37.943: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up *Mar 1 00:06:38.383: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.427: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.471: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.515: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) router# *Mar 1 00:06:42.783: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8134 unknown router#
Back to the troubleshooting flowchart
Troubleshooting: Does the Router Attempt to Dial?
In order to find out whether the router attempts to place a call, verify whether you have the following lines in the debug output of the calling router:
*Mar 1 00:06:36.395: BR0 DDR: Attempting to dial 8134
In the debug output, 8134 is the ISDN directory number the router is attempting to dial. This number was specified using the dialer string or dialer map command.
Back to the troubleshooting flowchart
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
*Mar 13 10:43:50.253: Di1 DDR: ip (s=10.1.1.1, d=172.22.53.1), 100 bytes, outgoing uninteresting (list 101).
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.
For more information on interesting traffic, refer to the document Dialup Technology: Overviews and Explanations.
Example 2
*Mar 1 00:07:22.255: Di1 DDR: ip (s=10.1.0.1, d=194.183.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 X
Note: The value for X should be the same one used with the dialer-list command.
Example 3
*Mar 1 00:08:24.919: Di1 DDR: ip (s=10.1.0.1, d=194.183.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 X protocol ip permit
Note: The value for X should be the same one used with the dialer-group command under the dialer interface.
Example 4
*Mar 1 00:25:32.551: Di1 DDR: ip (s=10.1.0.1, d=194.183.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 X is configured in the physical interface and dialer pool X is configured in the Dialer interface. Example:
interface BRI0 dialer pool-member 1 ! interface Dialer1 dialer pool 1
Also, verify that the BRI interface is not in shutdown state.
Example 5
*Mar 1 00:37:24.235: Di1 DDR: ip (s=10.1.0.1, d=194.183.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 is configured on the dialer interface. The router wants to place a call but does not know the ISDN directory number to call. Define a dialer-string:
interface Dialer1 dialer string 8134
For more troubleshooting information, refer to the section "The Calling Router does not send a SETUP Message" in the document Troubleshooting ISDN BRI Layer 3 using the debug isdn q931 Command.
Back to the troubleshooting flowchart
Troubleshooting: Does the ISDN Call Connect Successfully?
In order to identify whether the ISDN call connects, look for a CONNECT_ACK and %LINK-3-UPDOWN message in the debugs:
*Mar 1 00:06:36.743: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x02 *Mar 1 00:06:36.751: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
If you see this message, your ISDN call connected successfully and you may proceed to the next step. If you do not see a message like this, read below for possible causes.
Back to the troubleshooting flowchart
Symptom: The ISDN Call does not Connect Successfully
- If you see output similar to the following, verify that the ISDN cable is plugged in both the router and the Telco jack.
*Mar 1 21:31:18.190: Di1 DDR: ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 21:31:18.190: BR0 DDR: rotor dialout [priority] *Mar 1 21:31:18.198: BR0 DDR: Dialing cause ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4) *Mar 1 21:31:18.198: BR0 DDR: Attempting to dial 8134. *Mar 1 21:31:20.186: Di1 DDR: ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4), 100 bytes, outgoing interesting (ip PERMIT). *Mar 1 21:31:26.226: ISDN BR0: Could not bring up interface *Mar 1 21:31:26.226: BRI0: wait for isdn carrier timeout, call id=0x849E *Mar 1 21:31:26.246: ISDN BR0: Could not bring up interface. Success rate is 0 percent (0/5)
- 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 Cisco CLI Analyzer to display potential issues and fixes. To use Cisco CLI Analyzer, 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)
- Number busy (which indicates that the called side is busy)
- Temporary failure (which indicates a temporary outage on the Telco network)
In order to find the possible reason for a specific disconnect cause, please refer to Understanding debug isdn q931 Disconnect Cause Codes.
For example, a disconnect due to an incorrect ISDN number may be indicated with:
*Mar 3 00:10:38.756: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0xEB *Mar 3 00:10:38.764: Cause i = 0x84D8 - Incompatible destination
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:
Aug 13 18:23:14.734: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0x86
Aug 13 18:23:14.742: Cause i = 0x829C - Invalid number format (incomplete number)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:
*Mar 13 11:29:04.758: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0x83 *Mar 13 11:29:04.769: Cause i = 0x8295 - Call rejected
- 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).
interface BRI0 isdn spid1 51255511110101 5551111 isdn spid2 51255511120101 5551112
You can use the show isdn status command to verify if the SPIDs are correct.
For more information, refer to the document Troubleshooting ISDN BRI SPIDs.
If you have the output of a show isdn status command from your Cisco device, you can Cisco CLI Analyzer use to display potential issues and fixes. To use Cisco CLI Analyzer, you must be a registered user, be logged in, and have JavaScript enabled. - If the above procedure has not resolved the problem, use the document Troubleshooting ISDN BRI Layer 3 using the debug isdn q931 Command for further troubleshooting.
Back to the troubleshooting flowchart
Troubleshooting: Does the PPP LCP Phase Succeed?
In the debug output, you should see a message line to the following:
*Mar 1 00:06:36.887: BR0:1 LCP: State is Open
If you see this line, this indicates that Link Control Protocol (LCP) was negotiated successfully. Any state other than open indicates that LCP failed.
Back to the troubleshooting flowchart
Symptom: PPP LCP Phase Does not Succeed
Possible Cause: PPP is not Configured
If you have debug output similar to the following lines, this indicates that PPP did not start.
*Mar 2 19:34:21.761: Di1 DDR: dialer protocol up. *Mar 2 19:34:23.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT). *Mar 2 19:34:25.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT). *Mar 2 19:34:27.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT) *Mar 2 19:34:27.753: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8101.
! -- Call connects but the router does not send any PPP CONFREQ packets *Mar 2 19:34:29.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT). Success rate is 0 percent (0/5)
Note from the debug output that the router does not send any PPP CONFREQ messages. This is probably because the interface has not been configured for PPP encapsulation.
In this case, verify that you have configured the encapsulation ppp command under the dialer interface and physical interface. The following are examples:
interface Dialer1 encapsulation ppp or
interface BRI 0
encapsulation ppp
Possible Cause: ISDN Speed Mismatch
Sometimes you may see only outbound LCP CONFREQ messages, but no inbound LCP messages. An example is shown below:
*Mar 14 01:49:10.160: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up ! -- Call is connected. PPP negotiation will begin
*Mar 14 01:49:10.168: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1.
*Mar 14 01:49:10.188: BR0:1 PPP: Treating connection as a callout
*Mar 14 01:49:10.188: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load] ! -- PPP negotiation begins
*Mar 14 01:49:10.196: BR0:1 LCP: O CONFREQ [Closed] id 24 len 15
*Mar 14 01:49:10.200: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:10.204: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A). ! -- Outgoing Configure-Request (CONFREQ)
*Mar 14 01:49:12.176: BR0:1 LCP: TIMEout: State REQsent ! -- Router has not received a CONFREQ from the peer, hence the timeout
*Mar 14 01:49:12.180: BR0:1 LCP: O CONFREQ [REQsent] id 25 len 15
*Mar 14 01:49:12.184: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:12.188: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A).
*Mar 14 01:49:14.160: BR0:1 LCP: TIMEout: State REQsent
*Mar 14 01:49:14.164: BR0:1 LCP: O CONFREQ [REQsent] id 26 len 15
*Mar 14 01:49:14.168: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:14.172: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A)
This problem could be caused by:
- 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 Dialer1 maui-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)#exit maui-soho-01(config)#map-class dialer 56k
! -- map-class named "56k" that was used with the dialer string
! -- in int Dialer1
maui-soho-01(config-map-clas)#dialer isdn speed 56
! -- Set the speed of the call to be 56k (default is 64k)
For Legacy DDR (dialer maps):
maui-soho-01(config)#interface bri 0 maui-soho-01(config-if)#dialer map ip 10.1.1.1 name maui-nas-08 speed 56 81560
!-- The keyword speed 56 sets the outgoing call rate at 56k
Possible Cause: The Two Routers do not Agree on an Authentication Protocol (CHAP or PAP) to Use
If you have debug output similar to the following lines, this indicates that your router and the remote side did not agree on an authentication protocol to use:
*Mar 1 00:07:24.051: BR0:1 LCP: I CONFREQ [ACKrcvd] id 136 len 14 *Mar 1 00:07:24.055: BR0:1 LCP: AuthProto PAP (0x0304C023) *Mar 1 00:07:24.059: BR0:1 LCP: MagicNumber 0x1110C3C5 (0x05061110C3C5) ! -- An incoming CONFREQ (Config-Request) indicating the peer is
! -- willing to do PAP *Mar 1 00:07:24.063: BR0:1 LCP: O CONFNAK [ACKrcvd] id 136 len 9 *Mar 1 00:07:24.063: BR0:1 LCP: AuthProto CHAP (0x0305C22305) ! -- The router send a Configure-Negative-Acknowledge (CONFNAK) rejecting PAP
! -- The router suggests CHAP instead *Mar 1 00:07:24.087: BR0:1 LCP: I CONFREQ [ACKrcvd] id 137 len 14 *Mar 1 00:07:24.091: BR0:1 LCP: AuthProto PAP (0x0304C023) *Mar 1 00:07:24.091: BR0:1 LCP: MagicNumber 0x1110C3C5 (0x05061110C3C5) ! -- The peer once again requests PAP
! -- This is probably because PAP is the only protocol configured on the peer
! -- The router will once again CONFNAK PAP and suggest CHAP *Mar 1 00:07:24.095: BR0:1 LCP: O CONFNAK [ACKrcvd] id 137 len 9 *Mar 1 00:07:24.099: BR0:1 LCP: AuthProto CHAP (0x0305C22305) ! -- The router NAKs PAP and suggests CHAP for the 2nd time *Mar 1 00:07:24.119: BR0:1 LCP: I TERMREQ [ACKrcvd] id 138 len 4 *Mar 1 00:07:24.123: BR0:1 LCP: O TERMACK [ACKrcvd] id 138 len 4 ! -- The two routers cannot agree on LCP parameters so the call is disconnected
In this case, verify that you have configured the following:
interface Dialer1 encapsulation ppp ppp authentication chap pap callin ! -- This permits both CHAP and PAP and one-way authentication
For more information on Challenge Handshake Authentication Protocol (CHAP) or Password Authentication Protocol (PAP), refer to the following documents:
- Understanding and Configuring PPP CHAP Authentication
- PPP Authentication using the ppp chap hostname and ppp authentication chap callin Commands
- Configuring and Troubleshooting PPP Password Authentication Protocol (PAP)
You can also use the Cisco Support Community for further PPP troubleshooting.
Back to the troubleshooting flowchart
Troubleshooting: Does PPP Authentication Succeed?
Check the debug output for a line similar to this:
*Mar 1 00:06:36.943: BR0:1 PPP: Phase is UP
Back to the troubleshooting flowchart
Symptom: PPP Authentication Does Not Succeed
Make sure that you have configured the following lines:
interface Dialer1 ppp chap hostname XXXXX ppp chap password YYYYY ppp pap sent-username XXXXX password YYYYY
In the example, XXXXX is your username and YYYYY is your password.
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 username username password password, 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.
*Mar 1 00:16:54.403: BR0:1 CHAP: I CHALLENGE id 94 len 24 from "ISP" ! -- Incoming CHAP challenge *Mar 1 00:16:54.407: BR0:1 CHAP: Using alternate hostname XXXXX ! -- Using alternate hostname configured with ppp chap hostname command *Mar 1 00:16:54.411: BR0:1 CHAP: Username ISP not found *Mar 1 00:16:54.415: BR0:1 CHAP: Using default password ! -- Using password configured with ppp chap password command *Mar 1 00:16:54.415: BR0:1 CHAP: O RESPONSE id 94 len 26 from "XXXXX" ! -- Sending response from "XXXXX" which is the alternate hostname for the router *Mar 1 00:16:54.439: BR0:1 CHAP: I FAILURE id 94 len 25 msg is "MD/DES compare failed" ! -- Incoming CHAP failure. The remote router failed to authenticate this router. ! -- Check the username and password configured on both routers *Mar 1 00:16:54.447: BR0:1 LCP: I TERMREQ [Open] id 165 len 4 *Mar 1 00:16:54.451: BR0:1 LCP: O TERMACK [Open] id 165 len 4
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.
For more information refer to the document PPP Authentication using the ppp chap hostname and ppp authentication chap callin Commands.
Example 2
A message like the one below could mean that the CHAP username is not valid:
*Mar 1 00:18:34.831: BR0:1 CHAP: I CHALLENGE id 97 len 24 from "ISP" ! -- Incoming CHAP challenge *Mar 1 00:18:34.835: BR0:1 CHAP: Using alternate hostname Xdwqdqw ! -- Using alternate hostname configured with ppp chap hostname command *Mar 1 00:18:34.839: BR0:1 CHAP: Username ISP not found *Mar 1 00:18:34.839: BR0:1 CHAP: Using default password ! -- Using password configured with ppp chap password command *Mar 1 00:18:34.843: BR0:1 CHAP: O RESPONSE id 97 len 28 from "Xdwqdqw" ! -- Sending response from "Xdwqdqw" which is the alternate hostname
! -- for the router *Mar 1 00:18:34.867: BR0:1 CHAP: I FAILURE id 97 len 26 msg is "Authentication failure" ! -- Incoming CHAP failure. The remote router failed to authenticate
! -- this router. Check the username and password configured on both routers *Mar 1 00:18:34.875: BR0:1 LCP: I TERMREQ [Open] id 171 len 4 *Mar 1 00:18:34.879: BR0:1 LCP: O TERMACK [Open] id 171 len 4
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.
For more information, refer to the document PPP Authentication using the ppp chap hostname and ppp authentication chap callin Commands.
Example 3
A message like below means that the PAP password is not valid:
*Mar 1 00:21:33.927: BR0:1 PAP: O AUTH-REQ id 3 len 18 from "XXXXX" ! -- Outgoing PAP Authentication Request from XXXXX
! -- XXXXX is the username configured in
! -- ppp pap sent-username XXXXX password YYYYY *Mar 1 00:21:33.947: BR0:1 PAP: I AUTH-NAK id 3 len 27 msg is "Authentication failure" ! -- An incoming PAP failure. The peer could not authenticate this router
! -- Verify that the username and password configured on both routers
! -- are identical *Mar 1 00:21:33.955: BR0:1 LCP: I TERMREQ [Open] id 182 len 4 *Mar 1 00:21:33.955: BR0:1 LCP: O TERMACK [Open] id 182 len 4 *Mar 1 00:21:33.959: BR0:1 PPP: Phase is TERMINATING
For more information refer to the document Configuring and Troubleshooting PPP Password Authentication Protocol (PAP).
Example 4
A message like below means that the PAP username is not valid:
*Mar 1 00:20:41.023: BR0:1 PPP: Phase is AUTHENTICATING, by the peer *Mar 1 00:20:41.031: BR0:1 PAP: O AUTH-REQ id 1 len 17 from "ewddew" ! -- Outgoing PAP Authentication Request from ewddew
! -- ewddew is the username configured in
! -- ppp pap sent-username ewddew password YYYYY *Mar 1 00:20:41.047: BR0:1 PAP: I AUTH-NAK id 1 len 27 msg is "Authentication failure" ! -- An incoming PAP failure. The remote router could not authenticate
! -- this router. Check the username and password configured on both routers
! -- Note the PAP authentication failure in example 3 and 4 are identical.
! -- Hence the only way to determine if the username, password or both are
! -- wrong is to run debug ppp negotiation on the authenticating router *Mar 1 00:20:41.055: BR0:1 LCP: I TERMREQ [Open] id 178 len 4 *Mar 1 00:20:41.059: BR0:1 LCP: O TERMACK [Open] id 178 len 4 *Mar 1 00:20:41.063: BR0:1 PPP: Phase is TERMINATING
For more information refer to the document Configuring and Troubleshooting PPP Password Authentication Protocol (PAP).
You can also use the Cisco Support Community for further PPP Troubleshooting.
Back to the troubleshooting flowchart
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:
*Mar 1 00:06:36.967: BR0:1 IPCP: O CONFACK [REQsent] id 26 len 10 *Mar 1 00:06:36.971: BR0:1 IPCP: Address 194.183.201.1(0x0306C2B7C901)
and
*Mar 1 00:06:37.011: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10 *Mar 1 00:06:37.015: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902)
and
*Mar 1 00:06:37.015: BR0:1 IPCP: State is Open
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.
Back to the troubleshooting flowchart
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
For more information refer to the document Dialup Technology: Troubleshooting Techniques.
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;
*Mar 15 03:19:13.050: BR0:1 CHAP: O CHALLENGE id 32 len 33 from "maui-soho-03"
*Mar 15 03:19:13.094: BR0:1 CHAP: I CHALLENGE id 32 len 33 from "maui-soho-01"
*Mar 15 03:19:13.094: BR0:1 CHAP: O RESPONSE id 32 len 33 from "maui-soho-03"
*Mar 15 03:19:13.134: BR0:1 CHAP: I SUCCESS id 32 len 4 ! -- CHAP authentication is successful
*Mar 15 03:19:13.222: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0xA0
*Mar 15 03:19:13.226: Cause i = 0x8090 - Normal call clearing ! -- We have received (RX) a DISCONNECT from the peer
! -- We have to move troubleshooting to the called router
*Mar 15 03:19:13.238: ISDN BR0: TX -> RELEASE pd = 8 callref = 0x20
*Mar 15 03:19:13.242: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 15 03:19:13.250: BR0 DDR: has total 2 call(s), dial_out 0, dial_in 0
*Mar 15 03:19:13.254: BR0:1 PPP: Phase is TERMINATING
*Mar 15 03:19:13.254: BR0:1 LCP: State is Closed
*Mar 15 03:19:13.254: BR0:1 PPP: Phase is DOWN
*Mar 15 03:19:13.254: BRI0:1 DDR: disconnecting call
Note: The debugs from the called side do not help in troubleshooting this problem except to indicate that the peer disconnected the call. Move troubleshooting to the called router.
On the Called Router:
The following debug shows a call failing due to dialer profile binding issues:
*Mar 15 03:54:09.804: BR0:1 CHAP: O SUCCESS id 33 len 4
*Mar 15 03:54:09.808: BR0:1 CHAP: Processing saved Challenge, id 33
*Mar 15 03:54:09.812: BR0:1 DDR: Authenticated host maui-soho-03 with no matching dialer profile ! -- a binding failure because the dialer remote-name
! -- does not match the authenticated username
*Mar 15 03:54:09.816: BR0:1 DDR: disconnecting call
*Mar 15 03:54:10.086: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 15 03:54:10.093: BR0:1 PPP: Phase is TERMINATING [0 sess, 0 load]
Solution:
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.
For more further troubleshooting information on binding issues refer to the document Configuring and Troubleshooting Dialer Profiles.
You can also use the Cisco Support Community for further PPP troubleshooting.
Back to the troubleshooting flowchart
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:
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, 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:
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 ! -- this interesting traffic is applied to the dialer
! -- interface using dialer-group 1For more information refer to the document Dialup Technology: Overviews and Explanations.
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.
Tip: Unless specifically needed, designate all routing protocols configured on the router as uninteresting.
The following example shows periodic OSPF hellos being marked as interesting:
*Mar 15 00:25:58.865: Di1 DDR: ip (s=172.22.25.1, d=224.0.0.5), 64 bytes, outgoing interesting (ip PERMIT)
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:
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 ! -- this interesting traffic is applied to the dialer interface
! -- using dialer-group 1
For more information refer to the document Dialup Technology: Overviews and Explanations.
Note: OSPF has a feature called demand-circuit that can also be used here. Refer to the document Why OSPF Demand Circuit Keeps Bringing Up the Link for more information
Symptom: Second B-channel does not Connect
In many instances, the router may only connect on one B-channel, while the other B-channel stays idle. For more information on troubleshooting this issue refer to the document Troubleshooting Second B-channel Call Failures on ISDN BRI Links.
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.
If you are using the ISDN link as a backup to a WAN connection, then refer to the document Configuring and Troubleshooting DDR Backup.
Related Information
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)