ISDN Troubleshooting

Troubleshooting an ISDN connection mostly involves OSI Layers 1 and 2 but occasionally Layer 3 if there's a problem with routing. This section focuses on the bottom two layers with regard to BRI connections.

Layer 1 is pretty easy stuff. As long as you configure what the service provider tells you to, it almost always works, and when it doesn't, the problem is usually either a physical wire problem or an issue on its end. Most of the problems occur at Layer 2 between the end devices.

Probably the most misdiagnosed issue deals with authentication. People tend to forget that PPP authentication, as well as MLP and callback settings, occurs during the circuit setup phase. If you have the wrong password or even a wrong case in the dialer map statement, authentication fails, leaving many people wondering what is wrong with the ISDN connection. The answer, of course, is nothing. The ISDN connection works fine. But something linked to it, PPP, didn't work and was told to kill the call if it failed.

Troubleshooting PPP authentication, callback, and MLP was covered in Chapter 4. Here, we cover troubleshooting ISDN issues and how to tell when the ISDN part is working fine.

Q.921

Q.921, also known as Link Access Protocol, D Channel (LAPD), is responsible for the management of traffic that occurs between the local ISDN device and the ISDN switch. Essentially, it's responsible for the Layer 2 ISDN signaling.

Q.921 handles aspects such as the Terminal Endpoint Identifier (TEI), which identifies different devices on the ISDN bus. TEI 127 is used for broadcasting; others can be dynamically assigned from the range of 64 to 126 as required. Q.921 also uses Service Access Point Identifiers (SAPIs), which play the same role that a port or protocol number does in TCP/IP. A SAPI identifies what type of message Q.921 is encapsulating. A 0 indicates a Q.931 message, 16 is used for X.25, and 63 is used for the TEI assignment.

Q.931

Q.931 is responsible for addressing functions as well as call setup and teardown, commonly referred to as ISDN Layer 3 traffic. This chapter showed detailed steps of what goes on during call setup and teardown, but you can also troubleshoot the process.

ISDN show Commands

The show commands give the current status, a snapshot of the system setup, or results of what has happened. Because you don't monitor ISDN configurations too heavily, and when you do, it's because of a problem, there aren't many show commands.

You can check the status of D and B channels from the point of view of the interface. Remember that one B channel can be up while the other is down and that the D channel should always be up. Use the following command to check the status of the D channel for a BRI:

 show interface bri #/# to 

The following is partial output from that command:

 Router# show interface bri 0/0 BRI0/0 is up, line protocol is up (spoofing)   Hardware is BRI   Internet address is 10.1.0.1/24   MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255,     load 1/255   Encapsulation PPP, loopback not set 

Something that is confusing at first glance is where the status says (spoofing). It indicates that the interface is ready for traffic but that a connection doesn't really exist. Don't forget that this is output for the D channel, which is always up, and it's the B channels, which are down when not being used, that carry most of the data.

To see the status of the B channels, the command is slightly different. You can view the status of a single B channel or both together. Use the following command to see the first B channel, the second B channel, or both together:

 show interface bri #/# [1 | 2 | 1 2] 

The following command pulls up information on the first B channel:

 Router#show interface bri0/0 1 BRI0:1 is down, line protocol is down   Hardware is BRI   MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255,     load 1/255   Encapsulation PPP, loopback not set, keepalive set (10 sec)   LCP Closed   Closed: IPCP, CDP   Last input never, output never, output hang never   Last clearing of "show interface" counters never   Input queue: 0/75/0 (size/max/drops); Total output drops: 0   Queueing strategy: weighted fair   Output queue: 0/64/0 (size/threshold/drops)      Conversations  0/0 (active/max active)      Reserved Conversations 0/0 (allocated/max allocated)   5 minute input rate 0 bits/sec, 0 packets/sec   5 minute output rate 0 bits/sec, 0 packets/sec      0 packets input, 0 bytes, 0 no buffer      Received 0 broadcasts, 0 runts, 0 giants      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort      0 packets output, 0 bytes, 0 underruns      0 output errors, 0 collisions, 5 interface resets      0 output buffer failures, 0 output buffers swapped out      0 carrier transitions 

