PRI ERROR CODES Continued

[samelbe]

The last thread lost formatting on my computer screen.
I do not have a external CSU between the smart jack and the 100DS1 card. I have many Legends/Magixs like that. The T1 is a PRI only, all voice no need for a external CSU. By the way AVAYA installed this switch years ago.
Here is the printout of the last 99 error codes.

A ERROR LOG


A Last 99 System Errors:

A Message ss/pp Cnt First Last Code
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:20:43 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:20:48 7003
A POOL BUSY &/OR OOS 00/01 - - 01/30 19:20:53 4C03
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:20:53 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:20:58 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:21:03 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:21:08 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:21:13 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:21:18 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:21:23 7003
A DS1 LOSS OF SIGNAL ALARM 05/00 - - 01/30 19:21:30 6C01
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:21:32 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:21:33 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:21:38 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:21:43 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:21:48 7003
A POOL BUSY &/OR OOS 00/01 - - 01/30 19:21:53 4C03
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:21:53 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:21:58 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:22:03 7003
A POOL BUSY &/OR OOS 00/01 - - 01/30 19:22:04 4C03
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:22:08 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:22:13 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:22:22 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:22:29 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:22:37 7003
A DS1 LOSS OF SIGNAL ALARM 05/00 - - 01/31 04:23:29 6C01
A PRI D-CHNL INOPERATIVE 05/00 - - 01/31 04:23:36 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/31 04:23:41 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/31 04:23:46 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/31 04:23:51 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/31 04:23:56 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/31 04:24:05 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/31 04:24:11 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/31 04:24:20 7003
A INVALID SANITY RESPONSE 05/00 - - 01/31 06:29:44 7804
A COMMAND BUFFER FULL 05/00 - - 01/31 06:29:44 000E
A DS1 LOSS OF SIGNAL ALARM 05/00 - - 01/31 07:08:51 6C01
A PRI D-CHNL INOPERATIVE 05/00 - - 01/31 07:09:19 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/31 07:09:28 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/31 07:09:34 7003
A INVALID SANITY RESPONSE 05/00 - - 01/31 09:36:27 7804
A COMMAND BUFFER FULL 05/00 - - 01/31 09:36:27 000E
A INVALID SANITY RESPONSE 05/00 - - 01/31 10:02:36 7804
A COMMAND BUFFER FULL 05/00 - - 01/31 10:02:36 000E
A INVALID SANITY RESPONSE 05/00 - - 01/31 10:14:52 7804
A COMMAND BUFFER FULL 05/00 - - 01/31 10:14:52 000E
A INVALID SANITY RESPONSE 05/00 - - 01/31 11:07:41 7804
A COMMAND BUFFER FULL 05/00 - - 01/31 11:07:41 000E
A INVALID SANITY RESPONSE 05/00 - - 01/31 11:34:22 7804
A COMMAND BUFFER FULL 05/00 - - 01/31 11:34:22 000E
A INVALID SANITY RESPONSE 05/00 - - 01/31 12:35:11 7804
A ERROR LOG


