PRI-D channel Assitance

Unanswered Question
Sep 4th, 2007

Guys,

first time configuring PRI for voice and am having a little issue with the telco. they are asking me to turn up my D channel but have no idea of how this should be done.

My basic config is as follows

controller T1 0/0/0

framing esf

linecode b8zs

pri-group timeslots 1-24

interface Serial0/0/0:23

no ip address

encapsulation ppp

isdn switch-type primary-dms100

isdn incoming-voice voice

no cdp enable

my voice port is created and im thinking that should be all. show isdn status shows the following

Global ISDN Switchtype = primary-dms100

ISDN Serial0/0/0:23 interface

dsl 0, interface ISDN Switchtype = primary-dms100

Layer 1 Status:

ACTIVE

Layer 2 Status:

TEI = 0, Ces = 1, SAPI = 0, State = AWAITING_ESTABLISHMENT

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 = 46

Under layer 2 it sometimes shows the state as TEI_ASSIGNED then reverts to awaiting establishment.

finally, a show isdn service shows

PRI Channel Statistics:

ISDN Se0/0/0:23, Channel [1-24]

Configured Isdn Interface (dsl) 0

Channel State (0=Idle 1=Proposed 2=Busy 3=Reserved 4=Restart 5=Maint_Pend)

Channel : 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4

State : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3

if i show the serial interface i get the line protocol as being down

Serial0/0/0:23 is up, line protocol is down

any assistance would be greatly appreicated.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Loading.
a.gooding Wed, 09/05/2007 - 03:44

here it is, also, can you explain what they meant by turning up my D channel? im assuming the only thing i can do is issue a shut not shut on the Serial 0/0/0:23. interface.. also, ater the initial post, i saw the serial come up and the line protocl showed up (spoofed)

T1 0/0/0 is up.

Applique type is Channelized T1

Cablelength is long gain36 0db

Description: NOTE CHANGED TO CCS

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 Firmware: 20060707, FPGA: 13, spm_count = 0

Framing is ESF, Line Code is B8ZS, Clock Source is Line.

CRC Threshold is 320. Reported from firmware is 320.

Data in current interval (128 seconds elapsed):

0 Line Code Violations, 0 Path Code Violations

8 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins

8 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

Total Data (last 24 hours)

2 Line Code Violations, 6 Path Code Violations,

3498 Slip Secs, 0 Fr Loss Secs, 1 Line Err Secs, 1 Degraded Mins,

3498 Errored Secs, 1 Bursty Err Secs, 0 Severely Err Secs, 215 Unavail Secs

Paolo Bevilacqua Wed, 09/05/2007 - 03:48

They simply mean, start your device.

You circuit appears fine beside the slips. Please configure "network-clock-participate wic 0" and network-clock-select t1 0/0/0 1".

After that if still trouble please sedn output of "debug isdn q921" when going from shut to no shut under controller T1.

a.gooding Wed, 09/05/2007 - 04:39

did the network clock and select commands and shut down the controller and then brought back up. im seeing awaiting establishment. one last question. this should read multiframe established when its up correct?

043151: Sep 5 08:37:28.095 Caracas: %CONTROLLER-5-UPDOWN: Controller T1 0/0/0, changed state to up

043152: Sep 5 08:37:28.095 Caracas: ISDN Se0/0/0:23 Q921: L2_EstablishDataLink: sending SABME

043153: Sep 5 08:37:28.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043154: Sep 5 08:37:29.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043155: Sep 5 08:37:30.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043156: Sep 5 08:37:30.095 Caracas: %LINK-3-UPDOWN: Interface Serial0/0/0:23, changed state to up

043157: Sep 5 08:37:31.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043158: Sep 5 08:37:37.095 Caracas: ISDN Se0/0/0:23 Q921: L2_EstablishDataLink: sending SABME

043159: Sep 5 08:37:37.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043160: Sep 5 08:37:38.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043161: Sep 5 08:37:38.355 Caracas: %MARS_NETCLK-3-CLK_TRANS: Network clock source transitioned from priority 11 to priority 1

