NetworkShaw: Troubleshoot interface and cable issues

Troubleshooting interface and cable issues (collisions, errors, duplex, speed)

In full-duplex Ethernet, collision detection is disabled
A collision is the mechanism used by Ethernet to control access and allocate shared bandwidth among stations that want to transmit at the same time on a shared medium.
Because the medium is shared, a mechanism must exist where two stations can detect that they want to transmit at the same time. This mechanism is collision detection.
Ethernet uses CSMA/CD (Carrier Sense Multiple Access/Collision Detect) as its collision detection method. Here is a simplified example of Ethernet operation:

Station A wishes to send a frame. First, it checks if the medium is available (Carrier Sense). If it isn't, it waits until the current sender on the medium has finished.
Suppose Station A believes the medium is available and attempts to send a frame. Because the medium is shared (Multiple Access), other senders might also attempt to send at the same time. At this point, Station B tries to send a frame at the same time as Station A.
Shortly after, Station A and Station B realize that there is another device attempting to send a frame (Collision Detect). Each station waits for a random amount of time before sending again. The time after the collision is divided into time slots; Station A and Station B each pick a random slot for attempting a retransmission.
Should Station A and Station B attempt to retransmit in the same slot, they extend the number of slots. Each station then picks a new slot, thereby decreasing the probability of retransmitting in the same slot.

Collisions are a way to distribute the traffic load over time by arbitrating access to the shared medium. Collisions are not bad; they are essential to correct Ethernet operation.
The deferred counter counts the number of times the interface has tried to send a frame, but found the carrier busy at the first attempt (Carrier Sense). This does not constitute a problem, and is part of normal Ethernet operation.
An increasing collision rate (number of packets output divided by the number of collisions) does not indicate a problem: it is merely an indication of a higher offered load to the network. An example of this could be because another station was added to the network.
There is no set limit for "how many collisions are bad" or a maximum collision rate.
The collisions counter does not provide a very useful statistic to analyze network performance or problems.
The station that reports a late collision merely indicates the problem; it is generally not the cause of the problem. Possible causes are usually incorrect cabling or a non-compliant number of hubs in the network. Bad network interface cards (NICs) can also cause late collisions.
Excessive collisions indicate a problem. Common causes are devices connected as full-duplex on a shared Ethernet, broken NICs, or simply too many stations on the shared medium. The excessive collisions can be resolved by hardcoding speed and duplex.

Use this command to view collisions:

show interfaces

CRC - a high number of CRCs is usually the result of collisions or a station transmitting bad data.

frame - shows the number of packets received incorrectly having a CRC error and a noninteger number of octets. On a LAN, this is usually the result of collisions or a malfunctioning Ethernet device.

collisions - gives the number of messages retransmitted due to an Ethernet collision. This is usually the result of an overextended LAN (Ethernet or transceiver cable too long, more than two repeaters between stations, or too many cascaded multiport transceivers). A packet that collides is counted only once in output packets.

Use this command to view errors:

show interfaces

Ethernet is up, down or administratively down
packets input gives the total number of error-free packets received by the system
bytes input gives the total number of bytes, including data and MAC encapsulation, in the error-free packets received by the system
input error includes runts, giants, no buffer, CRC, frame, overrun, and ignored counts. Other input-related errors can also cause the input error count to be increased, and some datagrams may have more than one error; therefore, this sum may not balance with the sum of enumerated input error counts.
frame shows the number of packets received incorrectly having a CRC error and a noninteger number of octets. On a LAN, this is usually the result of collisions or a malfunctioning Ethernet device
input packets with dribble condition detected gives the dribble bit error, which indicates that a frame is slightly too long. This frame error counter is incremented just for informational purposes; the router accepts the frame
output errors gives the sum of all errors that prevented the final transmission of datagrams out of the interface being examined. Note that this may not balance with the sum of the enumerated output errors because some datagrams may have more than one error, and others may have errors that do not fall into any of the specifically tabulated categories
restarts gives the number of times a Type 2 Ethernet controller was restarted because of errors.

duplex and speed should match on both ends or else you will have problems
traffic can still pass with mismatched duplex and speed, but you will experience retransmissions and reduced throughput
to verify duplex and speed run the command

show interface x/x

If you want to hard code the speed and duplex on a switch that runs Cisco IOS Software (turn off auto-negotiation), issue the speed and duplex commands underneath the specific interface.
Duplex is subservient to speed in the sense that if speed is set to auto, then the duplex cannot be manually set.
You might see cyclic redundancy check (CRC) error messages when both the speed and duplex settings are hardcoded on the two devices. This might be because any one of the devices runs an earlier version of Cisco IOS.
You can upgrade the Cisco IOS or set the speed and duplex to auto on both devices in order to resolve this.