Conflicts surrounding half-duplex (HDx) and full-duplex (FDx) modes in Ethernet networks are well known to those who have spent hours tracking them down. This problem did not exist when Ethernet was first developed, however it evolved from what can only be described as a failed evolution through committees and standards.

A duplex conflict is a misunderstanding of transmission rules between two or more network interfaces that are connected together. Some applications like Ping and Telnet are rarely are affected by this problem. Links that handle only one socket at a time usually are not impeded. However, when multiple applications attempt to transmit simultaneously on a link, applications slow down and sometimes fail.

The problem becomes more clouded by the fact that duplex auto-negotiation techniques for NICs, switches, and routers are either obscure or incorrectly implemented. Often duplex rules are incorrectly negotiated on an interface, and the user has no method of seeing whether the interface negotiated full-duplex or half-duplex. Commonly, switches report that they have auto-negotiated full-duplex when in fact they are operating in half-duplex. Finally, some auto-negotiating schemes do not attempt to detect the link’s duplex mode. Rather, the link is put into a state that is neither half nor full-duplex, at the cost of overall link performance.

10Base-2 and 10Base-5

Let’s start by looking at 10Base-2 and 10Base-5 Ethernet networks. Ethernet originally was either 10Base-2 or 10Base-5. Both flavors were based on transceivers that were connected via coaxial cable, which could only carry one transmission at a time. NICs were connected to transceivers that joined the transmit (TX) and receive (RX) wires together. When networks are connected in this fashion, the transmission protocol used is CSMA/CD, also known as 'half-duplex'. Basically, a station doesn't transmit until the line is clear. While transmitting, it doesn't listen to its transmitted data, but it does listen for other stations transmitting. Any time multiple stations transmit at the same time a collision occurs, and each station retransmits at a later time.



10Base-T and hubs

Reliability and connectivity problems led to the next generation of Ethernet. 10Base-T networks connected NIC cards to centralized hub devices. 10Base-T networks that are connected into hubs have cables between NIC cards that carry both TX and RX transmission pairs. What is not clearly evident is the fact that within the hub, the TX and RX wires are connected together. Functionally and electronically, 10Base-T hubs work exactly the same as 10Base-2 and 10Base-5 Ethernet designs. They operate in half-duplex mode.


10Base-T and switches

The next step in the evolutionary chain is the development of switches for 10Base-T networks. Switches replaced hubs, and in general, improved the overall performance of the Ethernet network. With switches, the TX and RX wires are independent of each other, allowing simultaneous multi-direction transmissions. For the first time CSMA/CD rules became optional. Soon, full-duplex connections were supported, allowing any NIC to transmit at any time that it had data available for transmission. And this is where conflicts began.


Conflict on hubs

Once NIC cards started to support full-duplex, hub-based systems were affected by any NICs that were set to full-duplex. Recall that a hub can only support one transmitting station at a time. When Station B is set to full-duplex, it may attempt to transmit while receiving other traffic. This corrupts any frames that are passing through the hub, resulting in packet loss. If more than 64 bytes of the frame has passed through the hub at the moment the crash occurs, the frame is not considered to be a collision. Therefore, a retransmission is not generated at the physical layer, and the frame is lost.


Both stations must have the same duplex setting for a collision-free experience:


Conflict on switches

Switches require setting the duplex mode on a per-port basis. The port setting should match the settings of the device attached to the port. Note that Station A and the switch won't have any problems. However, if Station A is talking to Station B, its packets are susceptible to collision. Once again, Station B transmits regardless of the state of its receive line. However, the HDx setting at the switch restricts the port from receiving while it is transmitting, and Station B’s traffic will be lost. FDx does not support collision algorithms and therefore Station B’s traffic is not recovered.


All port/station pairs must have matching duplex settings to have a collision-free experience:



Most of us have seen auto-negotiation settings on NICs, switches, and routers. Logic suggests that using the auto-negotiate setting either at the NIC or at a port will alleviate duplex conflicts. Unfortunately, this often is not the case. The problem is that there is no clear standard on what auto-negotiate means. In a practice, we have seen many implementations and interpretations of this setting with regards to duplex issues. Commonly, auto-negotiate means that, when the link is established, i.e., the NIC is connected to a port, negotiations will occur to ensure that both sides of a connection are set to the right speed and duplex mode. The speed is often correct; however we often find that duplex negotiations fail.

Here is an example of this behavior on a common switch that we tested with Delivery monitoring.: we set the 100 Mbps switch ports to auto-negotiate, and tested with 3 manufactures' NICs. We set each card to auto-negotiate half-duplex and full-duplex. In each case, a conflict occurred. Further, the switch often incorrectly reported the negotiated duplex mode. For example, if the NIC was set to full-duplex, the switch would also report that it had negotiated full-duplex; however, Delivery monitoring still found a conflict. Only by explicitly setting both sides of the link to the same duplex mode would the link work flawlessly.

Many switches are receiving microcode updates that change the behavior of auto-negotiate mode. This mode of auto-negotiation does not appear to guess what the other end of the link is set to. Rather, the port operates in a mode that is neither half-duplex nor full-duplex. Although performance is degraded, the possibility of a conflict is less likely. For example, when setting up test cases where a station is set to full-duplex mode, and the switch is set to auto-negotiate, we don't see a conflict between half and full-duplex. However, Delivery monitoring found that the capacity of the link was 35% below expected, yet higher than would be possible on a half-duplex link. By switching from auto-negotiate to full-duplex, the full capacity of the link was once again realized. Quite clearly, this method of auto-negotiation sacrifices performance to address the inability to accurately negotiate duplex mode.


Recommendations for Duplex Settings

There are many policies regarding duplex settings for cards, and we have come up with the following conclusion. A large well-established NSP, ISP, NOC, ASP or data center will eventually choose to ban "auto-negotiate" settings from all switches, routers and NICs. We recommend such a policy whenever practical. However, these policies are often difficult to implement if you have any end users on your network. In general, NIC cards will default to "auto-negotiate" mode when installed, and conflicts often are inevitable. Luckily, 1Gbps links are manufactured for full-duplex operation only. Also, 10Gbps standards disallow half-duplex operation. However, do not forget that implanting these high-speed LANs doesn’t free you from configuration problems. Do not forget that jumbo frames implemented in 1Gbps Ethernet can cause MTU negotiation errors usually not seen in lower-speed links. By using Delivery monitoring, you will be able to take control of duplex conflicts. Within minutes, you will be able to assess whether or not your links are suffering from conflicts or degradation due to duplex implementation.