043162: Sep 5 08:37:39.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043163: Sep 5 08:37:40.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043164: Sep 5 08:37:46.095 Caracas: ISDN Se0/0/0:23 Q921: L2_EstablishDataLink: sending SABME

043165: Sep 5 08:37:46.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043166: Sep 5 08:37:47.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043167: Sep 5 08:37:48.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043168: Sep 5 08:37:49.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043169: Sep 5 08:37:55.095 Caracas: ISDN Se0/0/0:23 Q921: L2_EstablishDataLink: sending SABME

043170: Sep 5 08:37:55.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043171: Sep 5 08:37:56.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043172: Sep 5 08:37:57.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043173: Sep 5 08:37:58.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043174: Sep 5 08:38:04.095 Caracas: ISDN Se0/0/0:23 Q921: L2_EstablishDataLink: sending SABME

043175: Sep 5 08:38:04.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043176: Sep 5 08:38:05.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043177: Sep 5 08:38:06.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043178: Sep 5 08:38:07.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043179: Sep 5 08:38:13.095 Caracas: ISDN Se0/0/0:23 Q921: L2_EstablishDataLink: sending SABME

043180: Sep 5 08:38:13.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043181: Sep 5 08:38:14.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043182: Sep 5 08:38:15.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

043183: Sep 5 08:38:16.095 Caracas: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

Paolo Bevilacqua Wed, 09/05/2007 - 05:02

Hi,

you are not receiving anything. Check with telco thye have activated their side and have no alarms.

Unrelated question: Is your router really in Caracas? I was told repeatedly that ISDN is not available in Venezuela.

a.gooding Wed, 09/05/2007 - 05:10

thanks, have a conference call with the provider so i just wanted to be as prepared as possible. also, is it supposed to say Multiframe established?.

finally, hehe, no its not in caracas, we are in Trinidad near to venezuela and the time zone we normally set is Caracas La Paz. yeah i dont think they have PRI as yet. actually, our provider is now offering PRI (This customer is one of the first to have it) hence my basic questions since we always normally configure CAS.

Unrelated question :) do you do work on this side of the world? (As youre asking about Venezuela)

Paolo Bevilacqua Wed, 09/05/2007 - 12:55

I see. Yes the normal status of a PRI is multiframe established.

And yes I "do have" routers in Venezuela as well in Europe, Haiti, Guatemala, Santo Domingo, Argentina soon and others.

Never been to Trinidad but I think I should :)

a.gooding Wed, 09/05/2007 - 17:35

cool, shoot me an email if you wouldnt mind. i think you would like what we are trying to do.

a.gooding Thu, 09/06/2007 - 05:55

- provider says all the channels are up and idle except the D-Channel which is in a locked state. i verified the configurations again but they say that they are not receiving any signalling information from my router. is there anything else i can recommend doing?

just to get something clear as well. the serial 0/0/0:23 is the D channel correct? also do i need to configure nfas_d ?

Paolo Bevilacqua Thu, 09/06/2007 - 06:09

Your config is fine. But you are not receiving anything neither they do. Please recheck all layer 1, circuit, cabling to NTU, all these things. Ask here if you aren't sure about something.

Ask them if they seen any alarm at E1 level. Last resort, prepare a rj-45 loop in form of a female socket and connect it in place of the the router, this will definitely lift the burden of proof from you. The pinout is on the manual page for the card, however it's always the same.

My email is in my profile. Good luck!

pacameron Thu, 09/06/2007 - 06:17

Fixed an issue like this last week ... try changing the encapsulation on the D channel from PPP to HDLC, then reload the router. Use the command 'encapsulation hdlc ' under the D channel config.

At the moment, the telco is likely having trouble understanding the D channel messages when they are framed as PPP :-)

Paolo Bevilacqua Thu, 09/06/2007 - 09:49

Hi, you know like I do that in fact encapsulation on an ISDN interface only changes the encapsulation for B-channels when used for data. Encapsulation on D-channel is only and always LAPD, that is the layer 2 of ISDN.

