Core Issue
Cyclic Redundancy Check (CRC) errors occur when the CRC calculation does not pass. This indicates that data is corrupted. This issue occurs for one of these reasons:
- The serial line is noisy.
- The serial cable is too long or the cable from the CSU and Data Service Unit (DSU) to the router is not shielded.
- The CSU line clock is configured incorrectly.
- A ones density problem has occurred on the T1 link. This occurs from an incorrect framing or coding specification.
Resolution
The CRC errors and carrier transitions can be seen in the output of the show interfaces command, as shown in this example:
fmf-access#show interface s0:23
Serial0:23 is up, line protocol is up (spoofing)
Hardware is DSX1
Interface is unnumbered. Using address of Loopback0 (172.29.19.5)
MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, loopback not set
Last input 00:00:22, output 00:00:22, output hang never
Last clearing of "show interface" counters 16:01:33
Queueing strategy: fifo
Received 0 broadcasts, 5151 runts, 0 giants, 0 throttles
11476 input errors, 18
CRC, 5660 frame, 0 overrun, 0 ignored, 647 abort
!-- This is pertinent.
2218 packets output, 10120 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
16 carrier transitions
!-- This is pertinent.
Timeslot(s) Used:24, Transmitter delay is 0 flags
To address the CRC errors, perform these steps:
- Ensure that the line is clean enough for transmission requirements. Shield the cable, if necessary.
- Make sure that the cable is within the recommended length (no more than 50 feet [15.24 meters] or 25 feet [7.62 meters] for a T1 link).
- Make sure that the local and remote CSU and DSUs are configured for the same framing and coding scheme as that used by the leased-line or other carrier service. One example is the Extended Superframe (ESF) and Binary 8-Zero Substitution (B8ZS).
- If there is a problem with the framing and line coding configuration, then path or line code violations will be present in the output of the show controllers t1 command, as shown in this example:
mf-access#show controller t1 0
T1 0 is up.
No alarms detected.
Version info of slot 0: HW: 2, Firmware: 16, NEAT PLD: 14, NR Bus PLD: 22
Framing is ESF, Line Code is B8ZS, Clock Source is Internal.
Data in current interval (850 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
Voice Quality
Crackling (Listen to short or long crackling samples.)