ISDN Layer 2 stays on "TEI ASSIGNED" state

[kukamara]

Hi Folks,

I have an MGCP gateway and its controller T1 0/0/0 stays TEI ASSIGNED for Layer 2 status. We tried changing the ISDN switch type, Line coding and Framing with no luck. I have few information and logs attached. Can you please suggest me for troubleshooting.

Show controller T1

T1 0/0/0 is up.

Applique type is Channelized T1
Cablelength is long 0db
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: PRK4
Framing is ESF, Line Code is B8ZS, Clock Source is Line.
CRC Threshold is 320. Reported from firmware is 320.
Data in current interval (208 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Total Data (last 3 15 minute intervals):
0 Line Code Violations, 0 Path Code Violations,
1 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,
1 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 10 Unavail Secs

show interface serial 0/0/0:23

Serial0/0/0:23 is up, line protocol is up (spoofing)
Hardware is DSX1
MTU 1500 bytes, BW 64 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, crc 16, loopback not set
Keepalive set (10 sec)
Last input never, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
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 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
1370 packets output, 4110 bytes, 0 underruns
0 output errors, 0 collisions, 7 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
3 carrier transitions

debug isdn q921 & debug isdn q921 detail

109745: Jul 16 02:20:54.394: ISDN Se0/0/0:23 Q921: L2_EstablishDataLink: sending SABME
109746: Jul 16 02:20:54.394: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0
109747: Jul 16 02:20:55.394: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

109748: Jul 16 02:20:56.394: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0
109749: Jul 16 02:20:57.394: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

109750: Jul 16 02:21:04.402: ISDN Se0/0/0:23 Q921: L2_EstablishDataLink: sending SABME
109751: Jul 16 02:21:04.402: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0
109752: Jul 16 02:21:05.402: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

detail

108671: Jul 16 01:13:24.679: ISDN Se0/0/0:23 Q921d: handle_mail: setting pkt to NULL
108672: Jul 16 01:13:24.679: ISDN Q921d: isdn_l2d_srq_process: QUEUE_EVENT
108673: Jul 16 01:13:24.679: ISDN Q921d: isdn_l2d_srq_process: event_count 1
108674: Jul 16 01:13:25.679: ISDN Q921d: l2_timer: timer (0x2312C250), timer_type (0x1240)
108675: Jul 16 01:13:25.679: ISDN Q921d: isdn_l2d_srq_process: QUEUE_EVENT
108676: Jul 16 01:13:25.679: ISDN Q921d: isdn_l2d_srq_process: event_count 1

108677: Jul 16 01:13:26.679: ISDN Q921d: l2_timer: timer (0x2312C250), timer_type (0x1240)
108678: Jul 16 01:13:26.679: ISDN Se0/0/0:23 Q921d: S5_T200_EXPIRY: dlcb->N200=3 dlcb->RC=1
108679: Jul 16 01:13:26.679: ISDN Q921d: isdn_l2d_srq_process: QUEUE_EVENT
108680: Jul 16 01:13:26.679: ISDN Q921d: isdn_l2d_srq_process: event_count 1
108681: Jul 16 01:13:27.679: ISDN Q921d: l2_timer: timer (0x2312C250), timer_type (0x1240)
108682: Jul 16 01:13:27.679: ISDN Se0/0/0:23 Q921d: S5_T200_EXPIRY: dlcb->N200=3 dlcb->RC=2
108683: Jul 16 01:13:27.679: ISDN Q921d: isdn_l2d_srq_process: QUEUE_EVENT
108684: Jul 16 01:13:27.679: ISDN Q921d: isdn_l2d_srq_process: event_count 1

Configuration of Controller and Serial interface

controller T1 0/0/0
cablelength long 0db
pri-group timeslots 1-24 service mgcp

interface Serial0/0/0:23
no ip address
encapsulation hdlc
isdn switch-type primary-ni
isdn incoming-voice voice
isdn bind-l3 ccm-manager
no cdp enable

[Philip D'Ath]

"TEI ASSIGNED" is a good state.  What is your actual issue?

[j.huizinga]

On T1 and E1 PRI the L2 status should be

MULTIPLE_FRAME_ESTABLISHED

[Suresh Hudda]

What you see when you check 'show ccm-manager' from gateway ? Can you attach the output here, and what is the status of mgcp gateway in cucm ?

Suresh

[j.huizinga]

Contact your provider, the gateway sends SABME frames, and the provider should respond, but they don't

Bye

[Rishabh Ghai]

Hi,

To get the issue surfaced, start step by step troubleshooting:

• Ensure that the framing and line code settings match with the switch the gateway is attached to.
• I could see slip sec error in the show controllers output which points to improper clocking configuration. Kindly ensure that one side of the connection is providing clock while the other is deriving clock from the line.
• Check or replace your cables and, if necessary, ask your service provider to test the line. If the problem persists, there's always the possibility of bad hardware. If you have a second port to test with, try a different port to see if the problem resolves itself.

Once verified the physical layer connectivity / configurations, proceed further with the troubleshooting of the signaling channel, i.e., D-Channel:

• Issue the command show isdn status
• Ensure Layer 1 is Active; if not Active, then once again verify the controller as there is a problem with physical connectivity.
• Ensure switch type is correctly configured to get MULTIPLE_FRAME_ESTABLISHED status under Layer 2.

Debugging

• From the q.921 debugs attached, it can be observed that the gateway transmits SABME message; however, never receives any UAf message from the other end. Kindly ensure that the D-channel is enabled on the equipment attached to the gateway. You might need to involve your service provider to get it verified for you.
• You can verify if the SABME messages are indeed being transmitted out of the port by plugging a loopback plug into the T1/E1 port on the gateway. Be sure to change the clock to use the internal clock source and ensure that the controller comes up. Enable the debug isdn q921 and shut/no shut the controller again. After the gateway transmits the SABME message, it should get looped back toward the gateway, and the following message should appear:

RX <- BAD FRAME(0x00017F)Line may be looped!

• If you see this message, everything is working correctly from the gateway's point of view. The gateway sees its own packet and marks it as a bad frame. This means the frame was sent out of the port, got looped by the loopback plug, and was received back by the gateway.
• Once you are done troubleshooting the gateway / controller, you likely need to get your service provider involved.

[a.mehmood]

Just for the sake of documentation and for someone hunting down this issue!!!

followingsolution solved my problem (in my case No. 2):

1. Under the serial interface remove the isdn bind command and do a

shut/no shut. Do you see the Tx now and also does show isdn status show

multiple frames established? If it does you know the PRI is good and move

to step 2.

2. I have had similar issues lately and just doing a no mgcp/mgcp does not

fix it. Do you have “mgcp bind media/mgcp bind control” commands bound to

a loopback or anything? If so, try removing these binds, do a no

mgcp/mgcp, and then you can put the bind commands back in, no mgcp/mgcp.

3. If all that doesn’t work enable ccm-manager config and do a ccm-manager

config reset version id followed by a ccm-manager config check config

reset.

Thank goes to 

VOIPMonkey