In Ethernet, a duplex mismatch is a condition where two connected devices operate in different duplex modes, that is, one operates in half duplex while the other one operates in full duplex. The effect of a duplex mismatch is a network that works but is often much slower than its nominal speed. Duplex mismatch may derive from manually setting two connected network interfaces at different duplex modes, but also derives from connecting a device that performs autonegotiation to one that is manually set to a full duplex mode.
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 highlight 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 attempts 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. As a result, almost all of the packets sent by the full-duplex end will be lost because the half-duplex end is streaming either data packet or acknowledgments at the time.
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 quiesce 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 acknowledgment 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.
-Full duplex and MDIX
-Manually set cisco to full duplex
REFERENCES