All the other ISDN show commands come off the show isdn line. One of the useful ones is show isdn active. This command shows the current calls, where from and where to, and how long the connection has been active. The information for this command is kept only for a short amount of time. At 15 minutes after a call is terminated, the information is wiped from the database. In addition, it only keeps data for 100 calls.

If you're interested in what's going on behind the scenes, then give show isdn status a shot. This command shows the status of an interface and the details behind what makes that call work. The following is output from an interface with one call active:

 The current ISDN Switchtype = 5ess ISDN BRI0 interface Layer 1 Status: ACTIVE Layer 2 Status: TEI = 64, State = MULTIPLE_FRAME_ESTABLISHED Layer 3 Status: 1 Active Layer 3 Call(s) Activated dsl 0 CCBs = 1 CCB:callid=8002, callref=0, sapi=0, ces=1, B-chan=1 Number of active calls = 1 Number of available B-channels = 1 Total Allocated ISDN CCBs = 1 

Even if no data is flowing across the ISDN connection, it's easy to tell where you should be pointing your troubleshooting energies. If you want to delve more into how ISDN sets up on a real-time basis, then the debug commands are what you're interested in.

Debugging ISDN

Debugging ISDN results in a message coming across the router every time there's a piece of ISDN management information that enters or leaves the router. It's terrific for troubleshooting in real time, but it's not something you'll want to leave enabled once you're through examining the output.

There are two major types of logs that you can examine: traffic between the switch and the router, and traffic between the two endpoints.

To debug Q.921 management traffic, use the following command:

 Router# debug isdn q921 

Using this command even before you've tried to dial is something to consider because it monitors the signaling between the router and the telco switch. If there is no debug display, then the ISDN connection will not display relevant output.

The output from this command is short but a bit convoluted. Following is a single-line output example:

 Jun 7 10:27:16.303: ISDN BR0: RX <- RRr sapi = 0 tei = 64 nr = 6 

The output shows that a frame was received from the ISDN switch, with a SAPI of 0 indicating that there is Layer 3 information enclosed and that the TEI designated by 64 is the one the frame is for. That would be this device. The nr value is the expected sequence number of the next frame to be received. It allows for retransmission if necessary.

Typically, if you enable debugging for Q.921 and get output, you're fine.

The following two commands give Layer 3 output:

 Router# debug isdn event Router# debug isdn q931 

Showing the same types of information, the resulting output changes are primarily one of formatting. The following is output from the debug isdn event command:

 ISDN Event: Call to 4085551212 received HOST_PROCEEDING Channel ID i = 0x0101                  - Channel ID i = 0x89 received HOST_CONNECT Channel ID i = 0x0101 ISDN Event: Connected to 4085551212 on B1 at 64 Kb/s 

This output is from the debug isdn q931 command:

 TX -> SETUP pd = 8 callref = 0x04 Bearer Capability i = 0x8890 Channel ID i = 0x83 Called Party Number i = 0x80, '4085551212' RX <- CALL_PROC pd = 8 callref = 0x84 Channel ID i = 0x89 RX <- CONNECT pd = 8 callref = 0x84 TX -> CONNECT_ACK pd = 8 callref = 0x04.... 

As you can see, the output is pretty similar. When troubleshooting a link, one best practice is to begin by examining the Q.921 output, and if there is output, turn it off and move on to Q.931. Examine the output and note whether you see debug ISDN event output like the following:

 Jun 7 10:37:03.152: Cause i = 0x8095 - Call rejected 

There's a good chance that there's an authentication or other non-ISDN issue. It could also be something related to ISDN caller ID. The next step is to look at the other side or to run PPP debugging on the local router for more information. Suppose you saw a message such as the following instead:

 BRI0:Caller id 4085551212 callback - no matching map 

There's a really good indication that the connection was made to the remote device, but because callback is being used, the remote router needs to call you and it doesn't know how to. You wouldn't see this message from the router originally making the call, but you would if you were logging errors on the device being called.