Configuring RFC 2684
| < Free Open Study > |
The "Big show" and "Big D" for Troubleshooting ISDNWe will now cover some of the ISDN troubleshooting techniques that will aid in discovering and isolating common ISDN issues, as well as some tips to help you properly configure ISDN. The "Big show" for ISDNThe following list includes some of the most useful commands when trying to isolate ISDN- related problems, and this should be among the first things done to verify whether the ISDN link is working properly. show isdn status CommandThis command tells you whether your router is properly talking to the carrier's ISDN switch. It tells you the ISDN switch type that has been configured for each interface, as well as information about the SPID status and active layer calls. Example 7-48 shows an example where the router's BRI interface is properly configured and connected to the ISDN switch. Example 7-47 show isdn status Command OutputCheech# show isdn status The current ISDN Switchtype = basic-dms100 ISDN BRI0 interface Layer 1 Status: Depending on the router model and IOS version, it might be necessary to reset the BRI interface for the router's interface to properly connect to the ISDN switch. To illustrate this, watch what happens when we entered the bswitch type and SPID information into a Cisco 2503 running IOS version 11.2(20) in Example 7-49. Example 7-48 Verifying ISDN Layer 2 Status ISDN_Router# show isdn status The current ISDN Switchtype = basic-dms100 ISDN BRI0 interface Layer 1 Status: ACTIVE Layer 2 Status: TEI = 88, State = MULTIPLE_FRAME_ESTABLISHED Spid Status: TEI 88, ces = 1, state = 5(init) spid1 configured, no LDN, spid1 sent, spid1 valid Endpoint ID Info: epsf = 0, usid = 0, tid = B TEI Not Assigned, ces = 2, state = 1(terminal down) spid2 configured, no LDN, spid2 NOT sent, spid2 NOT valid Layer 3 Status: 0 Active Layer 3 Call(s) Activated dsl 0 CCBs = 0 Total Allocated ISDN CCBs = 0 Here, you can see that SPID 1 was accepted, but SPID 2 was not. After verifying that the SPID information is indeed correct, we reset the BRI interface by issuing the shutdown / no shutdown commands. Example 7-50 shows the results. Example 7-49 Resetting the BRI InterfaceISDN_Router(config)# int bri0 ISDN_Router(config-if)# shut ISDN_Router(config-if)# no shut ISDN_Router(config-if)# %LINK-5-CHANGED: Interface BRI0, changed state to administratively down %LINK-3-UPDOWN: Interface BRI0:1, changed state to down %LINK-3-UPDOWN: Interface BRI0:2, changed state to down %LINK-3-UPDOWN: Interface BRI0, changed state to up ISDN Router(config-if)# end %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 88 changed to up %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 97 changed to up %SYS-5-CONFIG_I: Configured from console by console Blue-R8# show isdn status The current ISDN Switchtype = basic-dms100 ISDN BRI0 interface Layer 1 Status: ACTIVE Layer 2 Status: TEI = 88, State = MULTIPLE_FRAME_ESTABLISHED TEI = 97, State = MULTIPLE_FRAME_ESTABLISHED Spid Status: TEI 88, ces = 1, state = 5(init) spid1 configured, no LDN, spid1 sent, spid1 valid Endpoint ID Info: epsf = 0, usid = 0, tid = B TEI 97, ces = 2, state = 5(init) spid2 configured, no LDN, spid2 sent, spid2 valid Endpoint ID Info: epsf = 0, usid = 1, tid = B Layer 3 Status: 0 Active Layer 3 Call(s) Activated dsl 0 CCBs = 1 CCB: callid=0x0, sapi=0, ces=1, B-chan=0 Total Allocated ISDN CCBs = 1 After the interface was reset, both SPIDS were properly talking to the ISDN switch and were shown as valid. One of the first things that should be done to verify connectivity to the ISDN provider's switch is to issue the show isdn status command. If the SPIDs will not come active following an interface reset, power-reset the router. This has proven to get the correct signaling from the switch when all else fails. show interface bri 0 CommandThis command is useful in showing the general status of the ISDN interface. In general, after the ISDN circuit is connected to the interface and it is administratively enabled, it will be spoofing. Spoofing is the state in which the IOS makes the interface pretend to be up so that the routing table can point to this interface to pass traffic. Example 7-51 demonstrates the output from this command. Example 7-50 Checking the Status of the ISDN Interface Cheech# show int bri0 BRI0 is up, line protocol is up (spoofing) Hardware is BRI Internet address is 175.10.23.1/30 MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation PPP, loopback not set Last input 00:00:01, output 00:00:01, output hang never Last clearing of "show interface" counters 00:00:02 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 1 packets input, 4 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 1 packets output, 4 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions If you want to see the status of each individual B channel, you can issue the show interface bri0 1 2 command, as demonstrated in Example 7-52. Example 7-51 Checking the Status of the Individual B Channels on the ISDN Interface Cheech# show interface bri0 1 2 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, multilink Closed Closed: IPCP, CDPCP Last input 00:00:07, output 00:00:05, output hang never Last clearing of "show interface" counters 00:00:49 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 9 packets input, 144 bytes, 0 no buffer Received 9 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 10 packets output, 152 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 1 carrier transitions BRI0:2 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, multilink Closed Closed: IPCP, CDPCP Last input 00:10:44, output 00:10:44, output hang never Last clearing of "show interface" counters 00:00:53 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 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 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, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions In this example, both B channels are down (the ISDN line is idle). show dialer CommandThis command enables you to determine which B channels are connected, as well as determine the destination number and the time until the call will tear down. It is also useful in that it shows the reason that each call was made (in the calling router only). Example 7-53 demonstrates the output generated from this command. Example 7-52 show dialer Command OutputCheech# show dialer BRI0 - dialer type = ISDN Dial String Successes Failures Last called Last status 6129319833 31 0 00:00:15 successful 0 incoming call(s) have been screened. BRI0:1 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs) Dialer state is physical layer up Dial reason: ip (s=175.10.23.1, d=175.10.23.2) Time until disconnect 104 secs Connected to 6129319833 (Chong) BRI0:2 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs) Dialer state is physical layer up Dial reason: Multilink bundle overloaded Time until disconnect 104 secs Connected to 6129319833 (Chong) In this example, both B channels are in use and are connected to a router named Chong. The first call was made as a result of an IP packet from 175.10.23.1 destined for 175.10.23.2 (which was allowed in the dialer-list). The second B channel was connected as a result of multilink bonding. (PPP multilink was configured on this particular BRI0 interface.) show isdn active CommandAs demonstrated in Example 7-54, this command is useful in showing the number of calls that are currently active, as well the number dialed and the idle time before disconnect. Example 7-53 show isdn active Command Output ISDN-1# show isdn active -------------------------------------------------------------------------------- ISDN ACTIVE CALLS -------------------------------------------------------------------------------- History table has a maximum of 100 entries. History table data is retained for a maximum of 15 Minutes. -------------------------------------------------------------------------------- Call Calling Called Remote Seconds Seconds Seconds Charges Type Number Number Name Used Left Idle Units/Currency -------------------------------------------------------------------------------- Out 6129319833 ISDN-2 6 0 0 -------------------------------------------------------------------------------- The "Big D" for ISDNIncluded here are some of the most useful debugging commands to use when trying to determine the cause of any ISDN anomalies. Among the most common problems are calls not connecting, calls that never hang up, and dialer interfaces that continuously connect, hang up, and then connect again. debug isdn q.921 CommandPersonally, we have never found this debug command to be particularly useful, except when troubleshooting SPID problems. The debug isdn q.921 command shows what is happening at Layer 2. The output in Example 7-55 shows what happens when the SPID's are improperly configured. Example 7-54 debug q.921 Command Outputdebug isdn q921 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 The router is sending identification requests (IDREQ) to the ISDN switch but is not receiving a response from the switch. If a SPID is incorrectly configured in the router, this debug command also shows that it was rejected. debug isdn events CommandDebugging Q.931 can be useful when you want to check the status of incoming and outgoing ISDN calls. This debug command displays the call setup and teardown process, and it can give some insight on what any problems with these processes might be. Example 7-56 demonstrates sample output from this command. Example 7-55 debug isdn events Command OutputBRI0: 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 Router# You can see that interesting traffic tried to initiate an ISDN connection, but the remote router did not answer the call (this is seen by the RX RELEASE) output. Normally, this problem is caused by a misconfigured dialing number or SPID. In this case, the dialing number was misconfigured. debug dialer CommandThis is probably the single most important debug command available. It can give insight to a number of things, such as the reason calls are initiated, whether the remote router is responding, and, in many cases, why calls fail. Example 7-57 demonstrates the output that appears when the router configuration is missing a dialer map or dialer string command. Example 7-56 debug dialer Command Output ISDN-1# debug dialer 1w1d: BR0 DDR: Dialing cause ip (s=175.10.23.1, d=175.10.23.2) 1w1d: BR0 DDR: No dialer string, dialing cannot occur 1w1d: BR0 DDR: Dialing cause ip (s=175.10.23.1, d=175.10.23.2) 1w1d: BR0 DDR: No dialer string, dialing cannot occur 1w1d: BR0 DDR: Dialing cause ip (s=175.10.23.1, d=175.10.23.2) 1w1d: BR0 DDR: No dialer string, dialing cannot occur 1w1d: BR0 DDR: Dialing cause ip (s=175.10.23.1, d=175.10.23.2) 1w1d: BR0 DDR: No dialer string, dialing cannot occur 1w1d: BR0 DDR: Dialing cause ip (s=175.10.23.1, d=175.10.23.2) 1w1d: BR0 DDR: No dialer string, dialing cannot occur Unlike many other debug outputs, the debug dialer gives some intuitive information about the reason calls fail. Perhaps the most useful information that we can obtain is the reason that calls initiate, showing which packets actually pass through the dialer list to make outgoing calls. For example, say that you are seeing the ISDN line connecting constantly, even though you have a restrictive dialer list in place. Example 7-58 shows the resulting output from the debug dialer command with this set of circumstances. Example 7-57 debug dialer Command OutputISDN-1# debug dialer 1w1d: BR0 DDR: Dialing cause ip (s=175.10.23.1, d=224.0.0.10) 1w1d: BR0 DDR: Attempting to dial 6129319833 1w1d: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up 1w1d: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 6129319833 1w1d: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up 1w1d: Vi1 DDR: dialer protocol up 1w1d: %SYS-5-CONFIG_I: Configured from console by console 1w1d: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up 1w1d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up The highlighted output type shows that the reason for the ISDN call is an IP packet with a source of 175.10.23.1 to a destination of 224.0.0.10. If you did your homework, you know that the 224.0.0.10 is a multicast address that EIGRP uses to announce routes. Therefore, EIGRP updates are triggering the call. To remedy this, make sure that the BRI interface is listed as passive under the EIGRP process, or deny all EIGRP packets in your dialer list. Some extensions to the debug dialer command are the debug dialer packets and events commands. debug dialer packets will give you some in depth insight on packets that are interesting and those that are not. debug dialer events will show you some additional information about the call setup and teardown process. debug ppp authentication CommandExample 7-59 reflects a situation in which the BRI interface constantly goes up and down and no traffic will traverse the link. Example 7-58 Authentication Failure Symptoms Cheech# ping 175.10.23.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 175.10.23.2, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Cheech# %LINK-3-UPDOWN: Interface BRI0:1, changed state to up %LINK-3-UPDOWN: Interface BRI0:1, changed state to down %LINK-3-UPDOWN: Interface BRI0:1, changed state to up %LINK-3-UPDOWN: Interface BRI0:1, changed state to down %LINK-3-UPDOWN: Interface BRI0:1, changed state to up %LINK-3-UPDOWN: Interface BRI0:1, changed state to down %LINK-3-UPDOWN: Interface BRI0:1, changed state to up %LINK-3-UPDOWN: Interface BRI0:1, changed state to down %LINK-3-UPDOWN: Interface BRI0:1, changed state to up %LINK-3-UPDOWN: Interface BRI0:1, changed state to down Cheech# A prime suspect for this type of behavior is PPP authentication failure. Example 7-60 shows the output from the debug ppp authentication command to indicate the symptoms of this problem. Example 7-59 PPP Authentication Debugging Cheech# debug ppp authentication %LINK-3-UPDOWN: Interface BRI0:1, changed state to up BR0:1 PPP: Treating connection as a callout BR0:1 PPP: Phase is AUTHENTICATING, by both BR0:1 CHAP: O CHALLENGE id 17 len 27 from "Cheech" BR0:1 CHAP: I CHALLENGE id 17 len 26 from "Chong" BR0:1 CHAP: O RESPONSE id 17 len 27 from "Cheech" BR0:1 CHAP: I FAILURE id 17 len 21 msg is "MD compare failed" %LINK-3-UPDOWN: Interface BRI0:1, changed state to down As you can see, the MD compare failed, indicating that the username and password combination was incorrectly configured on one of the routers. As it turns out, Cheech had the following command in its configuration: username Chong password cisco Meanwhile, Chong had the following: username Chong password cisco As you can see, the passwords must match exactly, and they are case-sensitive. |
Shows that the interface is up and the ISDN | < Free Open Study > |
EAN: 2147483647
Pages: 283