Broadwing PRI - AS5300

[mmedwid]

Is anyone using PRIs from Broadwing and terminating these on a Cisco

AS5300? We have been running into difficulty provisioning the

circuit. I actually show circuit active and D channel up. But on

their side they see D channel go into "lockout mode". I have not run

into these issues with SBC/Pac Bell, WorldCom or (earlier) Global

Crossing. The relevant configuration I have on my side:

!

controller T1 1

framing esf

linecode b8zs

pri-group timeslots 1-24

description Broadwing PRI DS3-1 port 10 circuit #40112345

interface Serial1:23

ip unnumbered FastEthernet0

no ip directed-broadcast

encapsulation ppp

timeout absolute 720 0

dialer idle-timeout 600

dialer-group 1

isdn switch-type primary-ni

isdn tei-negotiation first-call

isdn incoming-voice modem 64

peer default ip address pool second_pool

fair-queue 64 256 0

ppp authentication pap ms-chap chap

ppp multilink

!

[mmedwid]

btw - they type of switch Broadwing is using is the DMS250.

[tepatel]

If the PRI line is from DMS250 then try using the "isdn switch-type primary-dms100".

You can try troubleshooting the PRI line from layer 1. Here is the url for that.

http://www.cisco.com/warp/public/116/T1_pri.html

It has more links based on the issues to troubleshoot.

[mmedwid]

Well what's killing me is that it looks good on my end:

ISDN Serial1:23 interface

dsl 1, interface ISDN Switchtype = primary-dms100

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)

Activated dsl 1 CCBs = 0

And show controller T1 1 shows only...

Total Data (last 24 hours)

0 Line Code Violations, 14 Path Code Violations,

5 Slip Secs, 1 Fr Loss Secs, 0 Line Err Secs, 2 Degraded Mins,

7 Errored Secs, 1 Bursty Err Secs, 1 Severely Err Secs, 0 Unavail Secs

And the circuits been brought down and up a few times during that period.

I will read a little more closely on the SABMEs to make sure I understand part of the debug process.

[tepatel]

First try to do the hardware loopback test as per

http://www.cisco.com/warp/public/471/hard_loopback.html

to test the hardware in the router. After that move on to target layer 2 and 3.

[mmedwid]

The layer 2 test already appear to confirm connectivity to the ISDN switch - no? The keep alives are sent and received...

Feb 28 16:00:57: ISDN Se1:23: RX <- RRp sapi = 0 tei = 0 nr = 0

Feb 28 16:00:57: ISDN Se1:23: TX -> RRf sapi = 0 tei = 0 nr = 0

Feb 28 16:01:07: ISDN Se1:23: TX -> RRp sapi = 0 tei = 0 nr = 0

Feb 28 16:01:07: ISDN Se1:23: RX <- RRp sapi = 0 tei = 0 nr = 0

Feb 28 16:01:07: ISDN Se1:23: TX -> RRf sapi = 0 tei = 0 nr = 0

Feb 28 16:01:07: ISDN Se1:23: RX <- RRf sapi = 0 tei = 0 nr = 0

Feb 28 16:01:17: ISDN Se1:23: RX <- RRp sapi = 0 tei = 0 nr = 0

Feb 28 16:01:17: ISDN Se1:23: TX -> RRf sapi = 0 tei = 0 nr = 0

Feb 28 16:01:27: ISDN Se1:23: TX -> RRp sapi = 0 tei = 0 nr = 0

Feb 28 16:01:27: ISDN Se1:23: RX <- RRp sapi = 0 tei = 0 nr = 0

Feb 28 16:01:27: ISDN Se1:23: TX -> RRf sapi = 0 tei = 0 nr = 0

Feb 28 16:01:27: ISDN Se1:23: RX <- RRf sapi = 0 tei = 0 nr = 0

Feb 28 16:01:37: ISDN Se1:23: RX <- RRp sapi = 0 tei = 0 nr = 0

Feb 28 16:01:37: ISDN Se1:23: TX -> RRf sapi = 0 tei = 0 nr = 0

Feb 28 16:01:47: ISDN Se1:23: TX -> RRp sapi = 0 tei = 0 nr = 0

Feb 28 16:01:47: ISDN Se1:23: RX <- RRp sapi = 0 tei = 0 nr = 0

Feb 28 16:01:47: ISDN Se1:23: TX -> RRf sapi = 0 tei = 0 nr = 0

Feb 28 16:01:47: ISDN Se1:23: RX <- RRf sapi = 0 tei = 0 nr = 0

Feb 28 16:01:57: ISDN Se1:23: RX <- RRp sapi = 0 tei = 0 nr = 0

[mmedwid]

And note after a shut/no shut of int s 1:23...

Feb 28 16:51:34: ISDN Se1:23: RX <- SABMEp sapi = 0 tei = 0

Feb 28 16:51:34 PST: %ISDN-6-LAYER2UP: Layer 2 for Interface Se1:23, TEI 0

Feb 28 16:51:34: ISDN Se1:23: TX -> UAf sapi = 0 tei = 0exit

[makchitale]

This problem was seen with older DMS switches & addressed in CSCdk94188, where after a reload on the router, most of the ds0's are locked out from the switch. If we check the status of the DS0's from the router, they seem to be normal.

Under the interface s1:23 please add the following hidden command "isdn flip-chan-flag"

Hopefully this helps.

Thanks, Mak.

[mmedwid]

Thanks Mark. I have put that in. I won't know until I hear back from the Broadwing tech if that has helped or not.

-Michael