A COMMAND BUFFER FULL 05/00 - - 01/31 12:35:11 000E
A INVALID SANITY RESPONSE 05/00 - - 01/31 12:44:47 7804
A COMMAND BUFFER FULL 05/00 - - 01/31 12:44:47 000E
A INVALID SANITY RESPONSE 05/00 - - 01/31 12:47:59 7804
A COMMAND BUFFER FULL 05/00 - - 01/31 12:47:59 000E
A INVALID SANITY RESPONSE 05/00 - - 01/31 13:04:31 7804
A COMMAND BUFFER FULL 05/00 - - 01/31 13:04:31 000E
A INVALID SANITY RESPONSE 05/00 - - 01/31 13:54:40 7804
A COMMAND BUFFER FULL 05/00 - - 01/31 13:54:40 000E
A INVALID SANITY RESPONSE 05/00 - - 01/31 15:22:43 7804
A COMMAND BUFFER FULL 05/00 - - 01/31 15:22:43 000E
A INVALID SANITY RESPONSE 05/00 - - 01/31 15:36:03 7804
A COMMAND BUFFER FULL 05/00 - - 01/31 15:36:03 000E
A INVALID SANITY RESPONSE 05/00 - - 01/31 15:55:48 7804
A COMMAND BUFFER FULL 05/00 - - 01/31 15:55:48 000E
A POOL BUSY &/OR OOS 00/01 - - 01/30 19:18:50 4C03
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:18:53 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:18:58 7003
A POOL BUSY &/OR OOS 00/01 - - 01/30 19:19:00 4C03
A PRI B-CHNL NOT RELEASED 05/23 - - 01/30 19:19:01 7004
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:19:03 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:19:08 7003
A POOL BUSY &/OR OOS 00/01 - - 01/30 19:19:10 4C03
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:19:13 7003
A POOL BUSY &/OR OOS 00/01 - - 01/30 19:19:14 4C03
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:19:18 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:19:23 7003
A POOL BUSY &/OR OOS 00/01 - - 01/30 19:19:24 4C03
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:19:28 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:19:33 7003
A POOL BUSY &/OR OOS 00/01 - - 01/30 19:19:36 4C03
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:19:38 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:19:43 7003
A POOL BUSY &/OR OOS 00/01 - - 01/30 19:19:45 4C03
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:19:48 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:19:53 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:19:58 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:20:03 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:20:12 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:20:19 7003
A DS1 LOSS OF SIGNAL ALARM 05/00 - - 01/30 19:20:22 6C01
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:20:23 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:20:28 7003
A POOL BUSY &/OR OOS 00/01 - - 01/30 19:20:31 4C03
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:20:33 7003
A PRI D-CHNL INOPERATIVE 05/00 - - 01/30 19:20:38 7003
A POOL BUSY &/OR OOS 00/01 - - 01/30 19:20:42 4C03

A Permanent Errors:

A Message ss/pp Cnt First Last Code

A Transient Errors:

A Message ss/pp Cnt First Last Code
A ERROR LOG


A INVALID SANITY RESPONSE 05/00 041 01/28 21:21:43 01/31 15:55:48 7804
A COMMAND BUFFER FULL 05/00 041 01/28 21:21:43 01/31 15:55:48 000E
A POOL BUSY &/OR OOS 00/01 021 01/28 23:30:15 01/30 19:22:04 4C03
A DS1 MISFRAME ALARM 05/00 001 01/30 13:45:24 01/30 13:45:24 6C09


Again, any help will be appreciated greatly.

 

[dagwoodsystems]

I sent an email to the Tecumseh group regarding the sudden FUBAR formatting of that last thread, but did not receive a response. I'm glad you began a new post.

/lecture begin

Yes, yes, yes...you can run without a CSU, but it's not at all recommended. A CSU provides network protection and a far better means of diagnosing circuit problems that what Avaya has built into their software. The DSU portion has built-in buffers and is responsible for ironing out any issues with signal timing. Anyway, you should probably check your thinking about not needing a proper piece of terminating hardware simply because this is a "pure voice" circuit.

/lecture end


"PRI D-CHNL INOPERATIVE" can be caused by a number of things. It is due either due to imperfect protocol emulation or--more likely--physical layer errors. The timing slips and misaligned frames that you previously mentioned especially suggest the latter. If your programming is set for loop timing and the framing/line coding set for B8ZS/ESF, then you can almost be sure of it. Have the carrier do a "quasi" stress test on the circuit rather than simple pattern tests. If they want to do basic loopback testing first, be sure that you're in a place to observe the lights on the NID. Carrier techs will sometimes accidentally loop up a repeater instead of the smartjack, so you want to see evidence that they're talking to the right gear.

The "DS1 LOSS OF SIGNAL ALARM" again stresses a physical layer problem on the carrier's part. You can change the patch cord between your DS1 blade and the NID, but I suspect that's not the issue (otherwise we would have seen a Blue alarm in the history).

The "POOL BUSY &/OR OOS" is straightforward. The second set of digits indicates the pool affected. In this case "00/01" means pool #1. I guess you've got your PRI trunks in pool 70. The sanity and buffer errors are probably due to a heavy processor tax while it continuously attempts to resurrect the troubled circuit.

I've been fighting a similar problem at a local doctor's office for the last two days. The carrier in question is MPower/Telepacific, who has been adamant about the circuit's worthiness despite the heavy framing error count that I'm seeing.

Tim Alberstein

http://www.dagwoodsystems.com

 

[dagwoodsystems]

While we haven't heard from samelbe in a while, I'm wondering if Jim doesn't have a bit or two to share about what's been discovered so far. SYQUEST is a smart cookie when it comes to this stuff (sorry about putting you on the spot, bro).

