ISDN bouncing...

[voltron1011]

Two of my remote offices are having some funky ISDN bouncing issues. Please note that these sites have frame as their primary link and ISDN as their dial-backup sollution. Here is the output of my 'show isdn status'(note that both BRI's are in state 8):

dsl 0, interface ISDN Switchtype = basic-ni
Layer 2 Status:
TEI = 88, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
TEI = 105, Ces = 2, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
TEI 88, ces = 1, state = 8(established)
spid1 configured, spid1 sent, spid1 valid
Endpoint ID Info: epsf = 0, usid = 0, tid = 1
TEI 105, ces = 2, state = 8(established)
spid2 configured, spid2 sent, spid2 valid
Endpoint ID Info: epsf = 0, usid = 1, tid = 1


However, after a few minutes the two BRI's will all of the sudden go to this state:

dsl 0, interface ISDN Switchtype = basic-ni
Layer 2 Status:
TEI = 104, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
TEI = 113, Ces = 2, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
TEI 104, ces = 1, state = 5(init)
spid1 configured, spid1 sent, spid1 valid
Endpoint ID Info: epsf = 0, usid = 0, tid = 1
TEI 113, ces = 2, state = 5(init)
spid2 configured, spid2 sent, spid2 valid
Endpoint ID Info: epsf = 0, usid = 1, tid = 1

After I reset the ISDN interface, it returns to bouncing every few minutes. I called the LEC to verify that we have the correct isdn-switch type and that's when I found out that they are setup for 5ess. After changing my two sites to 5ess, the isdn doesn't work at all and stays in 'state = 1'
Also, the LEC did some loopback testing in front of the NT1 interfaces and found the line clean. The LEC seems to think it could be an issue with the NT1 card in the router.

Mind you, I have a total of 137 total remote sites, and only 2 of them are suffering from this.

Anyone have some insight?

 

[ISDNman]

What is happening at Layer 1 (NT1). If you have an external NT1 it should have status LED(s). If you have a built in NT1 there should be some way to look at Layer 1 status.

 

[voltron1011]

This is an internal NT1 on a Cisco 2621.... Here is the entire output of the 'show isdn status' command:

ydwrtr050#show isdn status
Global ISDN Switchtype = basic-ni
ISDN BRI0/0 interface
dsl 0, interface ISDN Switchtype = basic-ni
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 64, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
TEI = 73, Ces = 2, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
TEI 64, ces = 1, state = 5(init)
spid1 configured, spid1 sent, spid1 valid
Endpoint ID Info: epsf = 0, usid = 0, tid = 1
TEI 73, ces = 2, state = 5(init)
spid2 configured, spid2 sent, spid2 valid
Endpoint ID Info: epsf = 0, usid = 1, tid = 1
Layer 3 Status:
0 Active Layer 3 Call(s)
Active dsl 0 CCBs = 0
The Free Channel Mask: 0x80000003
Total Allocated ISDN CCBs = 0
ydwrtr050#

 

[ISDNman]

>>>ydwrtr050#show isdn status
Global ISDN Switchtype = basic-ni
ISDN BRI0/0 interface
dsl 0, interface ISDN Switchtype = basic-ni
Layer 1 Status:
ACTIVE
<<<

So, if you issue this command repeatedly do you see Layer 1 status vary from ACTIVE to INACTIVE or INITIALIZING?

Check it about 1/2 dozen times and if it is cycling then probably the line is bad (or there may be an NT-1 compatibility issue). In that case call it in and once you talk to a tech have him/her tell you if either of the following is true

1)Is this an EWSD switch?

2) Is this on direct copper form the CO, or is it on a loop extender/fiber/U-brite or other non-direct-copper technology?

Good luck.

 

[voltron1011]

The weird thing about this problem is that the layer-1 never goes down... I've watched it for several days now and it is always 'active.' Whenever I recycle the BRI0/0 main interface, the 2 spids will reinitialize back to "state = 8" for about 30 minutes. During that time the lines work and successful calls can be made by both BRI's. After 30 minutes, they revert back to "init = 5".

I've handed the troubleshooting over to our Remote Operations Services provider, so we'll see how many answers they can get for us.

 

[ISDNman]

I agree, odd.

A couple of things you might try

1) Swap the problem units with other sites that stay up. If the problem follows the units maybe they don't have the identical s/w version?

2) Find out what the actual switch is. Perhaps it is not a 5e, DMS, or EWSD (yes, I realize the protocol is NI-1, but each switch has it's quirks).

Many years ago I saw a situation where a certain CPE (made by us) had problem similar to what you describe only on the DMS-100. Ultimately what we found was that the DMS-100 had insufficient D-channel buffering and that messages we were sending were becoming lost. It would get pissy on us and terminate any calls and send a TEI remove command.

The problem varied from hour-to-hour and day-to-day. Presumably based on how loaded the switch was.

We put in a wait loop and that fixed the problem (the protocol was good and did not get changed) but we were going too fast for the switch (the same version of our product worked fine on the 5ESS and EWSD).

Good luck.