Framing/CRC Errors on Serial Connection

[hartleyp]

I know this sounds quite simple to troubleshoot but,

I have installed a 2620 and two 1601 routers to replace some very old routers between 3 sites (hub and spoke)

The very old routers were set to bridge and worked pretty well (small network), So basically the fractional E1 line is working without problems.

After I swapped to the new Cisco routers I find that I am experiencing framing and CRC errors. Yes, I've looked at the troubleshooting guide on cco.

To summarise, WAN ok - so can't be that, new X.21 DTE serial cables & smart serial cables - what can go wrong with them?, 1601s could both be faulty?, WIC-2T in the 2620 - how often do these things come DOA?

This job was going to last 2 hours max, turned into a nightmare!!

Thanks if you can shed any light on this situation.

[m.witte]

My experience with these errors are almost always the carrier. Is the encapsulation set for ietf? I would highly doubt all of your hardware is bad, so the common point is the carrier. They will tell you its not them and make you crazy for hours or days. If you have external CSU/DSU, you can put them in loopback and reset the interface counters and see if they increase. If they do its on your end. If not have the carrier put theirs in loopback and see if it goes up. if it does then the problem is between the carrier and your DEMARC. If not its in their hands. HTH

[m.prouty]

I just tackled two problems very similar to this problem. I had two serial E1 connections that were presenting CRCs at both ends. We tested the E1 link inbetween and it ran clean. We looped the interfaces back on themselves and they ran clean. Only when the router was connected to the ADM did we start to count CRCs. I tried to extend the cable length at one end and the CRCs decreased. I procured some inline attenuators and placed a dB3 attenuator on the far end. The CRCs reduced to 1 to 2 CRCs per hour or about 2% of the traffic. This level was still unexceptable. I tried 5 or 6 different cables of increasing length (1 meter increments) (all which tested fine on a test set) and finally I cleared the CRCs from the near end serial interface. The second issue was the same situation. We were using a 12' V.35 cable and changed from a 12' V.35 cable to a 30' V.35 cable

between the patch module and our V.35 Cisco router stub cable. The length of the V.35 cable between the patch moduel and router was an issue all 12-20'

cables continually counted CRCs but a cable of 30' ran clean.

In all instances the E1 carrier was error free when tested stand alone.

M.

[eapenten]

You may know this, but my take is that verify that you are running correct framing type, linecode, and clocking (line or internal) on both sides of your link.

Emil.

[scarothe]

Greetings:

My guess is that the lines were having errors before. I have seen several cases where customer was bridging on their old equipment, but it did not have anyway of looking at errors on the ckt and everything seemed fine (good enough). Then they put on the Cisco stuff and there they are. Is that the case?

Do some basic loop testing. Loop the CSU back to the router and do an extended ping on the local serial address. Do about 200 pings with a packet size of 2000 if 56kb and the maximum amount if a T1. If that is clean, have the telco loop the ckt at the first CO back to the router. I emphasis telco looping back toward the router. A lot of times, they will loop the router's CSU toward them. That is not what you want.

If this test is clean, the router and CSU are fine and you can tell telco to find the problem. If you want, after they loop the first CO back toward the router, have them loop the next one down the line. Usually, one of those loops will find errors.

Here is a procedure I had put together for my customers during this situation comes up so much.

Thanks...Steve

======================

To test line, do the following at enable mode:

1) "config t"

"int s 0"

"ip address x.x.x.x y.y.y.y" (Only needed if no address)

"encapsulation hdlc"

"cntr-z"

2) "show int s 0"

This will display router stats with input and output

packets.

3) Put CSU in DTE loop toward router. Use the "loopback

DTE" command.

4) "show int s0"

Should show "serial0 up, line protocol up (looped)".

If not, you are not seeing the loop and cannot go to

next step until you do.

5) "Clear counters"

Resets all counters on the "show int s 0" command.

6) Ping the local serial0 interface.

"ping"

Protocol [ip]: ""

Target IP address: IP address of local serial0

Repeat count [5]: "250"

Datagram size [100]: "2000"

Timeout in seconds [2]: "1"

Extended commands [n]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 100, 1000-byte ICMP Echos to 100.100.100.50,

timeout is 1 seconds:

You should get "!!!!!!!!!!!!!!!!!!!!!!!!!". If you get

!!!....!!.!.!..!!. or some similar pattern like this,

you have found a flakey part of the line.

7) "show int s0"

Check for CRC errors or any other type of errors at the

input/output packets portion. If no errors, ping is

good. Have another loop put up and repeat steps 4-7.

The first loop after a sucessful loop of the CSU should be put up at the first telco office closest to your site. Have them loop toward the router and you must be specific about this. Do not let them loop the CSU toward the ckt. You want to do a DTE loop back toward the router provided by the telco just as you did with your own CSU.

8) Once circuit is considered good, you will need to

recycle the router with the "reload" command and it will

come back up with the original configuration with frame

relay or you can use the "config memory" command for the

same purpose. These will only work if the changes to

HDLC have not been saved.