06-27-2013 09:21 AM - edited 03-04-2019 08:19 PM
Gents,
My crc errors are steadily increasing on the Ethernet segment, but when i ping the BGP neighbor (so packets travel accross this "bad" segment) i do not see any packets going bad. Anyone got an explanation for this?
How is this possible, i would expect at least something going wrong with my ping test.
Unfortunately Google could not help me.
xxxx#ping xxx.22x.193.174 repeat 1000 size 1400
Type escape sequence to abort.
Sending 1000, 1400-byte ICMP Echos to xxx.22x.193.174, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (1000/1000), round-trip min/avg/max = 232/251/552 ms <===
xxxx#sh int Fa0/0
FastEthernet0/0 is up, line protocol is up
Hardware is Gt96k FE, address is 001f.9ee5.d32a (bia 001f.9ee5.d32a)
Description: ISP
Internet address is xxx.12x.110.226/27
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:18, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:05:28
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 214000 bits/sec, 76 packets/sec
5 minute output rate 232000 bits/sec, 72 packets/sec
25999 packets input, 9368996 bytes
Received 7 broadcasts, 0 runts, 0 giants, 0 throttles
66 input errors, 66 CRC, 0 frame, 0 overrun, 0 ignored <===
0 watchdog
0 input packets with dribble condition detected
25199 packets output, 10021048 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
6 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
07-02-2013 07:23 AM
Hello,
Are the crc growing still? There is a possibility thay they might be generated before and the cable is good now. Try clearing the interface counters and again ping and check the interface status.
Sent from Cisco Technical Support Android App
07-03-2013 04:45 AM
I have send out a NEW wic card to the site, we are going to replace it, both sides are configured as 100/full hard coded (auto neg = off) Will keep you posted!
07-04-2013 10:17 PM
Reasons for CRC error.
1. cable issue( some times cross cable will used instead of Straight cable vice versa).
2: Duplex and Speed mismatch.
After replacing this two still problem persist then might problem with port..
Once replaced cable and Configuration.. Before generating ping clear the counters and observe the errors..
07-04-2013 10:34 PM
full hard coded (auto neg = off)
If you have two Cisco devices, I'd recommend you enable auto-negotiation. When you hard-code the speed and duplex, you'll see more line errors.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide