Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations wOOdy-Soft on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Loopback for a TN767E DS1 (PRI)

Status
Not open for further replies.

TMiyake

IS-IT--Management
Feb 6, 2002
69
US
I’m helping a friend with their PBX. He has a Definity G3 R8. They are having line problems with their PRI’s. They have 3 TN767E and 1 TN767F cards. They are having errors on their lines. Here’s the “li meas ds1 sum CARD” for all of them:

Worst 15-Minute Interval 24-Hour Current
Category Date Time Count Count Interval Count

Errored Seconds 04/16 10:53 20 192 0
Bursty Errored Seconds 04/15 13:08 0 0 0
Severely Errored Seconds 04/16 07:23 1 1 0
Unavailable/Failed Seconds 04/16 07:23 2 2 0
Controlled Slip Seconds 04/16 10:53 20 189 0
Loss Of Frame Count 04/15 13:08 0 0 0

They have the carrier doing intrusive testing, but they’re saying everything is fine. They want to setup a loopback on the line, but I’ve never done it with a separate CSU (we use the TN464 cards with the integrated CSU). They can’t really do anything themselves until they talk with their Avaya sales rep because they have very limited maintenance access with their login right now. Does anyone know how you would configure the loopback for this kind of a system though?


Thanks in advance,

Tom
 
Easy answer is to put in a hard loop and test with that. Your telco should see the circuit run clean with the loop in, and generate errors with the loop out. Get a rj45 jack a crimper and a couple of inches of cross connect wire. Loop pin 1 to pin 4 and pin 2 to pin 5. Here is a link from Cisco on how to build the plug.
 
Have him do a status sync on the switch and find out what the sync source is. Is he pulling sync from one of the public network T1s?
 
Thanks dsldefinity. I'm having him make the cable now so he can test it out. I totally forgot about doing loopbacks like that.

Sched99, I’ve never ran the stat sync before, so I’m not sure exactly where is says you’re syncing from. Here’s the information from the command:

status synchronization
SYNCHRONIZATION STATUS

Stratum Level: 4
Maintenance Name: UDS1-BD Physical Location: 01A03
Switching Capability: Enabled
Excessive Reference Switching: No


Thanks,

Tom
 
That means your entire switch is clocking itself off the pipe in A03. Is that the circuit you are having a prob with? Is that supposed to be your sync source? Is that a long distance T1? Do a list meas ds1 log 01a03 to see if that is clean. If not that could be your prob. You really need to check each board and pay attention to your sync source to nail problems like this down. Are they dropping calls or just hearing popping? Is faxing affected? What is their complaint?
Errors on T1's are common (except the unavailable seconds is of concern).
 
01A03 is the first PRI in the group. All 4 PRI’s are receiving the same errors. The PRI’s are both long distance and local. They go through a company called Focal (Bay area, CA) that can handle both. The log’s are consistent across all 4 PRI’s (the same amount of errors at every 15 minute increment).
They haven’t said anything about faxing to me. The problem is they are getting a lot of dropped calls. I just talked with him and they carrier is sending out a PacBell technician to do additional testing on all of the lines.
 
Are all T1's using the same D channel for signaling?

What flavor csu's are you using?
 
What is the vintage of the 767E's
There is a QPPCN 956R conserning problems with some.
There is also 1359B, which concerns 120A3 ICSUs, Which you might also have.
 
If you are having the same exact errors across all 4 T1s, make sure Focal is aware of this. It is possible that all 4 are coming off the same switch on the Focal's side and there may be a problem on that switch.
 
I want to thank everyone for their help in resolving this issue.
The problem ended up being the first PRI. There were errors with that line, and since all of the other PRI’s were getting their timing from that one, it was causing errors across all of them. Once the first PRI was fixed, all of the other lines stopped receiving errors.

Thank you,

Tom
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top