cisco interface errors

NickHills

Hello,

we are seeing a very high number of "input errors" on our cisco switches. These errors only occur under heavy load (like backups)  and only appear on the interfaces between src and dest ports involved with the backup process.

I know a number of errors is to be expected during bursting on these interfaces, but it seems that the error counts we are seeing are quite extensive.

common causes of this i know can be autoneg for speed and duplex, but would this not constantly error, not just under heavy load?

All of the interfaces are connected to HP proliant servers with NICs in a variety of modes (Teamed TLB, Teamed NFT, and un-teamed) and patch cables have been checked and swapped yet still the issue persists.

I am planning to test a few interfaces by hardcoding the speed/duplex, but wonder if anyone else has seen this sort of behaviour and has any ideas what i can do to resolve.

the switches are 4500s, servers HP Proliants, and ports are configured as follows:

#sh run int gi3/31
Building configuration...
Current configuration : 112 bytes
!
interface GigabitEthernet3/31
 switchport access vlan 11
 switchport mode access
 spanning-tree portfast
end

#sh int gi3/31
GigabitEthernet3/31 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet Port, address is 0012.430d.505e (bia 0012.430d.505e)
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 80/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, link type is auto, media type is 10/100/1000-TX
  input flow-control is off, output flow-control is off
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input never, output never, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 2339315
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 316568000 bits/sec, 26290 packets/sec
  5 minute output rate 6324000 bits/sec, 10104 packets/sec
     2110384561 packets input, 2144877692248 bytes, 0 no buffer
     Received 8456236 broadcasts (3272658 multicast)
     0 runts, 0 giants, 0 throttles
     103139 input errors, 1 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     3498749824 packets output, 1651942536917 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 output buffer failures, 0 output buffers swapped out

thanks for your time!
Nick

jemertz

I can't tell you what is causing these, but I can tell you that it's not a speed or duplex mismatch.
1) A Speed mismatch will not allow the link to come up. If either side is Auto, it will correctly detect the highest speed supported by the other side, even if hard-coded.

2) A Duplex mismatch cannot occur at 1000 Mbps. There is no 1000/half standard. It was never written. Gig always works at Full duplex so the following statements do not apply when 1000 Mbps speed has been negotiated.
3) If running at 10 or 100, and one side is Auto but the other side is hard-coded for both speed and duplex, the Auto side will always choose the correct speed, and Half duplex, whether this is correct or not. If the opposite side of the link is Half, there is no mismatch, and you will see the normal Collisions that you will see on any half-duplex link. If the opposite side of the link is Full, you will see Late Collisions and CRC Errors as an indication of this. If you see that combination, check your operating duplex, and if it's half, safe money says the other side is hard-coded to Full.

4) The opposite side of the mismatched link (the one hard-coded to Full duplex) will not see CRC and Late Collisions (Full never detects a collision - Ever) but will instead see Frame Errors. This is because when the half-duplex side detects the Full Duplex side transmitting while it is already "speaking" it stops and sends a jamming signal to clear the line for a fixed amount of time. The Full duplex side sees this as a transmission that lasts longer than the time a frame is supposed to take, and records it as a Frame Error.

Since you are operating at gig speeds, you can't have a mismatch, and 3 and 4 do not apply. Also since you are not seeing CRC, Late Collision, or Frame Errors on this interface, you can be confident that you never had a mismatch since the counters were cleared.

Oh, and since you asked whether a mismatch would constantly error, or only under load, the answer is some of each. You can see errors at any time, but when the interface is under heavy load you will see far more errors than when it is mostly idle. Under extremely heavy load, its throughput will drop significantly due to the half duplex side constantly stopping both transmitting and listening, and sending jamming signals. I don't believe it can ever drop to 0, but it will definitely cause a service impact if fast throughput is an important factor for your application.

P.S. I know this is a 6-year-old post, but I hope this answer helps somebody else with a similar question in the future.