A-Train

One of my sites had a weird T1 outage this afternoon that magically fixed itself. As with many such outages I doubt I will get any real information as to the cause of the problem. The outage occured on a vanilla (non-PRI) long distance T1. When I ran a status on the trunk group it showed all channels as out-of-service. I ran a long test on the trunk here are the result for each channel:

Test 136 - Abort 1020
Test 36 - Abort 1006
Test 6 - Pass
Test 7 - Pass

I busied out and released the trunk. After it went through its test phase (where it looks like it is working, but is just being tested), it went back to the same status.

I opened tickets with my Avaya BP and my LD Carrier. Before either vendor had a chance to do much of anything the circuit came back in service. I doubt I will ever get a good answer on this issue, but I would love to hear what people here think. I am especially interested in what those codes mean. I have searched the various PDFs for details, but they haven't really told me much. If you have any thoughts I would love to hear them.

martinyoung

If an entire T1 is down a better test is "test board <DS1 board>". You are interested in tests 138-146. You can cancel after 146 because the rest of the tests are the individual channels. Those tests are -

138 - loss of signal
139 - blue alarm
140 - red alarm
141 - yellow alarm
142 - excessive bit error
143 - bit errors, but not as much as the previous test
144 - slips
145 - out of frame
146 - translations

If test 144 fails, test again because that is a slip counter that counts slips since the last time you ran this test. This is an historical counter, if it does not pass now then you are slipping right now.

__________________
Marty
Retired Avaya DSIC tech

PBXtech.info

 

oozenoz

As an ex-telco specials technician, there are a lot of reasons a T1 circuit could be brought down for a short time. Some have to do with hardware or cabling on the verge of failing, others have to do with simple human error. Keep an eye on it; if it doesn't fail again in the next few weeks or months, don't worry about it. If it does, call your telco and open a ticket.

__________________
- calvin

A-Train

Well the problem came back again. I couldn't test on the DS-1 because of the vintage of board, so I tested the board. It failed a test 141 (yellow alarm). I had my BP test it too. The tech there said that it looks like a provider side issue. I have gone back and reopened the ticket with the LD carrier. Thanks for the details on the tests. I have saved that off to a document for future reference. It is very handy to have.

oozenoz

Yellow alarm means loss of receive on the far side. The alarm coding is embedded in the transmitted signal, so you were obviously still seeing something on your receive. If you weren't getting anything at all, your card would be in Red alarm. That being said, it could still be your problem - a bad CSU or cabling between the CSU and demarc could cause this.

Is the circuit fibre all the way to the building, or is it copper on the local loop?

__________________
- calvin

martinyoung

I have never seen a yellow alarm to be an onprem problem. A yellow has always been from the NIU out.

I agree with your BP, it is a vendor issue.

__________________
Marty
Retired Avaya DSIC tech

PBXtech.info

 

oozenoz

I have... bent pins on a CSU that were causing a high open joint. It would work for a while, then the link would go down. Fought that bad boy for months...

__________________
- calvin

martinyoung

Interesting. I will add that to the toolbox. Thanks.

Can't be too common a problem though, I have not run across it in nearly 40 years. If you did a hard loop back at the demarc would you still get a yellow or would it then become red?

__________________
Marty
Retired Avaya DSIC tech

oozenoz

I've only seen it that one time myself. Just shows you can't take anything for granted.

I don't know for certain if they ever looped back toward the PBX; I think the vendor's tech was convinced it had to be a telco problem. He had already put in a ticket with telco, who played it by the numbers and looped the smartjack, which tested ok, then they put the circuit normal again and looped the CSU and that tested okay... the bent pins were on the connection between the PBX and the CSU, on the PBX transmit side.

__________________
- calvin

martinyoung

Goes to show that you learn something new every day. Though not looping back to the PBX is an error in testing. If they had done that while it was broken they would have seen local trouble from the get go.

Always check local before involving anyone else.

__________________
Marty
Retired Avaya DSIC tech

oozenoz

You would hope. Then again, this circuit would work for a while, sometimes days before it would drop out of service. So looping the PBX back toward itself from the network side of the CSU, it could have actually looked okay for a short time, possibly long enough to give a false sense of everything being okay.

Absolutely! And always perform a visual inspection!

__________________
- calvin

marilynnanne

An Avaya loopback device (we call them cigars) would have been handy (placed at the DMARC). You send the command to loop it up, then, clear measurements, then list measurements just like you were doing a regular T1 test from the PBX. The interesting part about using these loopback devices is that if the T1 is bad "beyond", the loop won't come down gracefully. So, you have to force it down. But, it's a good indicator.

Also, I have found that list measurement summary (instead of log) is helpful when testing a T1. You just repeat the summary, and, if you have slips or errors, you can see them right away. I have heard people say that they have to wait 15 minutes to see if the "trouble has cleared" when, really, list measurement summary would have told them right away.

oozenoz

Interesting approach - I'll add that to my bag of tricks. Thanks for the tip.

__________________
- calvin