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....
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.
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
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".
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 , 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.
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.
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.
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.