For years there has been a popular misconception surrounding the "auto-negotiation" features of Fast Ethernet networks.
Many are under the illusion that this feature is unstable and simply not to be trusted. The result is a frequent recommendation to "hard-code" or manually configure your switched ports to "Full-Duplex" instead of letting it choose between Full or Half. While this is acceptable in some circumstances, it can really get you in trouble in others.
Specifically, I've noticed a lot of IP Telephony vendor documentation lately that lists hard-coding your switch ports to Full-Duplex as a best practice, but neglects to mention that the IP Phone end station MUST also be statically set to Full duplex because they default to Auto-negotiate. So if you intend to follow these "best practice" recommendations to set all your ports, make sure you turn off auto-negotiation on the phones as well! Of course, setting both sides to auto-negotiate will result in a full-duplex connection, which is the desired result. The important thing is that both sides be set the same: both Auto or both Full.
A little more technical detail: The term "negotiation" is something of a misnomer. What actually happens is that each device on a segment sends out a series of messages (called Fast Link Pulses) that form some code words that explain what settings it is capable of supporting. At the same time, each device receives the messages from the other side and compares them to its own, and they both choose the highest common denominator but neither acknowledges the other received its transmission.
So the problem here is that when you manually configure the duplex, what you're actually doing is turning off auto-negotiation. That means that if you only do it for one side, only one side will send its capabilities message. Thus, this device will not receive any messages from its peer and will choose the lower duplex setting (half). Connectivity will still occur because this device can auto-DETECT (different than negotiate) the link speed (10 or 100), but not the duplex.
The result is that data will traverse the link under very light loads, but because half-duplex is using Collision Detection and Full-duplex does not have collisions, when any substantial load is placed on the line, any link contention causes real problems because the full-duplex side will continue transmitting, while the half-duplex side waits for it to finish. Worse, the half-duplex side will transmit a frame when the wire is quiet, but the full-duplex side will transmit while the half-duplex side is speaking, causing one to report Frame Check Sequence (FCS) or Cyclical Redundancy Check (CRC) errors and the other collisions. Needless to say, voice quality in this condition will be totally unacceptable.
Thomas Alexander Lancaster IV is a consultant and author with over ten years experience in the networking industry, focused on Internet infrastructure.
Dig deeper on Unified Communications Resources