This said I can totally believe that restoring the encapsulation to default and a reboot is beneficial, also considering that ISR routers only recently gained data capability on the VWICx moduled.

a.gooding Thu, 09/06/2007 - 10:13

well, i think ive tried everything. just off the phone after a marathon 3 hours with the provider with no success. they say their D channel is locked out and they turned on a trunk and got a D channel out of service. they are re-checking the cross connects but it doesnt look good.

Paolo Bevilacqua Thu, 09/06/2007 - 10:39

Let them work and things will eventually work.

It is very, very hard to find a cisco router is culpable. (ok, sometime it is, but not to the point of locking a telco's interface).

cg100668 Tue, 10/21/2008 - 11:46

Hi There. Did you manage to solve the problem. I am having exactly the same issue on a T1 connected to a CCME. The installation is in New York. Please let me know.

Thanks

Chandrasen

a.gooding Tue, 10/21/2008 - 22:13

the issue was the encapsulation as it should have been hdlc rather than ppp.

cg100668 Tue, 10/21/2008 - 22:16

Hi. Thanks very much for the reply. I already had encapsulation as hdlc. Last night the problem was solved by the service provider. They did not tell me what they did but it is working now. Thanks for your quick reply. Highly appreciated.

Chandrasen

a.gooding Wed, 10/22/2008 - 04:26

i was contemplating mentioning that as well since in my experience most of the issues are on the carrier side. actually we just did another PRI and for about a month they advised that they are not seeing our D-Channel up. after conversations back and forth they finally brought up thier side :)

glad it worked

sohaildxbfze Sun, 03/21/2010 - 08:36

Hi paul,

can u tell me wots wrong with my d channel????i ca nc CRCs only, but after some weeks d channel goes out of service & comes back again automatically.

sh  int s1/0:15
Serial1/0:15 is up, line protocol is up (spoofing)
  Hardware is DSX1
  MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec,
     reliability 255/255, txload 225/255, rxload 1/255
  Encapsulation HDLC, loopback not set
  Last input 00:00:07, output 00:00:07, output hang never
  Last clearing of "show interface" counters 00:00:25
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/1/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 48 kilobits/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     2 packets input, 8 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 20 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     2 packets output, 8 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     7 carrier transitions

Aaron Harrison Sun, 03/21/2010 - 13:10

Hi

Do a 'show controllers e1/t1' and post that back.. may be a clocking misconfig...

Aaron

a.gooding Mon, 03/22/2010 - 19:50

Since then ive gotten a little better at configuring PRI heheehe....ill have to go with Arron and addressing clocking.

i also realized that we needed to set network clock participate and select to fix clocking issues on my side with the now many PRI deployments ive achieved since this post 

GJHiggins Thu, 07/15/2010 - 14:25

Agreed on network-clock-participate, netowrk-clock-select and so on. But one thing that certain telcos require (and don't know to ask for) is this old command:

isdn protocol-emulate network

this mimics legacy attributes of switches and can be the only thing standing between you and MULTIPLE_FRAME_ESTABLISHED.

Paolo Bevilacqua Thu, 07/15/2010 - 22:13

Agreed on network-clock-participate, netowrk-clock-select and so on.  But one thing that certain telcos require (and don't know to ask for) is  this old command:

isdn  protocol-emulate network

Incorrect, that is NEVER required to connect to telco.

Howeverm it it OFTEN required, to connect to PBXs.

GJHiggins Fri, 07/16/2010 - 02:36

Perhaps I did not word that clearly--not for connection to CO, but it is sometimes required on the local gateway to bring

up a circuit due to the configuration on the carrier side. The command is the only thing that will bring the PRI up in those scenarios. Normally it is not a command one sees regularly. In cases like that noted in this thread, one can go in circles with a provider where the protocol-emulate network command fixes it.

Paolo Bevilacqua Fri, 07/16/2010 - 17:30

Well, you said telco. Telco = CO.

In theory is possible that you will have a router network-side facing a a WAN circuit, in practice it's unlikely as this type of connections are most often purely local.

Actions

This Discussion