l l l l l

������ �� ��� �������

� ������ �� ������� �������������� ��� ������������

������ ����������
��� � ������ �������� ��� ������� � �������

��������� l ������ ����

�������� ���� ������ l ��� ������ ����� l ��� � ��� ����� ������ l ���������� ������� ��������� ������� ��� ��� l �������������������������������
 Technical White Paper Series
Duplex Conflicts

Company

Apparent Networks is a leading innovator of network intelligence software. Apparent Networks’s technology, AppareNet, a network
intelligence system, operates non-intrusively on live networks, to and from any location worldwide. Without requiring specialized
hardware or remote agents, AppareNet views the network from the application’s perspective. In doing so, AppareNet rapidly
identifies the locations and causes of network bottlenecks anywhere in the world so that companies can boost the performance
of, and gain more value from, the network infrastructure they already have. Apparent Networks improves its customers’ businesses
by helping organizations reduce operational costs, increase IP availability, and protect revenues.

Contact Information

Canadian Head Office

400 - 321 Water Street

Vancouver, BC
Canada V6B 1B8

Sales: 1.800.508.5233
Support: 1.800.664.4401
Telephone: 604.433.2333
Fax: 604.433.2311

http://www.apparentnetworks.com
marketing@apparentnetworks.com

This report in whole or in part may not be duplicated, reproduced, stored or retransmitted without prior written permission of Apparent Networks. All opinions and
estimates herein constitute our judgment as of this date and are subject to change without notice. Any product names mentioned herein may be trademarks and/or
registered trademarks of their respective companies.

Duplex Conflicts
Technical Series
This is the second in a technical series of white papers from Apparent
Networks examining the Perils of the Network. This technical series
explains network idiosyncrasies and degradations and how AppareNet
is capable of identifying network problems.
The first paper in this series, The Apparent Network, introduced the
concept of the AppareNet network as a complete end-to-end view of
a network. This paper discusses one of the most pervasive problems
on networks today, duplex conflicts.
Executive Summary
A recent study concluded that duplex conflicts (otherwise known as
duplex mismatches) cause 75% of all Internet/2 problems.* Most
Network Engineers have encountered such conflicts, and understand
how elusive they can be. These conflicts often go undiscovered by
existing tools and network management technologies, leaving users
experiencing painfully slow and erratic network performance. Some
networking professionals have gone as far as to call the problem an
epidemic.
This paper defines the problem, along with some common
application performance symptoms of duplex problems. A brief
history of Ethernet technology provides a context for how and why
duplex conflicts have become a prevalent performance inhibitor in
today’s network infrastructures. The nature of conflicts on hubs and
switches, as well as an exploration of inconsistent "auto-negotiate"
implementations, will also be outlined.
AppareNet offers unique capabilities for rapidly measuring network
capacity, often identifying the duplex mode, and can identify and
pinpoint duplex conflicts in an IP network. Once the problem source
is isolated, a simple reconfiguration of the network equipment is
typically all that is required to achieve significant and noticeable
improvements in IP network performance. AppareNet allows
organizations to maximize the performance and ROI of IP networking
infrastructures.
* Internet2, Fall 2001, End-to-end Performance Initiative
Technical White Paper Series
Duplex Conflict/Mismatch
A duplex conflict or mismatch is the mixing of transmission rules
between two network interfaces that are connected together. Each
interface implements a different rule set, resulting in simultaneous
attempts at transmission causing lost packets.
Impact on Application Performance
Some applications (e.g. ping, telnet) are rarely affected by duplex
problems. Links that handle only one socket at a time usually are
not impeded. Hence, the scale and performance impact of the
problem is a relatively minor issue for a network link that is used
only by non-intensive or one-way data exchange.
However, when multiple applications (sockets) attempt to transmit
simultaneously on a link with a duplex mismatch, packets are lost
and re-transmissions are forced; applications begin to slow down
and sometimes fail. This is a common scenario for application or FTP
servers, and performance degradations of 50-80% from expected
levels are quite common.
One symptom of a potential duplex problem in an IP network is FTP
performance fade. When an FTP download is started, the initial
performance and data transfer rate is acceptable, but then, as
collisions and packet loss start to occur due to a duplex conflict, the
TCP sliding window is progressively decreased until the performance
slows to a crawl.
Before AppareNet, there simply were no tools that reported duplex
conflicts. It was nearly impossible to understand when or where
conflicts and link degradations were occurring.
A brief look at the history of Ethernet reveals how and why duplex
conflicts occur as often as they do.
Page 1
 Technical White Paper Series
