PRI T1 line code violations

Unanswered Question
Jun 6th, 2009

The only errors that I get on the T1 controller are these numerous line code violations, and on the corresponding serial0/0/0:23 I get a lot of input CRC errors. No output errors.

The configuration is pretty generic: primary-ni switch type, B8ZS and ESF. Clocking for the single T1 is the line.

I've already replaced the cables and VWIC. The telco states loopback tests clean to the CSU/DSU. Below is the show controller output:

T1 0/0/0 is up.

Applique type is Channelized T1

Cablelength is long gain36 0db

No alarms detected.

alarm-trigger is not set

Soaking time: 3, Clearance time: 10

AIS State:Clear LOS State:Clear LOF State:Clear

Version info Firmware: 20051006, FPGA: 20, spm_count = 0

Framing is ESF, Line Code is B8ZS, Clock Source is Line.

CRC Threshold is 320. Reported from firmware is 320.

Data in current interval (666 seconds elapsed):

0 Line Code Violations, 322 Path Code Violations

0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 11 Degraded Mins

265 Errored Secs, 33 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

I would appreciate any direction for my next steps. Thanks!

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
PETER NEGUS Sat, 06/06/2009 - 10:03

I notice that your cablelength is set to long. If it is a long cable, then you may have grounding issues, which you can test by moving the router next to the DSU. If it is a short cable, you may have too much juice on the interface - try cablelength long 6 to take 6db off the signal strength and progressively reduce, or use the short keyword

Nicholas Matthews Sat, 06/06/2009 - 13:50

I've seen this when the signal from the provider is coming in too 'hot'. You may want to call them up and see how far your router is from the CO.

You can try a T1 loopback plug to see if the problem continues to happen when the providers equipment isn't involved if you can take the T1 down.

More info here:



Darren Strunk Sat, 06/06/2009 - 14:05

Thanks guys. I did the software loopback test and it came up clean. On Monday I will have a local tech there with a hardware T1 loopback to finish up testing. I was wondering about the cablelength command, but I have no experience setting it. I will play around with your suggestions.

I did have the router moved closer to the drop-off point within the building. Not sure how far that is from the CO.

Paolo Bevilacqua Sun, 06/07/2009 - 02:54


Do you have configured ?

network-clock-participate wic 0

network-clock-select 1 t1 0/0/0

Paolo Bevilacqua Sun, 06/07/2009 - 09:43

Sorry to be insisting, you need the two commands above verbatim. Your answer does not confirm that explicitly.

Nicholas Matthews Sun, 06/07/2009 - 09:52

From what I know, and correct me if you've seen differently, the network-clock commands only apply to timing. Errored seconds, slip seconds, etc.

The path code violations, from I've seen at least, are almost always some other external problem.


Paolo Bevilacqua Sun, 06/07/2009 - 10:02

Nick, you're correct.

At the same time, we always want to start troubleshooting from a 100% correct configuration.

Darren Strunk Sun, 06/07/2009 - 15:30

Yes, those commands are in place.

Right now this is on hold until we have a local tech there Monday morning. I will be sure to update what we find.

Darren Strunk Thu, 06/11/2009 - 09:15

Got a telco tech on site and he discovered that their switch had the line coding set wrong. The cut sheet said B8ZS but they had it set to something else. Our side was correct.

Got everything working now - thanks for the input guys.


This Discussion