01-06-2010 02:25 AM - edited 03-06-2019 09:10 AM
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
07-11-2012 10:55 PM
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....
07-11-2012 11:10 PM
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.
11-09-2013 03:08 PM
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,
02-25-2016 09:02 AM
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
02-25-2016 12:05 PM
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".
11-11-2013 12:01 PM
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
11-11-2013 01:44 PM
@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.
10-07-2020 12:24 PM
Leo,
Looks like your TDR link is dead. Any chance you have a new one?
10-07-2020 02:54 PM
11-12-2013 11:40 AM
@Leo appreciate your doc.. I am searching for test interface doc too...
Sent from Cisco Technical Support Android App
11-13-2013 11:58 PM
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.
01-10-2014 02:57 AM
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.
03-13-2018 09:53 PM
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.
11-01-2019 07:15 AM - edited 11-01-2019 09:11 AM
Post removed
05-28-2018 09:40 AM
#clear counter command for clear CRC error
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