nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

CRC Errors

thenjduke

Okay we have a problem with one of our sites. We are getting high CRC errors on our secondary connection to main hq. I was wondering what is too high of CRC errors on T1 between serial interfaces.

Find more posts tagged with

SAVE $250 on Your CISCO Boot Camp — Use Code "EXAM26"

Exclusively for TechExams members for Infosec Boot Camps starting before April 30, 2026

View CISCO Boot Camps

Comments

jason_lunde

What line code are you all using? Most CRC errors usually come from clocking problems, so check you settings on both ends. As far as how many are too much, I cant say for certain, but anytime CRC errors start showing up I give them some attention.

Stotic

Check the cabling and contact your carrier.

kryolla

Stotic wrote: »

Check the cabling and contact your carrier.

+1 check your dmarc

thenjduke

We have check cables and did loopback test. I have a call to the ISP. This has been happening for the last two weeks. They are doing construction on the building and last time I look at the cables for T1 they were just sitting against the expose to the elements. It is not a timing issue between the routers because this site has been up and running for three years and no one has touch anything. It has to be a ISP issue but they keep telling me that everything looks clean.

thenjduke

Here is show controller T1 and I will do the interfaces.
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: 20050620, FPGA: 16, 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 (831 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Total Data (last 24 hours)
76526 Line Code Violations, 6363 Path Code Violations,
2 Slip Secs, 0 Fr Loss Secs, 3 Line Err Secs, 1 Degraded Mins,
3 Errored Secs, 0 Bursty Err Secs, 5 Severely Err Secs, 133 Unavail Secs
T1 0/0/1 is down.
Applique type is Channelized T1
Cablelength is long gain36 0db
Transmitter is sending remote alarm.
Receiver has loss of signal.
alarm-trigger is not set
Soaking time: 3, Clearance time: 10
AIS State:Clear LOS State:Clear LOF State:Clear
Version info Firmware: 20050620, FPGA: 16, 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 (834 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 834 Unavail Secs
Total Data (last 24 hours)
0 Line Code Violations, 0 Path Code Violations,
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 86400 Unavail Secs
T1 0/1/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: 20050620, FPGA: 16, 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 (838 seconds elapsed):
0 Line Code Violations, 91563 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 13 Degraded Mins
648 Errored Secs, 632 Bursty Err Secs, 21 Severely Err Secs, 0 Unavail Secs
Total Data (last 24 hours)
91654 Line Code Violations, 78088 Path Code Violations,
3 Slip Secs, 0 Fr Loss Secs, 2 Line Err Secs, 611 Degraded Mins,
7388 Errored Secs, 2194 Bursty Err Secs, 22 Severely Err Secs, 139 Unavail Secs

thenjduke

Here is the interface in question.
Serial0/1/0:0 is up, line protocol is down
Hardware is GT96K Serial
Internet address is 10.12.254.106/30
MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, loopback not set
Keepalive set (10 sec)
CRC checking enabled
Last input 00:13:20, output 00:00:04, output hang never
Last clearing of "show interface" counters 1d01h
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 124
Queueing strategy: Class-based queueing
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/38/256 (active/max active/max total)
Reserved Conversations 1/1 (allocated/max allocated)
Available Bandwidth 432 kilobits/sec
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
2842640 packets input, 717900821 bytes, 0 no buffer
Received 10409 broadcasts, 0 runts, 1 giants, 0 throttles
112408 input errors, 112405 CRC, 3866 frame, 523 overrun, 0 ignored, 3795 abort
1142554 packets output, 211118116 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 output buffer failures, 0 output buffers swapped out
6 carrier transitions
Timeslot(s) Used:1-24, SCC: 0, Transmitter delay is 0 flags

thenjduke

We have it down right now because that path is not letting people connect. We have our primary up right now.

thenjduke

I hate that this is happening but this is giving me exposure to diagnosing real live equipment just in time for CCNA exam soon.

kryolla

go to the dmarc and put a loop facing you and isp and see who is still getting errors and that will tell you where the problem is at.

jason_lunde

kryolla wrote: »

go to the dmarc and put a loop facing you and isp and see who is still getting errors and that will tell you where the problem is at.

good idea

networker050184

kryolla wrote: »

go to the dmarc and put a loop facing you and isp and see who is still getting errors and that will tell you where the problem is at.

Thats pretty much what the ISP would do. They will loop it from the demarc and test. If it tests clean its your problem not theirs.

Stotic

Like others are saying, if the loopback tests fine from the smartjack to your router then the issue is probably on the carrier side and they should have you loop back to them to test.

thenjduke

Loopback is fine no errors. I figure it was ISP.