Still hoping to hear from samelbe as soon as information is available!

Tim Alberstein

http://www.dagwoodsystems.com

 

[samelbe]

Last night (Friday) the carrier's technician came out and again they stated that their circuit looked good and that they saw errors coming from the switch. I tested the board controller and internal loopback test and all passed OK. The carrier changed the slot in the smartjack and the smartcard and swapped out a repeater card at their hut (fiber to copper hut, I don't know what card. Since it takes a while for the errors to build and the circuit to drop out of service (only once Friday morning at 6:23AM) Anyway, I had to replace a 008MLX card and since I powered down the switch to do that I changed out the 100DS1 card as well. After a powerup and board renumber, I checked the error events after a hour and they were LOOKING GOOD. MILLER TIME!

This will always be a mystery to me but you can only put a customer through so much pain before it becomes fatal to the carrier and the phoneman. I want to thank everyone and someday I hope I can be as helpful and knowledgeable as you gentleman

 

[SYQUEST]

Hi all,

Here is my 2 cents. I'm glad samelbe got the service restored and working again. Sometimes your last resort is to shotgun the thing. In this case it appears to be working. My gut feeling is the DS1 facility was at fault somewhere. Not knowing what kind of design the ckt is using from the "hut" location to the premise. If it was an HDSL or "real DS1" type, it could be the repeater or the NIU modules were glitched, and the only way to clear them would be to replace them or power cycle them. I have had experience with trickle errors before. They can be very difficult to find sometimes.

In the past I had a DS1 that kept crashing every time channel 24 was in use. This DS1 terminated on a channel bank in the Paramount CO. It had a mix of ckts on it, DID trunks and 3002 data ckts. It drove Pacific Bell nuts trying to figure the problem out. Well to make the story short, the cause was the LIU (Line Interface Unit) in the CB at the CO was optioned wrong. The Line Code was suppose to be B8ZS, and the craft person kept setting it to AMI! The LIU in the CO could not handle the BPVs, especially when channel 24 was in use. So it would go into CGA.

....JIM....

 

[samelbe]

With a couple of days behinh this event the T1 is still up and hasn't taken a dump. But when I check the error log I see a 6C09 error and checking the slot I is a MaxAlm BLUE and between 061 and 052 MIS's. I think a few of these MIS is OK, but not sure. One thing for sure - What I don't know about T1's will fill the oceans and what I do know will fill a eyedropper.

 

[dagwoodsystems]

MIS is a misframe. Eighteen misframes have occurred for each instance that an MIS or 6C09 error is reported. I personally don't find those counts acceptable for two or three days of exercise. The blue alarm--briefly as it may have been--indicates a total lack of incoming signal.

The first bit of each of the 24 frames, or timeslots, is used for synchronization. Pre-established patterns of these synch bits also serve as an error checker. Expected pattern seen = data must be good; bad pattern = the frame is misaligned (we don't know where the frame truly begins and ends). You've changed out your equipment, so now I'm left to believe that this is a physical layer problem, an intermittent repeater or (as SYQUEST pointed out) a piece of upstream hardware that is optioned incorrectly.

Clear you errors and keep an eye on it.

Tim Alberstein

http://www.dagwoodsystems.com

 

[dagwoodsystems]

Jim, are there REALLY people out there still using those old unconditioned analog circuits? I used to order a 3002 as a poor-man's 19.2 data circuit and slap serial muxes on either end. Back in the day...

Tim Alberstein

http://www.dagwoodsystems.com

 

[SYQUEST]

Well Tim, back in the day when I worked at the paging company, we used 3002s and "end links" that rode DS1 or microwave channels to various locations where we had radio transmitters. We had an extensive wireline network for our transmitter control. Alot of this was setup before everyone else went to satellite (and you know what happened when GE's bird died!). To reduce costs, I would use DS1s to various end offices for DID trunks and other ckts. Not much call for analogue data anymore...

samelbe,
I would keep an eye on those alarm errors and make sure your wiring is rock solid! Wiggle the patch cord in the jacks and
make sure nothing happens when you do. I agree with Tim, too many errors for that time frame. Just for your own peace of mind, examine the Telco wiring from the NIU to the protector and see if it looks "OK". In the past I have had to "fix" Telco's bad jumpers.

....JIM....