Debug and Show Commands for ISDN
By Chris Bryant
Expert Author
Article Date: 2005-02-11
The major reason I recommend getting your hands on real Cisco equipment rather than
a simulator is that real Cisco routers give you the chance to practice and learn show and
debug commands.
The knowledge you acquire from debugs is invaluable. Frankly, it's this knowledge that puts
you above the "average" CCNA who doesn't have that hands-on experience. Watching
debugs in action also gives you a head start on the CCNP. Since 90 - 95% of CCNAs go on to
pursue the CCNP, it's a great idea to get started with debugs now.
Don't make the mistake of waiting until you're studying for your CCNP and CCIE to start
learning debugs and shows. The work you do for the CCNA is the foundation for everything
you'll do in the future.
Never practice debugs on a production network. There are debugs that will give you so much
information that the router actually becomes overloaded and then locks up. Never practice
debugs on a production network.
It's important to know the proper show and debug commands for ISDN for several reasons.
First, by watching ISDN in operation, you can see its processes and better understand what's
going on. Secondly, it's difficult if not impossible to properly troubleshoot ISDN without
knowing the proper show and debug commands. (It's easy to overlook an ISDN
authentication error just by looking at the configuration, but running debug ppp negotiation
will quickly show you where the problem lies.)
Let's take a look at the ISDN show and debug commands that every CCNA and CCNP
should know.
Show ISDN Status
If you only know one ISDN show command, it's got to be this one. Always use this command
after configuring your ISDN switch type and any necessary SPIDs. The command will show
you the switch type (and will also show you if you did not configure a switch type), and
whether the SPIDs you entered are valid:
R1#show isdn status
Global ISDN Switchtype = basic-ni
ISDN BRI0 interface
dsl 0, interface ISDN Switchtype = basic-ni
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 91, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
TEI = 92, Ces = 2, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Spid Status:
TEI 91, ces = 1, state = 5(init)
spid1 configured, no LDN, spid1 sent, spid1 valid
Endpoint ID Info: epsf = 0, usid = 1, tid = 1
TEI 92, ces = 2, state = 5(init)
spid2 configured, no LDN, spid2 sent, spid2 valid
Endpoint ID Info: epsf = 0, usid = 3, tid = 1
Layer 3 Status:
0 Active Layer 3 Call(s)
Activated dsl 0 CCBs = 0
The Free Channel Mask: 0x80000003
Once in a while, you'll get this output from show isdn status:
R2#show isdn status
The current ISDN Switchtype = basic-ni1
ISDN BRI0 interface
Layer 1 Status:
ACTIVE
Layer 2 Status:
Layer 2 NOT Activated
Spid Status:
TEI Not Assigned, ces = 1, state = 3(await establishment)
spid1 configured, no LDN, spid1 NOT sent, spid1 NOT valid
TEI Not Assigned, ces = 2, state = 1(terminal down)
spid2 configured, no LDN, spid2 NOT sent, spid2 NOT valid
Check your running configuration, and if the SPIDs look good, simply close the BRI
interface and open it again. Then run show ISDN status again. If you then see "spids are
valid", you're ready to proceed. If you still see a message that the spids are invalid, you've
most likely mistyped the SPID.
Show Access-List
What's this command got to do with ISDN? Everything.
Remember how the ISDN link comes up in the first place? Interesting traffic. By default,
there is no interesting traffic. You define interesting traffic with the dialer-list and dialergroup commands, AND the access-list command. If you have a problem with your link never
coming up or with it coming up and staying up, use this command to see what traffic has
been defined as interesting.
Show Dialer
Another helpful command to determine why an ISDN link is coming up and staying up. This
command shows you how many successful calls and failed calls have taken place, what the
current idle-timer value is (by default, it's 120 seconds), and most importantly, what the
source and destination was for the current interesting traffic:
R1#show dialer
BRI0 - dialer type = ISDN
Dial String
Successes
Failures
Last called
Last status
8358662
1
0
00:00:59
successful
0 incoming call(s) have been screened.
0 incoming call(s) rejected for callback.
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 data link layer up
Dial reason: ip (s=172.12.21.1, d=172.12.21.2)
Time until disconnect 62 secs
Connected to 8358662 (R2)
Here, you can see that the idle-timer value is at its default, that there are 62 seconds left until
the link comes down (unless interesting traffic resets the timer), and that the source of the
interesting traffic was 172.12.21.1 and the destination is 172.12.21.2. If that destination is the
multicast address of a routing protocol - say, 224.0.0.5 for OSPF - you know what traffic is
keeping the line up.
Show ISDN History
Want to see what calls have been made in the last 15 minutes? Just run this command. It's
helpful if you're walking in to an ISDN troubleshooting situation and want to see what calls
have been made.
R1#show isdn history-------------------------------------------------------------------------------ISDN CALL HISTORY-------------------------------------------------------------------------------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 ChargesType Number .Number Name Used Left
Idle Units/Currency----------------------------------------------------------------------------------------------------------Out 8358662 R2 121 0Out 8358662 R2 121 0---------------------------------------------------------------------------------------------------Debug PPP Negotiation
Not only do you need to know this command for your CCNA and CCNP exams, you MUST
know it to be an effective ISDN troubleshooter.
When PPP authentication is first configured, it's simple to mistype a password, or forget to
configure a "username / password" combination. Instead of continually reading your running
configuration to see what the problem is, run debug ppp negotiation and send a ping to bring
the line up. You'll quickly see where the problem is.
R2#debug ppp negotiation
PPP protocol negotiation debugging is on
R2#ping 172.12.21.1
BR0:1 PPP: Phase is AUTHENTICATING, by both
BR0:1 CHAP: O CHALLENGE id 1 len 23 from "R2"
BR0:1 CHAP: I CHALLENGE id 1 len 23 from "R1"
BR0:1 CHAP: O RESPONSE id 1 len 23 from "R2"
BR0:1 CHAP: I SUCCESS id 1 len 4
BR0:1 CHAP: I RESPONSE id 1 len 23 from "R1"
BR0:1 CHAP: O SUCCESS id 1 len 4
By mastering these simple ISDN show and debug commands, you increase your chances of
passing the CCNA and CCNP exams greatly, and vastly improve your on-the-job skills.