CRC Errors on link While accesing Application

Unanswered Question
Apr 16th, 2008

We have DC and DR site, And NAP locations. Each nap has 2 routers which are having 2 Fastethernets connectivity is as per attached diagram.

At one Nap location we are having application server which is accessed by all other naps through Internet explorer.

Now for perticular one Nap application wont work if traffic flows on NAP to DC link while on other Naps it works .

But if we shut the NAP to DC link application works properly on DR link. (i.e for perticular NAP if traffic flows on DC link application won't work for the same NAP it works if traffic flow on DR link)

So we have to keep DC link shut for application to work.

We observed that if we bring up DC link and try to access the application it generates CRC errors an input erros on link

on NAP side.

(If this perticular application is accessed and if the DR link is shut application won't open and it generates

the CRC errors and input errors But if DC link is shut on dr link it works properly )

At DC and DR side we are having STM and on NAP side we are having Chanalized Even having 2 Mbps connectivity.

pl Help us What could be the problem ?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
hadbou Tue, 04/22/2008 - 06:26

CRC errors are caused by one of the following reasons and you can check for these issues on youe setup.

1) Duplex Mismatch: When we have an interface that has a duplex mismatch it will generate

CRC errors, having combinations like Full---Half, Auto---Full, Auto---Half could increase

the CRC counter to increase, and the way to solve this problem is having the same duplex

on both ends.

2) Bad Cable: When a cable goes bad or we have something interrupting the signal we can

experience CRC errors, the solution for this is clear, just change the cables and remove

any device/machine that could be affecting the signal.

lamav Wed, 04/23/2008 - 09:03


You also have framing errors and carrier transitions, not just CRCs.

From Cisco:

Carrier Transitions

Carrier transitions appear in the output of the show interfaces serial command whenever there is an interruption in the carrier signal, such as an interface reset at the remote end of a link.

Symptom Increasing carrier transitions count on serial link

Possible Cause The following problems can result in this symptom:

Line interruptions by an external source, such as physical separation of cabling, T1 alarms, or lightning striking somewhere along the network

Faulty switch, DSU, ASI, or MRP hardware

Action The following steps are suggested when you encounter this symptom:


Step 1 Check hardware at both ends of the link by attaching a breakout box or a serial analyzer and testing to determine source of problems.

Step 2 If an analyzer or breakout box does not identify any external problems, check the ASI or MRP hardware.

Step 3 Swap faulty equipment as necessary.

From me:

Have telco test the line end-to-end (head-to-head, if possible) and run stressful data patterns



pushpak.lele Wed, 04/23/2008 - 09:12


thanks i will certainly try out tests.

But could this problem is with specfic data traffic ?

what data patterns can i try ?

or is there is another way to find out application data pattern ?

lamav Wed, 04/23/2008 - 10:26


Here goes...

To test a T1 line, these are typically the tests that are run:

QRSS (quasi) -- random bit pattern meant to simulate real data traffic.

1:7 (sometimes called 1:8) -- stressful pattern meant to test line integrity by maximizing number of zero bits (minimum ones density), without forcing binary eight zero suppression coding.

3:24 -- similar to 1:7 but a bit more stressful.

All Ones -- meant to test riser repeaters by forcing a reproduction of every bit.

All Zeroes -- meant to test for B8ZS configuration.

These are about the only test you will ever need to run. If possible, have the LEC dispatch 2 techs and have them run head to head.

This is most likely a line/hardware issue, not an application issue.




This Discussion