Duplex Conflicts

Brief History of Ethernet Hub

Ethernet originally was either 10Base-2 or 10Base-5. Both flavors ** Hub Internal
Connection
** Hub Internal
Connection
** Hub Internal
Connection

used transceivers connected via coaxial cable, carrying only one * Xceiver

transmission at a time. Network Interface Card (NIC) transceivers

joined the transmit (Tx) and receive (Rx) wires together. Tx Rx

Port Port Port Port

Tee Connector Tee Connector Tee Connector Tee Connector

Xceiver

** Coaxial Cable ** Coaxial Cable ** Coaxial Cable

Rx Tx
* Xceiver

NIC a NIC b NIC c NIC d

* Tx and Rx joined here in the Hub

** Only one transmitting station allowed at one time;
internal function similar to a coaxial cable
Tx Rx

In 10Base-T networks, hubs typically interconnect NICs using cables

NIC a NIC b NIC c
* Tx and Rx joined here in the NIC
** Only one transmitting station allowed at one time
When networks were connected in this fashion (as illustrated above),
the transmission protocol used was CSMA/CD (Carrier Sense Multiple
Access/Collision Detect), also known as half-duplex (HDx). Simply
stated, a station does not transmit if it detects any other stations
NIC d
that have 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 Ethernets. In other words, they
operate in half-duplex mode.
Switch
Switch Fabric

transmitting. While it is transmitting, it does not listen for other

stations. It does listen for collisions (multiple stations transmitting at
once), subsequently retransmitting at a later time.
Tx Rx

Reliability and connectivity problems led to the next generation of Port Port Port Port

Ethernet employing 10Base-T.

Xceiver

Rx Tx

NIC a NIC b NIC c NIC d

In 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. Full-duplex connections are
supported, allowing any NIC to transmit at any time that it had data
available for transmission.

And this is where the duplex conflicts began.

Page 2
 Technical White Paper Series
Duplex Conflicts

Conflict on Hubs Conflict on Switches

Once NICs started to support full-duplex (FDx), hub-based systems Switches require setting of duplex mode on a per-port basis. The port
were affected by any NICs that were set to full-duplex. setting must match the settings of the device attached to the port.

������ �������� �� ���� �� �������� � ���� �������� ��� �� ����������� ������ �������� �� �������� �� �������� � ���� ��������� ������ �������� ������� ���� ��
������� � ������� � ��� ������������� ������ ����

Duplex Conflict on Hubs Conflict - FDx not allowed on hub ������ �������� �� �������� �������� � ���� ����� �� � ���� ���� �� ��� ��� ����
Diagram B ������� �

