This document provides an overview of the different counters related to
Ethernet collisions, and explains how to troubleshoot problems with Ethernet
collisions reported by these error messages (based on the platform):

%AMDP2_FE-5-COLL

%DEC21140-5-COLL

%ILACC-5-COLL

%LANCE-5-COLL

%PQUICC-5-COLL

%PQUICC_ETHER-5-COLL

%PQUICC_FE-5-COLL

%QUICC_ETHER-5-COLL

%AMDP2_FE-5-LATECOLL

%DEC21140-5-LATECOLL

%ILACC-5-LATECOLL

%LANCE-5-LATECOLL

%PQUICC-5-LATECOLL

%PQUICC_ETHER-5-LATECOLL

%PQUICC_FE-5-LATECOLL

%QUICC_ETHER-5-LATECOLL

%SIBYTE-4-SB_EXCESS_COLL

Note: The information in this document only applies to half-duplex
Ethernet. In full-duplex Ethernet, collision detection is disabled.

This document is not restricted to specific software and hardware
versions.

The information in this document was created from the devices in a
specific lab environment. All of the devices used in this document started with
a cleared (default) configuration. If your network is live, make sure that you
understand the potential impact of any command.

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.

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.

In summary, 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.

Some useful facts:

The maximum amount of time slots is limited to
1024.

The maximum amount of retransmissions for the same frame in the
collision mechanism is 16. If it fails 16 consecutive times, it is counted as
an excessive
collision.

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.

As explained here, collisions do not constitute a problem. The
collisions counter counts the number of frames for which one or more collisions
occurred when the frames were sent.

The collisions counter can be broken down into single
collisions and multiple collisions, as in this output
from the show controller command:

8 single collisions, 2 multiple collisions

This means that eight (out of 10) frames have been successfully
transmitted after one collision; the other two frames required multiple
collisions to arbitrate access to the medium.

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.

In conclusion, the collisions counter does not provide a very useful
statistic to analyze network performance or problems.

To allow collision detection to work properly, the period in which
collisions are detected is restricted (512 bit-times). For Ethernet, this is
51.2us (microseconds), and for Fast Ethernet, 5.12us. For Ethernet stations,
collisions can be detected up to 51.2 microseconds after transmission begins,
or in other words up to the 512th bit of the frame.

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.

Note: 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.

As discussed earlier, the maximum number of retries in the backoff
algorithm is set to 16. This means that if an interface fails to allocate a
slot in which it can transmit its frame without another collision 16 times, it
gives up. The frame is simply not transmitted, and is marked as an
excessive collision.

Note: The Transmit Retry Count (TRC) counter is a 4-bit field which
indicates the number of transmit retries of the associated packet. The maximum
count is 15. However, if a Retry Error occurs, the count rolls over to zero. In
this case only, the TRC value of zero should be interpreted as meaning sixteen.
TRC is written by the controller into the last transmit descriptor of a frame,
or when an error terminates a frame.

Note: The time delay reflectometer (TDR) counter is an internal counter
that counts the time (in ticks of 100 nanoseconds (ns) each) from the start of
a transmission to the occurrence of a collision. Because a transmission travels
about 35 feet per tick, this value is useful to determine the approximate
distance to a cable fault.

You can check the number of excessive collisions in the output of a
show controller ethernet [interface
number] command.

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.

In Cisco Catalyst switches, the
%SIBYTE-4-SB_EXCESS_COLL system message is
displayed for every occurrence of an excessive collision, if the service
internal mode is on. With service internal mode off, the system only prints out
this message whenever the excessive collision reaches a certain fixed
threshold. In this case, the appearance of this message might indicate a real
collision case. With the service internal mode on, the system prints out this
message whenever there is one instance of excessive collision. It might be
caused by some hardware noise. The occasional appearance of this message with
service internal mode on is a normal behavior. You can issue the
no service internal command in order to turn off
this logging and see how that affects your error logs.