CRC Error and input Error how can fix these

[mkumailali]

FastEthernet0/13 is up, line protocol is up
  Hardware is Fast Ethernet, address is 0004.4d27.66cd (bia 0004.4d27.66cd)
  Description: EDL-P-Box-NO-4
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
     reliability 250/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive not set
  Auto-duplex (Full), Auto Speed (100), 100BaseTX/FX
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 18:52:43, output 00:00:01, output hang never
  Last clearing of "show interface" counters never
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 12000 bits/sec, 6 packets/sec
  5 minute output rate 24000 bits/sec, 6 packets/sec
     14488019 packets input, 2783320210 bytes
     Received 345346 broadcasts, 0 runts, 0 giants, 0 throttles
     261028 input errors, 259429 CRC, 1599 frame, 0 overrun, 0 ignored
     0 watchdog, 84207 multicast
     0 input packets with dribble condition detected
     19658279 packets output, 3529106068 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out
PAD-8-1-10.179#cle
v

[nkarthikeyan]

This is purely a physical issue...... either a cable issue or the media connected to it or a duplex problem...... verify all the above and check....

[Leo Laohoo]

 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
   reliability 250/255, txload 1/255, rxload 1/255

Don't know why I didn't see this.

It's a cabling issue.

[Jose Solano]

Hi,

Check this:

1. Check the speed/duplex both the ends

2. Check the cable
3. Check by changing the speed and duplexto half or Auto
4. Chek if the grounding is proper

Regards,

[JRDIAZ758]

Not necessarily, i encountered this problem with a barracuda web filter in inline mode (bump in the wire). it happened from time to time when the web filter rebooted. 

i dont know the exact cause but it was not L1, i think it was the link layer negotiation (speed, duplex settings) . 

i managed to fix it by shutting down the interface of the switch then back on, to force a renegotiation.l

PC-----f0/1 SW (c2960) f0/2---- lan Barracuda  wan ----  f0/0  c2821 internet router

|-------- ------------          same Bcast domain     ----------------|

------------- INTERFACE CONNECTED TO LAN OF cuda

show int f0/2

FastEthernet0/2 is up, line protocol is up (connected)

  Hardware is Fast Ethernet, address is e804.627a.9403 (bia e804.627a.9403)

  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

     reliability 236/255, txload 1/255, rxload 1/255

  Encapsulation ARPA, loopback not set

  Keepalive set (10 sec)

  Full-duplex, 100Mb/s, media type is 10/100BaseTX

  input flow-control is off, output flow-control is unsupported

  ARP type: ARPA, ARP Timeout 04:00:00

  Last input 00:00:32, output 00:00:00, output hang never

  Last clearing of "show interface" counters 00:07:41

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

  Queueing strategy: fifo

  Output queue: 0/40 (size/max)

  5 minute input rate 9000 bits/sec, 16 packets/sec

  5 minute output rate 9000 bits/sec, 16 packets/sec

     6904 packets input, 1117804 bytes, 0 no buffer

     Received 272 broadcasts (3 multicasts)

     0 runts, 0 giants, 0 throttles

     1576 input errors, 582 CRC, 0 frame, 0 overrun, 0 ignored

     0 watchdog, 3 multicast, 0 pause input

     0 input packets with dribble condition detected

     8796 packets output, 819348 bytes, 0 underruns

     0 output errors, 0 collisions, 0 interface resets

     0 unknown protocol drops

     0 babbles, 0 late collision, 0 deferred

     0 lost carrier, 0 no carrier, 0 pause output

     0 output buffer failures, 0 output buffers swapped out

[Leo Laohoo]

I disagree.  Negotiation of speed &/or duplex does NOT change the Reliability value and this I am very sure.  

Run a TDR and I am certain it's a cable issue.  

Post the complete output to the command "sh controll e Fa0/2".  If it's a duplex mismatch there should be errors on the left-hand side column under "collisions".  

[Karan Puri]

Leo gave the answer.. see the reliability. ..

@Leo , one question for you.. is test cable tdr n test interface is intrusive commands... can we use it during production time??? Do u have any sample output for this???


Sent from Cisco Technical Support Android App

[Leo Laohoo]

@Leo , one question for you.. is test cable tdr n test interface is intrusive commands

I've created a "blog" in regards on how to use TDR. 

Your question has two answers:  Yes and no.  Yes, it is intrusive particularly when you have old IOS like 12.2(44)SE or earlier/lower.   It is also intrusive if you have a PoE device in one end.  However, if you have newer IOS like 12.2(50)SE and higher (version) or if you have plain Fast- or GigabitEthernet connection, then TDR will not be intrusive.

can we use it during production time

My switches have the latest IOS and I run TDR very regularly during business hours.  Most of the time, it doesn't matter.  If you are running TDR it means something is wrong with the connection so it doesn't matter because the business owner wants the issue rectified no matter what.

[Carmicklec]

Leo,

Looks like your TDR link is dead. Any chance you have a new one?

[Georg Pauwen]

https://community.cisco.com/t5/networking-documents/how-to-use-time-domain-reflectometer-tdr/ta-p/3119327

[Karan Puri]

@Leo appreciate your doc.. I am searching for test interface doc too...

Sent from Cisco Technical Support Android App

[Guru Mysoruu]

Hi,

Whats the distance between the end points,is it greater than 100 meters.then you will face this issue,due to  signal attenuation.

check with cable,duplex,speed.

[Bhishma Khanna]

Hi,

In your case the input and CRC errors are almost equal

261028 input errors, 259429 CRC

This clearly points to a layer one issue, mosy probable a bad cable which is transmitting the traffic partially and that is why the counters of input errors and CRC are getting hit at same time.

Thanks.

[gavincreach]

In my case, we had set up 100/full for a connection to our ISP provider per their requirement.  Something changed on their side that was most likely auto/auto for 1gb.  I had input errors, crc errors, and frame errors accumulate as traffic flowed, which took down the DMVPN tunnel a few times and traffic was extremely slow.  Removed the 100/full and it came up without errors.  This was of course after changing all of our patch cables.  So not always a physical layer issue. 

[robert.lorrison]

Post removed

[CSCO11304974]

#clear counter command for clear CRC error