Troubleshooting ISDN
 Connecting A ConsoleFaxback Document #console |
Troubleshooting requires a router console connection. With a console, status messages from the router may be read and commands into the router may be entered. |
Once an ISDN line has been properly installed and provisioned by the telco, installation of an ISDN network using Cisco IOS routers is usually a simple, trouble-free task, requiring minimal configuration and maintenance. However, when the ISDN line does not operate as expected, proven problem-isolation techniques can be applied to recognize and solve common ISDN problems.
When problems do occur, most WAN problems can be diagnosed by using the following router commands:
In North America, all ISDN lines are connected to the ISDN switch at the local Central Office (CO) via a U interface. This U interface will require network termination to convert it into an S/T interface that actually connects to your end equipment. A Network Termination Type 1, or NT-1, is a separate unit that serves this function, as well as providing power to your ISDN line. In Europe, the NT-1 is included in telco-provisioned ISDN lines so all you will need is the S/T interface.
When working with Cisco routers, it is important to determine whether the unit has an S/T interface, which will require an external NT-1, or a U interface with a built-in NT-1. Please check your hardware manual to determine whether you have the proper equipment.
Cisco routers employ dial-on-demand routing (DDR) for ISDN networks. With DDR, the router opens the ISDN connection only when there is traffic that needs to be transmitted. The context for using DDR involves infrequent or intermittent traffic to and from remote sites, or when ISDN line usage is tariffed, usually per B-channel.
Configuration of DDR on Cisco routers involves four steps:
| Step 1 | To identify the traffic that should be transmitted,
you specify the packets that the DDR processes on the
router will interpret as ‘interesting' traffic.
DDR uses two ways to specify interesting packets that
trigger the dialer to make a call.
|
| Step 2 | The dialer-list will have to be applied to a BRI
interface. This is done with the dialer-group
interface configuration command, the syntax of which is:
For example, the commands: interface BRI0 dialer-group 1 applies the dialer-list 1 to the BRI0 interface. |
| Step 3 | A dialer-map must be entered on the interface
to instruct it how to reach a DDR destination. The syntax
for this interface configuration command is:
For example, the command: dialer map ip 10.1.1.1 name cisco speed 56 broadcast 4155551212 would instruct the router that upon experiencing interesting traffic, it will dial 4155551212 and connect at 56k to a router named cisco with the next hop ip address of 10.1.1.1. It will allow broadcast traffic while the line is up, but will not necessarily be the cause of the ISDN call (see example dialer-list). |
| Step 4 | A static route(s) must be set to provide the
routing path to the next hop router. The syntax for this
global configuration command is:
For example, the commands: ip route 0.0.0.0 0.0.0.0 10.1.1.1 ip route 10.1.1.1 255.255.255.255 BRI0 would inform the router that in order to reach any ip network not defined in its routing table (all zeros network), it will go to the ip address 10.1.1.1, and in order to get to the host ip number 10.1.1.1, it will go through interface BRI0. |
Using Show Commands To Troubleshoot ISDN Networks
The show commands in the Cisco IOS that are most helpful in solving ISDN problems tell you whether you are connected to the local ISDN switch - show isdn status, or whether you have successfully made a call - show dialer.
Upon getting the ISDN line provisioned by telco, the only parameters that are required for the router to synchronize with the switch are the switch type and the spid(s). Sample configuration would be:
isdn switch-type basic-ni1 ! interface BRI0 isdn spid1 41555512120101 5551212 isdn spid2 41555512130101 5551213
After proper configuration, output from the show isdn status EXEC command would yield:
The current ISDN Switchtype = basic-ni1
ISDN BRI0 interface
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 112, State = MULTIPLE_FRAME_ESTABLISHED
TEI = 113, State = MULTIPLE_FRAME_ESTABLISHED
Layer 3 Status:
No Active Layer 3 Call(s)
Activated dsl 0 CCBs = 0
Total Allocated ISDN CCBs = 0
Failure of the Cisco router to synchronize properly with the ISDN switch would yield:
The current ISDN Switchtype = basic-ni1
ISDN BRI0 interface
Layer 1 Status:
DEACTIVATED
Layer 2 Status:
Layer 2 NOT Activated
Layer 3 Status:
No Active Layer 3 Call(s)
Activated dsl 0 CCBs = 0
Total Allocated ISDN CCBs = 0
If you receive this output, the possible causes are:
| Problem | Suggested Action |
| Faulty Cable | Replace the cable from router to ISDN jack, making sure the cable contains the middle two pins (pins 4 & 5 in an RJ-45 cable). |
| Wrong Switch Type or Spid(s) | Contact telco and confirm switch type and spid(s). Re-enter them into router and issue the clear interface bri number EXEC command. |
| Faulty ISDN line | Get an analog phone and plug into ISDN jack. You should get either 1) a clicking noise, or 2) white noise/light static. If you do not get either of those, it is not an active ISDN line. Contact telco and open trouble ticket. |
After getting successful connection with the local ISDN switch and after having entered the basic Dial-On-Demand Routing configuration into the router, you should be able to initiate a test call by issuing interesting traffic to the next hop address. Even if full PPP connectivity has not been established, you can determine whether a physical call was made by issuing the show dialer EXEC command.
Output from the Show Dialer Command
Dial String Successes Failures Last called Last status 4155551212 1 0 00:00:00 successful 4155551213 1 0 00:00:00 successful 0 incoming call(s) have been screened. BRI0: B-Channel 1 Idle timer (300 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs) BRI0: B-Channel 2 Idle timer (300 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs)
If you receive any failure on the attempted call, the possible causes are:
| Problem | Suggested Action |
| Error in Configuration | Check over the router configuration, making sure there is a dialer-list, dialer-group, and dialer map/dialer string. Also confirm validity of the dial string of destination ISDN connection. |
| Remote Failure | Make sure the remote router is properly configured. |
Using Debug Commands To Troubleshoot ISDN Networks
Click here
for more information on debug commands.
When the show commands are inadequate in providing details regarding the ISDN failure, debug commands are extremely helpful in determining exactly what the router is experiencing within the debug topic. The following debug commands are applicable to ISDN troubleshooting:
The following are sample outputs from various combinations of debug commands, followed by the identication of the ISDN problem they represent as well as suggested actions.
BRI0: ISDN Event: incoming ces value = 1 BRI0: received HOST_TERM_REGISTER_NACK - invalid EID/SPID or TEI not assigned Cause i = 0x8082 - No route to specified network
| Problem | Suggested Action |
| Usually SPID problem. To verify that TEI is assigned, try show ISDN status. Layer 2 information will tell if TEI is assigned. | 1. Check configuration if SPIDs are configured
correctly. 2. Have service provider verify SPIDs, if necessary have them track the SPIDs. |
BRI0: Dialing cause: BRI0: ip PERMIT BRI0: Attempting to dial 6968900 TX -> SETUP dsl = 0 pd = 8 callref = 0x01 Bearer Capability i = 0x8890218F Channel ID i = 0x83 Called Party Number i = 0x80, '6968900' RX RELEASE dsl = 0 pd = 8 callref = 0x01 RX
| Problem | Suggested Action |
| Remote router does not answer call. | Verify telephone number and SPIDs. |
BRI0: Dialing cause: BRI0: ip PERMIT BRI0: No dialer string defined. Dialing cannot occur.. BRI0: Dialing cause: BRI0: ip PERMIT BRI0: No dialer string defined. Dialing cannot occur.. BRI0: Dialing cause: BRI0: ip PERMIT BRI0: No dialer string defined. Dialing cannot occur.. BRI0: Dialing cause: BRI0: ip PERMIT BRI0: No dialer string defined. Dialing cannot occur.. BRI0: Dialing cause: BRI0: ip PERMIT BRI0: No dialer string defined. Dialing cannot occur..
| Problem | Suggested Action |
| Dialing cannot occur. | Check configuration (dialer-list, dialer-group, dialer map, dialer string, etc). |
DEBUG PPP NEGOTIATION, DEBUG PPP AUTHENTICATION
pico#ping 192.9.198.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.9.198.1, timeout is 2 seconds: %LINK-3-UPDOWN: Interface BRI0: B-Channel 1, changed state to up %LINK-5-CHANGED: Interface BRI0: B-Channel 1, changed state to up ppp: sending CONFREQ, type = 3 (CI_AUTHTYPE), value = C223/5 ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 28CEEF99 ppp: received config for type = 3 (AUTHTYPE) value = C223 value = 5 acked ppp: received config for type = 5 (MAGICNUMBER) value = 1E23F5C acked PPP BRI0: B-Channel 1: state = ACKSENT fsm_rconfack(C021): rcvd id E4 ppp: config ACK received, type. = 3 (CI_AUTHTYPE), value = C223 ppp: config ACK received, type = 5 (CI_MAGICNUMBER), value = 28CEEF99 BRI0: B-Channel 1: PPP AUTH CHAP input code = 1 id = 82 len = 16 BRI0: B-Channel 1: PPP AUTH CHAP input code = 2 id = 95 len = 28 BRI0: B-Channel 1: PPP AUTH CHAP input code = 4 id = 82 len = 21 BRI0: B-Channel 1: Failed CHAP authentication with remote. Remote message is: MD compare failed ppp: sending CONFREQ, type = 3 (CI_AUTHTYPE), value = C223/5 ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 28CEEFDB %LINK-3-UPDOWN: Interface BRI0: B-Channel 1, changed state to down %LINK-5-CHANGED: Interface BRI0: B-Channel 1, changed state to down %LINK-3-UPDOWN: Interface BRI0: B-Channel 1, changed state to up %LINK-5-CHANGED: Interface BRI0: B-Channel 1, changed state to up ppp: sending CONFREQ, type = 3 (CI_AUTHTYPE), value = C223/5 ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 28CEF76C ppp: received config for type = 3 (AUTHTYPE) value = C223 value = 5 acked ppp: received conf.ig for type = 5 (MAGICNUMBER) value = 1E24718 acked PPP BRI0: B-Channel 1: state = ACKSENT fsm_rconfack(C021): rcvd id E6 ppp: config ACK received, type = 3 (CI_AUTHTYPE), value = C223 ppp: config ACK received, type = 5 (CI_MAGICNUMBER), value = 28CEF76C BRI0: B-Channel 1: PPP AUTH CHAP input code = 1 id = 83 len = 16 BRI0: B-Channel 1: PPP AUTH CHAP input code = 2 id = 96 len = 28 BRI0: B-Channel 1: PPP AUTH CHAP input code = 4 id = 83 len = 21 BRI0: B-Channel 1: Failed CHAP authentication with remote. Remote message is: MD compare failed
| Problem | Suggested Action |
| CHAP authentication failed. | Check username and passwords for correct spelling, use of lower and upper case letters. Check dialer map command for name keyword and correct hostname. |
DEBUG ISDN EVENT, DEBUG ISDN Q931
TX -> RRp dsl = 1 sapi = 0 tei = 96 nr = 98 RX on B1 at 64 Kb/s
ISDN Event: Accepting the call
%LINK-3-UPDOWN: Interface BRI1: B-Channel 1, changed state to up
TX -> INFOc dsl = 1 sapi = 0 tei = 96 ns = 108 nr = 98 i = 0x0801D807180189
CONNECT dsl = 1 pd = 8 callref = 0xD8
Channel ID i = 0x89
RX RRr dsl = 1 sapi = 0 tei = 96 nr = 99
ISDN Event: incoming ces value = 1
received HOST_CONNECT
Channel ID i = 0x0101
-------------------
Channel ID i = 0x89
Signal i = 0x4F
ISDN Event: Connected to on B1 at 64 Kb/s
%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI1: B-Channel 1,
changed
state to up
TX -> RRp dsl = 1 sapi = 0 tei = 105 nr = 17
RX RRp dsl = 1 sapi = 0 tei = 96 nr = 99
RX INFOc dsl = 1 sapi = 0 tei = 96 ns = 109 nr = 99 i =
0x0801D84508028090
DISCONNECT dsl = 1 pd = 8 callref = 0xD8
Cause i = 0x8090 - Normal call clearing
RX RRr dsl = 1 sapi = 0 tei = 96 nr = 100
ISDN Event: incoming ces value = 1
received HOST_DISCONNECT_ACK
%LINK-3-UPDOWN: Interface BRI1: B-Channel 1, changed state to down
TX -> INFOc dsl = 1 sapi = 0 tei = 96 ns = 110 nr = 100 i =
0x0801D85A
RELEASE_COMP dsl = 1 pd = 8 callref = 0xD8
ISDN Event: Hangup call to call id 0x3C on dsl 1, ces = 1
CCBRI Mail NULL InPkt public is 0 ccb is 3C53E0
ISDN Event: incoming ces value = 1
received HOST_QUERY_RESPONSE
Call State i = 0x00
-------------------
RX RRp dsl = 1 sapi = 0 tei = 105 nr = 17
| Problem | Suggested Action |
| Call connected, but got disconnected. | Turn on debug ppp negotiation and debug ppp chap and see if ppp negotiation and ppp authentication is good. |
19:27:31: TX -> IDREQ ri = 19354 ai = 127 dsl = 0 19:27:33: TX -> IDREQ ri = 1339 ai = 127 dsl = 0 19:27:35: TX -> IDREQ ri = 22764 ai = 127 dsl = 0 19:27:37: TX -> IDREQ ri = 59309 ai = 127 dsl = 0 19:27:39: TX -> IDREQ ri = 25214 ai = 127 dsl = 0 19:27:41: TX -> IDREQ ri = 35423 ai = 127 dsl = 0 19:27:43: TX -> IDREQ ri = 12368 ai = 127 dsl = 0 19:27:45: TX -> IDREQ ri = 13649 ai = 127 dsl = 0 19:27:47: TX -> IDREQ ri = 35426 ai = 127 dsl = 0 19:27:49: TX -> IDREQ ri = 12419 ai = 127 dsl = 0 19:27:51: TX -> IDREQ ri = 14516 ai = 127 dsl = 0 19:28:04: TX -> IDREQ ri = 50165 ai = 127 dsl = 0 19:28:06: TX -> IDREQ ri = 838 ai = 127 dsl = 0 19:28:08: TX -> IDREQ ri = 14247 ai = 127 dsl = 0 19:28:34: TX -> IDREQ ri = 45592 ai = 127 dsl = 0 19:28:36: TX -> IDREQ ri = 54169 ai = 127 dsl = 0 19:28:38: TX -> IDREQ ri = 3370 ai = 127 dsl = 0 19:29:09: TX -> IDREQ ri = 57291 ai = 127 dsl = 0 19:29:11: TX -> IDREQ ri = 56444 ai = 127 dsl = 0 19:29:13: TX -> IDREQ ri = 42045 ai = 127 dsl = 0 19:29:44: TX -> IDREQ ri = 59406 ai = 127 dsl = 0 19:29:46: TX -> IDREQ ri = 26863 ai = 127 dsl = 0 19:29:48: TX -> IDREQ ri = 63456 ai = 127 dsl = 0 19:30:19: TX -> IDREQ ri = 30177 ai = 127 dsl = 0 19:30:21: TX -> IDREQ ri = 54258 ai = 127 dsl = 0 19:30:23: TX -> IDREQ ri = 4883 ai = 127 dsl = 0 19:30:54: TX -> IDREQ ri = 17476 ai = 127 dsl = 0 19:30:56: TX -> IDREQ ri = 34949 ai = 127 dsl = 0 19:30:58: TX -> IDREQ ri = 4310 ai = 127 dsl = 0 19:31:24: TX -> IDREQ ri = 7735 ai = 127 dsl = 0 19:31:26: TX -> IDREQ ri = 424 ai = 127 dsl = 0
| Problem | Suggested Action |
| The router is sending Identification Requests (IDREQ) to the ISDN switch, but does not get a response from the switch. | Check: - correct configuration of SPIDs, - verify SPIDs with telco, - if neccessary, have telco track the SPIDs. |
DEBUG ISDN EVENT, DEBUG ISDN Q931
0:05:44: BRI0: ISDN Event: incoming ces value = 1 0:05:44: BRI0: received HOST_PROCEEDING Channel ID i = 0x0101 0:05:44: ------------------- Channel ID i = 0x89 0:05:44: Locking Shift to Codeset 5 0:05:44: Codeset 5 IE 0x2A i = 0x80880B,'12149398003', 0x8001098001148 00114800114 0:05:44: BRI0: RX RELEASE pd = 8 callref = 0x09 0:05:44: BRI0: RX SETUP pd = 8 callref = 0x0A 0:05:46: Bearer Capability i = 0x8890218F 0:05:46: Channel ID i = 0x83 0:05:46: Called Party Number i = 0x80, '12149398003' 0:05:46: BRI0: RX RELEASE pd = 8 callref = 0x0A 0:05:46: BRI0: RX
| Problem | Suggested Action |
| Switch type or switch type configuration. | Verify switch type with telco Verify switch type in configuration. |
Debug: DEBUG PPP NEGOTIATION, DEBUG PPP AUTHENTICATION
3:22:53: ppp: sending CONFREQ, type = 3 (CI_AUTHTYPE), value = C223/5 3:22:53: ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = C6091F. 3:22:55: ppp: sending CONFREQ, type = 3 (CI_AUTHTYPE), value = C223/5 3:22:55: ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = C6091F 3:22:55: PPP BRI0: B-Channel 1: received config for type = 0x0 (??) 3:22:55: PPP BRI0: B-Channel 1: rcvd unknown option 0x0 rejected 3:22:55: PPP BRI0: B-Channel 1: received config for type = 0x1 (MRU) value = 0x5F4 rejected 3:22:55: PPP BRI0: B-Channel 1: received config for type = 0x3 (AUTHTYPE) value = 0xC223 value = 0x5 acked 3:22:55: PPP BRI0: B-Channel 1: received config for type = 0x11 (MULTILINK_MRRU) rejected 3:22:55: PPP BRI0: B-Channel 1: received config for type = 0x13 (UNKNOWN) 3:22:55: PPP BRI0: B-Channel 1: rcvd unknown option 0x13 rejected 3:22:55: ppp: config REJ received, type = 3 (CI_AUTHTYPE), value = C223/5 3:22:55: ppp: sending CONFREQ, type = 3 (CI_AUTHTYPE), value = C223/5 3:22:55: ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = C6091F 3:22:55: PPP BRI0: B-Channel 1: received config for type = 0x3 (AUTHTYPE) value = 0xC2. Success rate is 0 percent (0/5) moog#23 value = 0x5 acked 3:22:55: ppp: config REJ received, type = 3 (CI_AUTHTYPE), value = C223/5 3:22:55: ppp: BRI0: B-Channel 1 closing connection because remote won't authenticate. 3:22:55: ppp: sending CONFREQ, type = 3 (CI_AUTHTYPE), value = C223/5 3:22:55: ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = C6091F 3:22:55: %ISDN-6-DISCONNECT: Interface BRI0: B-Channel 1 disconnected from 01235820040 , call lasted 2 seconds 3:22:56: %LINK-3-UPDOWN: Interface BRI0: B-Channel 1, changed state to down
| Problem | Suggested Action |
| The remote device does not authenticate itself. This can be seen usually with non-Cisco devices, e.g. Ascend, Livingston. | Use IOS 10.3(9), 11.0(5) or 11.(1) or higher, which
have the option for:ppp authentication chap callin, or ppp authentication pap callin |
Caution The output from debug
privileged EXEC commands provides diagnostic information
concerning a variety of internetworking events relating to
protocol status and network activity in general. Use these
commands with great care. In general, it is recommended that
these commands only be used under the direction of your router
technical support representative when troubleshooting specific
problems. Enabling debugging can disrupt operation of the router
when internetworks are experiencing high load conditions. When
you finish using a debug command, remember to disable it
with its specific no debug command or with the no debug
all command (the undebug command is also accepted).
To minimize the impact of using debug commands, follow this procedure:
| Step 1 | Issue the no logging console global configuration command on your router. This command disables all logging to the console terminal (to re-enable logging to the console, issue the logging console enable global configuration command). |
| Step 2 | Telnet to a router port and enter the enable EXEC command. |
| Step 3 | Issue the terminal monitor command and issue the necessary debug commands (to disable logging on the virtual terminal, issue the terminal no monitor command). |
Following this procedure minimizes the load created by using debug commands because the console port no longer has to generate character-by-character processor interrupts.
All contents copyright © Cisco Systems, Inc. Important notices.