Thanks. I guess I should request that a telco tech go out with a T-BERD and check the lines for us to resolve this. I am curious though, if there were a piece of equipment set for AMI coding in the circuit, wouldn't that inject either a near constant amount of errors and wouldn't it be a very large number of these Path Code Violations within a 15 min period? I am seeing 15 minute intervals with no errors, some with 2 or 3 and then a few with 60 or 70 errors within the interval. Jim Jeff Mcadams wrote:
Also sprach Jim Johnson
Recently, in preparation for a telco switchover, we have been testing a new phone company and currently we have three PRIs up.
About a week ago, we start getting numerous reports of disconnect problems, so I started looking at this problem and I am a bit frustrated.
Of course, the phone company monitored the circuits and declared everything fine on their end.
The only thing that I am seeing is a small number (0 to 100) of Code Violation errors in each 15 minute interval when I look at the Near End Current Intervals.
From looking at the stats, these errors initially were only showing up on the third PRI, so we went and powered down the chassis and moved the circuits around to make sure it wasn't the equipment.
However, today I am seeing these errors on all the PRI's.
What would cause these errors and what should I look at from here?
Line Coding generally refers to AMI and/or B8ZS. You might have your equipment set up for B8ZS and some piece of equipment in the transport between you and their switch (or the switch itself) might be set for AMI...it only takes one piece of equipment being set wrong to cause these.
The best way to test this is to run an all-0's pattern over a loopback'ed line.
AMI and B8ZS are intended to maintain 1's density on a T1, so running all-0's over it will cause the coding mechanisms in AMI and B8ZS to be used very frequently. If a piece of equipment in the transmission path is set to AMI when it should be B8ZS, you'll see line coding errors rack up quickly.
This all assumes, of course, that you have some piece of equipment capable of running Bit Error Rate Testing (BERT). The DSPs do have some limited capabilities in this area themselves, but they're not the easiest thing to work with.
If you've got a cisco t1 card (with integrated csu/dsu), they can often do BERT...as can some stand-alone CSU/DSU's. Of course, if you have access to a T-berd, then you've got it made in the shade. :)
I use a port on our PA-MC-8T1 to do BERT when I need it, FWIW.
If this isn't your problem...well...I might be able to come up with other explanations, but not off the top of my head. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.