Input errors on Fastethernet trunk
Posted on 2008-11-19
I have a Catalyst 3560 switch at an out-site, connecetd back via cat5e over a BT LES 10Mb circuit abck to the core 6509 switch.
I have been getting input errors increasing on the edge switch, on the trunk that connects it back to the 6509. The users at the site have been experiencing a few issues with VoIP break-up, and I'm wondering if this is related, and what could be causing it.
I've changed the patch leads at both ends, and changed the ports (and even the blades/switches) at both ends. BT have tested the LES circuit, and not detected any issues on it, even under full load.
The errors I get show up like this (Counters cleared about 10 mins prior to this)...
FastEthernet0/24 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 0023.5d18.801a (bia 0023.5d18.801a)
Description: LES 2 circuit to Core
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 8/255, rxload 21/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 10Mb/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:00, output 00:00:01, output hang never
Last clearing of "show interface" counters 00:12:40
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 832000 bits/sec, 296 packets/sec
5 minute output rate 320000 bits/sec, 286 packets/sec
206713 packets input, 72601492 bytes, 0 no buffer
Received 4719 broadcasts (0 multicasts)
0 runts, 0 giants, 0 throttles
25 input errors, 25 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 3583 multicast, 0 pause input
0 input packets with dribble condition detected
201211 packets output, 27942893 bytes, 0 underruns
0 output errors, 0 collisions, 0 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
I always get the same rate of input errors and CRCs. I really can't think what else it could be.
Interface is set up as follows :-
switchport trunk encapsulation dot1q
switchport trunk allowed vlan x,y,z
switchport mode trunk
mls qos trust dscp
So nothing special.
I'm not sure whether this rate of errors would be performance-impacting on this link, and would appreciate input on this too.
By the way, the other end (6509) does not have any errors showing...