Fastethernet input errors, 34 CRC

[ajay chauhan]

One of 2950 switch is connect with firewall and 34 input errors, 34 CRC then 35 input errors, 35 CRC then 36 input errors, 36 its increasing Like this . CRC increse ratio is same .what could be the reason.

sh int fa0/3

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

Hardware is Fast Ethernet, address is 0014.a85b.8443 (bia 0014.a85b.8443)

Description:Server 20

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

reliability 255/255, txload 28/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

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

input flow-control is unsupported output flow-control is unsupported

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

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

Last clearing of "show interface" counters never

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 7000 bits/sec, 5 packets/sec

5 minute output rate 11046000 bits/sec, 980 packets/sec

32284072 packets input, 2318079625 bytes, 0 no buffer

Received 134372 broadcasts (0 multicast)

0 runts, 0 giants, 0 throttles

34 input errors, 34 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 123280 multicast, 0 pause input

0 input packets with dribble condition detected

179374132 packets output, 2393906010 bytes, 0 underruns

0 output errors, 0 collisions, 2 interface resets

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

[jackyoung]

Try to check the cable or replace it and obverse the status.

And, how the rate of the erroer increase ? If compare to the total packet, it is only a very small amount and you can ignore it.

Hope this helps.

[glen.grant]

Make sure speed/duplex settings match on both ends , make both end either auto/auto or hardcode both ends. Also if you look at your display the counters they have never been cleared , so if this is something that has been operating for a half year or more I wouldn't worry about the few crc's .

[#4]

I agree with the hardcode option, especially in applications that you design for a specific parameter, ie FD on a point to point.

Also, admin shutdown and restart the interface after you make the change. I have seen problems with FEIP's connected to switches (2950T)that didn't go where you told them to until you cycle the interface.

Hope that it helps.

--Ron

[smothuku]

Hi Ajay ,

In put errors can be caused by a number of things, faulty wiring, signal interference, signal degradation due to distance, miscommunication by devices, collisions, and so many more. While Ethernet technology has come a long way, it is still not a perfect system and is not, and probably never will be a collision/errorless system. That is why there are built in Collision detection and Cyclic Redundancy Checking, CRC, in the system. While there is no documentation stating exact error percentages, there are industry accepted guidelines. These are up to 3% errors on a full duplex connection, and up to 30% errors on a half duplex connection. The reason for the difference is the way the two handle communication. Full duplex connections take turns transmitting, while half duplex often have both sides trying to transmitt at the same time.

Hope it helps you.

Thanks,

satish