Which switch port error is an indication of duplex mismatches on 10/100/1000 IEEE 802.3u
Gigabit Ethernet ports?

A.
FCS errors

B.
Runts

C.
Multiple collisions

D.
Alignment errors

Explanation:
Communication is possible over a connection in spite of a duplex mismatch. Single packets are
sent and acknowledged without problems. As a result, a simple ping command fails to detect a
duplex mismatch because single packets and their resulting acknowledgments at 1-second
intervals do not cause any problem on the network. A terminal session which sends data slowly (in
very short bursts) can also communicate successfully. However, as soon as either end of the
connection attempts to send any significant amount of data, the network suddenly slows to very
low speed. Since the network is otherwise working, the cause is not so readily apparent.
A duplex mismatch causes problems when both ends of the connection attempt to transfer data at
the same time. This happens even if the channel is used (from a high-level or user’s perspective)
in one direction only, in case of large data transfers. Indeed, when a large data transfer is sent
over a TCP, data is sent in multiple packets, some of which will trigger an acknowledgment packet
back to the sender. This results in packets being sent in both directions at the same time.
In such conditions, the full-duplex end of the connection sends its packets while receiving other
packets; this is exactly the point of a full-duplex connection. Meanwhile, the half-duplex end
cannot accept the incoming data while it is sending — it will sense it as a collision. The half-duplex
device ceases its current transmission and then retries later as per CSMA/CD. As a result, when
both devices are attempting to transmit at the same time, packets sent by the full-duplex end will
be lost and packets sent by the half duplex device will be delayed or lost.

The lost packets force the TCP protocol to perform error recovery, but the initial (streamlined)
recovery attempts fail because the retransmitted packets are lost in exactly the same way as the
original packets. Eventually, the TCP transmission window becomes full and the TCP protocol
refuses to transmit any further data until the previously-transmitted data is acknowledged. This, in
turn, will quiescence the new traffic over the connection, leaving only the retransmissions and
acknowledgments. Since the retransmission timer grows progressively longer between attempts,
eventually a retransmission will occur when there is no reverse traffic on the connection, and the
acknowledgments are finally received. This will restart the TCP traffic, which in turn immediately
causes lost packets as streaming resumes. The end result is a connection that is working but
performs extremely poorly because of the duplex mismatch. Symptoms of a duplex mismatch are
connections that seem to work fine with a ping command, but “lock up” easily with very low
throughput on data transfers; the effective data transfer rate is likely to be asymmetrical,
performing much worse in one direction than the other. In normal half-duplex operations late
collisions do not occur. However, in a duplex mismatch the collisions seen on the half-duplex side
of the link are often late collisions. The full-duplex side usually will register frame check sequence
errors, or runt frames. Viewing these standard Ethernet statistics can help diagnose the problem.
Contrary to what one might reasonably expect, both sides of a connection need to be identically
configured for proper operation. In other words, setting one side to automatic (either speed or
duplex or both) and setting the other to be fixed (either speed or duplex or both) will result in a
speed mismatch, a duplex mismatch or both. A duplex mismatch can be fixed by either enabling
autonegotiation (if available and working) on both ends or by forcing the same settings on both
ends (availability of a configuration interface permitting). If there is no option but to have a locked
setting on one end and autonegotiation the other (for example, an old device with broken
autonegotiation connected to an unmanaged switch) half duplex must be used. All modern LAN
equipment comes with autonegotiation enabled and the various compatibility issues have been
resolved. The best way to avoid duplex mismatches is to use autonegotiation and to replace any
legacy equipment that does not use autonegotiation or does not autonegotiate correctly.