Recall that a hub can only support one transmitting station at a time.
When Station B (in Diagram 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.
In Duplex Conflict on Switches - Diagram A, traffic will flow smoothly
between Station A and Station B because each station’s duplex setting
matches that of the corresponding switch port.
In Diagram B, traffic will flow correctly between Station A and its
switch port. However, if Station A sends data to Station B, the duplex
conflict between Station B and the switch can cause packet collisions.
Station B does not detect collisions. Station B’s full-duplex setting will
cause it to transmit regardless of the state of its receive line. As Station
B’s switch port is set to half-duplex, restricting the port from receiving
while it is transmitting, Station B’s packets will be lost.

Page 3

Duplex Conflicts
Auto-Negotiate
Supposedly the solution to the duplex conflict, auto-negotiation has
actually made the problem even more insidious. Typically duplex
auto-negotiation techniques for NICs, switches and routers are either
obscure or incorrectly implemented.
Most of us have seen auto-negotiate settings on NICs, switches and
routers. Logic suggests that using auto-negotiate settings either at
the NIC or at a port will ensure proper negotiation of the duplex
setting. The sensible outcome would be if the interfaces settled on
the most favorable duplex setting.
The problem is that there is no clear standard that defines auto-
negotiation. In a practical sense, we have seen many implementations
and interpretations of this so-called feature.
Commonly, auto-negotiate means that, when the link is established
(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.
������ �������� �������������� ��� ���� � �������� ����� �� ������ ��������������
The illustration above is an example of this behavior on a common
switch device that Apparent Networks tested with AppareNet. We
set the 100 Mbps switch ports to auto-negotiate mode, and tested
with NICs from three different vendors. We set each card to auto-
negotiate, half-duplex and full-duplex. In each case, a duplex conflict
occurred. Furthermore, the switch often reported the negotiated
duplex mode incorrectly. For example, if the NIC was set to full-duplex,
the switch would report that it had negotiated full-duplex, however
AppareNet still identified that a duplex conflict was present.
Technical White Paper Series
Only by explicitly setting both sides of the link to the same duplex
mode would the link work at optimum performance.
To deal with this problem, many switches have received microcode
updates that change the behavior of their auto-negotiate mode. This
revised 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 duplex conflict and subsequent packet
loss is less likely.
Apparent Networks has set up test cases where a station is set to full-
duplex mode, and the switch is set to auto-negotiate. We do not see a
conflict between half and full-duplex, but AppareNet 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.
This example of auto-negotiation sacrificed performance to address
the inability to accurately negotiate duplex modes.
Measuring Path Bandwidth
Unlike most other technologies that can measure traffic throughput
or "what the network is doing", AppareNet is unique in its ability
to measure "what the network can do" from API to API along any
IP test path. AppareNet can also distinguish whether an end-to-end
path is working at half or full-duplex.
The diagram below is an example where AppareNet has measured the
last hop of an end-to-end test path as half-duplex Ethernet.
The reported bandwidth is slightly less then the expected 9.75 Mbps
(Ethernet 10 Mbps half-duplex less IP overhead). The slight variations
in bandwidth measurement are dependent on clock speed in the NIC
of the target device.
Page 4

Duplex Conflicts
Here is an example where AppareNet reports a full-duplex Ethernet
bandwidth:
Again, the measured capacity is slightly less then the theoretical
maximum of 19.5 Mbps (a two-way measure) for a 10 Mbps full-
duplex link.
Finding Duplex Setting Problems
Existing tools and network management technologies have been
unable to adequately identify and control the pervasiveness of
duplex problems in IP networks.
AppareNet’s sophisticated analysis of test packets, after they return to
the AppareNet sequencer, (the single-end test measurement probe)
allows the system to identify problem "signatures", and report
findings to the user with clear diagnostic information.
The following is an example of AppareNet’s identification of a duplex
conflict.
AppareNet can uniquely identify which interface has which duplex
setting. "Half/full-duplex" indicates that the half-duplex setting
is on the interface closest to the sequencer. "Full/half-duplex"
indicates the converse.
AppareNet has isolated the half/full-duplex problem at a particular
IP address. Hence, a technician can now quickly isolate the location
of fault, and apply the necessary adjustments to the settings on one
or both ends of the problem link.
Technical White Paper Series
Once resolved, AppareNet can run the test again to verify a clean
network path (i.e. Full-duplex 100 Mbps Ethernet).
Resolving Duplex Setting Problems
Apparent Networks encourages and recommends that most
enterprises with large networks should not use auto-negotiate.
However, in practice it is difficult to enforce in dynamic networking
environments. A related challenge is that several brands of network
adapters default to auto-negotiate at installation time, thus making
conflicts more likely.
AppareNet is the perfect tool for taking control of duplex conflicts.
Regular testing of your IP network using AppareNet reveals
conflicts and slowdowns on your network instantly. The test reports
pinpoint exactly where network technicians need to apply fixes to
duplex settings on network equipment. AppareNet allows network
operators to identify and eliminate duplex problems, and maximize
the performance and ROI of existing infrastructure.
Emerging Ethernet Standards
As a final note, 1 Gbps links work only in full-duplex mode and the 10
Gbps standard disallows half-duplex operation. However, anticipate
that Gbps Ethernet’s jumbo frames will be responsible for a whole
new raft of issues, such as MTU misalignments.
AppareNet can also be leveraged to identify and isolate MTU
misalignments. This is a separate white paper topic from Apparent
Networks.
For further information on AppareNet, or to see it live, please contact
us at marketing@apparentnetworks.com or toll free at 1.800.508.5233
or visit our website at www.apparentnetworks.com.
Page 5