I recently ran into an some issue with one of my Branch office PRI’s. As with most issues it started off with a call to Helpdesk which eventually made its way to me. After making a couple quick inbound test calls over their main DID number which of course failed I decided to move on to a more detailed investigation of the problem.
ISDN FAQ
The ISDN standard is one of the specifications from the International Telecommunication Union or ITU along with the American National Standards Institute or ANSI. These two groups, help to define the ISDN standards. The Q group is primarily respnsible for the switching and signaling portion of the standard. The way I like to distinguish the two is to think about Q standards are at Layer 2 and Layer 3.
- Q.921 – Data Link Layer at Layer 2
- Q.931 – Call Control and Signaling at Layer 3
As with most ISDN related problems or network related problems for that matter it usually comes down to Layers 1, 2 or 3. After a quick look at the ISDN status it was apparent that my problem was at Layer 2. This usually points to a problem with the Telco ISDN switch, but I had to run through the normal troubleshooting steps.
R1#show isdn status Global ISDN Switchtype = primary-ni %Q.931 is backhauled to CCM MANAGER 0x0003 on DSL 0. Layer 3 output may not apply ISDN Serial0/0/1:23 interface dsl 0, interface ISDN Switchtype = primary-ni L2 Protocol = Q.921 0x0000 L3 Protocol(s) = CCM MANAGER 0x0003 Layer 1 Status: ACTIVE Layer 2 Status: TEI = 0, Ces = 1, SAPI = 0, State = TEI_UNASIGNED Layer 3 Status: 0 Active Layer 3 Call(s) Active dsl 0 CCBs = 0 The Free Channel Mask: 0x807FFFFF Number of L2 Discards = 0, L2 Session ID = 27 Total Allocated ISDN CCBs = 0
This is more than likely a a Telco related issue, but I’m probably going to have to prove it before they will help. At the vary least give myself a little fire power before I call and open up a trouble ticket. So lets turn on some debugging and find out what’s going on or not going on at Layer 2.
R1#configure terminal R1(config)#logging buffered 10000 R1(config)#no logging console R1(config)#no logging monitor R1(config)#exit R1#clear logging R1#clear counters R1#debug isdn q921
Now lets take a closer look at the logs to see what’s going on with Layer 2
R1#show logging *Jun 9 13:42:43.327: ISDN Se0/0/1:23 Q921: User RX <- DMf sapi=0 tei=0 *Jun 9 13:42:53.315: ISDN Se0/0/1:23 Q921: L2_EstablishDataLink: sending SABME *Jun 9 13:42:53.315: ISDN Se0/0/1:23 Q921: User TX -> SABMEp sapi=0 tei=0 *Jun 9 13:42:53.327: ISDN Se0/0/1:23 Q921: User RX <- DMf sapi=0 tei=0 *Jun 9 13:43:03.327: ISDN Se0/0/1:23 Q921: L2_EstablishDataLink: sending SABME *Jun 9 13:43:03.327: ISDN Se0/0/1:23 Q921: User TX -> SABMEp sapi=0 tei=0 *Jun 9 13:43:03.351: ISDN Se0/0/1:23 Q921: User RX <- DMf sapi=0 tei=0 *Jun 9 13:43:13.339: ISDN Se0/0/1:23 Q921: L2_EstablishDataLink: sending SABME *Jun 9 13:43:13.339: ISDN Se0/0/1:23 Q921: User TX -> SABMEp sapi=0 tei=0 *Jun 9 13:43:14.339: ISDN Se0/0/1:23 Q921: User TX -> SABMEp sapi=0 tei=0 *Jun 9 13:43:14.351: ISDN Se0/0/1:23 Q921: User RX <- DMf sapi=0 tei=0 *Jun 9 13:43:23.343: ISDN Se0/0/1:23 Q921: L2_EstablishDataLink: sending SABME *Jun 9 13:43:23.343: ISDN Se0/0/1:23 Q921: User TX -> SABMEp sapi=0 tei=0 *Jun 9 13:43:24.343: ISDN Se0/0/1:23 Q921: User TX -> SABMEp sapi=0 tei=0 *Jun 9 13:43:24.351: ISDN Se0/0/1:23 Q921: User RX <- DMf sapi=0 tei=0
The logging indicates that the Router didn’t receive the ISDN SABME or Set Asynchronous Balanced Mode Extended message, and was unable to responded with the UA or Unnumbered Acknowledge frames to synchronize with the Telco ISDN switch.
After opening up a trouble ticket with my Service Provide, and providing them with the logs they decided to perform intrusive testing on the PRI circuit. They would have performed the intrusive testing regardless of the logs, but its always helpful to provide as much information as possible when troubleshooting.
Checking The T1 Controller
It’s always a good idea to check the status of the T1 controller. For that matter its probably the best place to start when your troubleshooting ISDN related issues.
R1#show controllers t1 0/0/1 T1 0/0/1 is up. Applique type is Channelized T1 Cablelength is long 0db Description: VOICE No alarms detected. alarm-trigger is not set Soaking time: 3, Clearance time: 10 AIS State:Clear LOS State:Clear LOF State:Clear Version info FPGA Rev: 08121917, FPGA Type: PRK1 Framing is ESF, Line Code is B8ZS, Clock Source is Line. CRC Threshold is 320. Reported from firmware is 320.
After numerous phone calls and troubleshooting with my Service Provider they informed me that the ISDN switch was sending DM disconnect message which basically means the ISDN switch is refusing the connection from the Router. Lets take a look at the status of the PRI now that they made the necessary configuration change on the ISDN switch.
R1#show isdn status Global ISDN Switchtype = primary-ni %Q.931 is backhauled to CCM MANAGER 0x0003 on DSL 0. Layer 3 output may not apply ISDN Serial0/0/1:23 interface dsl 0, interface ISDN Switchtype = primary-ni L2 Protocol = Q.921 0x0000 L3 Protocol(s) = CCM MANAGER 0x0003 Layer 1 Status: ACTIVE Layer 2 Status: TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED Layer 3 Status: 0 Active Layer 3 Call(s) Active dsl 0 CCBs = 0 The Free Channel Mask: 0x807FFFFF Number of L2 Discards = 0, L2 Session ID = 27 Total Allocated ISDN CCBs = 0
It took the better part of at day troubleshooting with the my Service Provider over the phone, but they were finally able to determine that someone had placed a loop on the PRI. The explanation didn’t make a lot of sense at the time considering that they were always able to loop the smatjacket. At any rate Layer 2 came up and calls started completing again.
I hope that you found this post on ISDN Q921 helpful and informative. Be sure to let me know what you think by leaving your suggestions, and feedback in the comments section below. You can find out more about these and other articles be checking out recent posts and archives. To learn more about myself be sure to check out the About page. And as always thanks again for visiting The Packet.
