Autonegotiation
Network autonegotiation is easily misunderstood. Consider two 10/100Mb devices attached to one another – a PC connected to a router. For each of these devices, it’s possible to configure the connection to use either 1) a fixed speed and duplex or 2) to negotiate the optimal shared speed and duplex with whatever it is connecting to. What is not intuitive is that both devices must be configured with the same settings. The connection will suffer a performance hit, or may not work at all, if the two devices are configured differently.
A common misconception about autonegotiation is that it is possible to manually configure one link partner for 100 Mbps full-duplex and autonegotiate to full-duplex with the other link partner. In fact, an attempt to do this results in a duplex mismatch. This is a consequence of one link partner autonegotiating, not seeing any autonegotiation parameters from the other link partner, and defaulting to half-duplex.
If both devices are configured to autonegotiate speed and duplex, then each will attempt to make the best possible connection among the possibilities they have in common. However, if one of the devices is set to use a fixed speed and duplex and the other device is set to autonegotiate, the autonegotiating device can determine the speed but not the duplex of the other device and so falls back to its default duplex mode. In the case of Cisco switches, the default duplex mode is half-duplex.
…it is possible for a[n autonegotiating] link partner to detect the speed at which the other link partner operates, even though the other link partner is not configured for auto-negotiation. In order to detect the speed, the link partner senses the type of electrical signal that arrives and sees if it is 10 Mb or 100 Mb.
It is not possible to detect the correct duplex mode in the same method that the correct speed can be detected. In this case, the […] port of [the autonegotiating] switch […] is forced to select the default duplex mode. On Catalyst Ethernet ports, the default mode is auto-negotiate. If auto-negotiation fails, the default mode is half-duplex.
http://www.cisco.com/en/US/tech/tk389/tk214/technologies_tech_note09186a0080094781.shtml
Half-duplex as a default duplex mode is not unique to Cisco switches. Below is a link to an article on www.dell.com written by Rich Hernandez, a senior engineer with the Server Networking and Communications Group at Dell, that contains a table summarizing “all possible combinations of speed and duplex settings, both on 10/100/1000-capable switch ports and on NICs.” Included are combinations that would yield no link or link fail conditions, as well as combinations that would yield a duplex mismatch.
http://www.dell.com/content/topics/global.aspx/power/en/ps1q01_hernan?c=us&cs=555&l=en&s=biz
The importance of using identical settings on both sides of a network connection is stressed in a KB article from www.symantec.com with information on how an autonegotiating port may report that it has established a full-duplex connection with a NIC configured for 100MBs/Full, but in fact is communicating at less than expected capacity.
Only by explicitly setting both sides of the link to the same duplex mode would the link work flawlessly.
http://www.symantec.com/business/support/index?page=content&id=TECH87827
Understanding link data errors
The page at the link below contains two tables that explain the various errors and counters logged by a network switch and the possible causes.
Troubleshooting Ethernet Collisions
Collisions may appear to indicate communication problems with a network connection, but as a technote from cisco.com states, collision counters alone are not indicative of network problems.
…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.
There is no set limit for “how many collisions are bad” or a maximum collision rate.
In conclusion, the collisions counter does not provide a very useful statistic to analyze network performance or problems.
http://www.cisco.com/en/US/products/hw/modules/ps2033/products_tech_note09186a008009446d.shtml
Late Collisions
When a collision is detected by a station after it has sent the 512th bit of its frame, it is counted as a late collision.
The station that reports the 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.
http://www.cisco.com/en/US/products/hw/modules/ps2033/products_tech_note09186a008009446d.shtml