(usr-tc) Code Violation Errors
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? TIA, Jim - 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.
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.
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.
Also sprach Jim Johnson
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.
No. Keep in mind that AMI and B8ZS serve to maintain 1's density on the circuit. If the data that's flowing over the circuit would maintain 1's density without any of the line coding "tricks" that AMI and B8ZS uses, then those mechanisms don't get triggered, the data is basically sent over raw, and no line code violations would be seens. The only time that you would see line code violations would be when there would be a timeslot on the T1 that is all 0's, then one of the mechanisms (either basic AMI, or B8ZS) would kick in, and possibly mangle one or the other as they conflict. There is an idle pattern that T1's use on channels that aren't in use (I don't know the pattern off the top of my head, but I do know that its not all 0's), so if the circuit is completely idle, it shouldn't trigger line code problems. u-law voice encoding, and v.90 pcm encoding don't ever generate all 0's either (if I remember correctly), so the only time you should ever see all 0's is when you're dealing with ISDN data calls (and then it may only be when they are running at 64kbps). Now then...I'm definitely *not* a telco engineer, so take everything I'm saying here with a grain of salt...I'm sure inaccuracies could be found. :) -- 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.
participants (2)
-
Jeff Mcadams -
Jim Johnson