whitepaper duplex aug2002

8/6/2019 Whitepaper Duplex Aug2002

http://slidepdf.com/reader/full/whitepaper-duplex-aug2002 1/7

l � � � l l l

l l l l l

l



Technical White Paper SerieDuplex Conicts

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

identies 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’ businesse

by helping organizations reduce operational costs, increase IP availability, and protect revenues.

Contact Information

Canadian Head Ofce

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

[email protected]

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.




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 rst 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 conicts.

Executive Summary

A recent study concluded that duplex conicts (otherwise known as

duplex mismatches) cause 75% of all Internet/2 problems.* Most

Network Engineers have encountered such conicts, and understand

how elusive they can be. These conicts 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 conicts have become a prevalent performance inhibitor in

today’s network infrastructures. The nature of conicts 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 conicts in an IP network. Once the problem source

is isolated, a simple reconguration of the network equipment is

typically all that is required to achieve signicant and noticeable

improvements in IP network performance. AppareNet allows

organizations to maximize the performance and ROI of IP networking

infrastructures.

Duplex Conict/Mismatch

A duplex conict 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 simultaneou

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 initia

performance and data transfer rate is acceptable, but then, a

collisions and packet loss start to occur due to a duplex conict, the

TCP sliding window is progressively decreased until the performance

slows to a crawl.

Before AppareNet, there simply were no tools that reported duplex

conicts. It was nearly impossible to understand when or where

conicts and link degradations were occurring.

A brief look at the history of Ethernet reveals how and why duplex

conicts occur as often as they do.

Page

* Internet2, Fall 2001, End-to-end Performance Initiative




Brief History of Ethernet

Ethernet originally was either 10Base-2 or 10Base-5. Both avors

used transceivers connected via coaxial cable, carrying only one

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

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

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

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.

Reliability and connectivity problems led to the next generation of

Ethernet employing 10Base-T.

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

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.

In switches, the Tx and Rx wires are independent of each other

allowing simultaneous multi-direction transmissions. For the rst

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 conicts began.

Page 2

Switch

Rx

NIC a NIC b NIC c NIC d

Tx

Tx Rx

Switch Fabric

Xceiver

Port Port Port Port

Hub

Rx


Tx

Tx Rx

** Hub InternalConnection

* Tx and Rx joined here in the Hub

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

Xceiver

* Xceiver

Port Port Port Port



Tx


Rx

** Coaxial Cable

Tee Connector

* Tx and Rx joined here in the NIC

** Only one transmitting station allowed at one time

* Xceiver

** Coaxial Cable

Tee Connector

** Coaxial Cable

Tee Connector Tee Connector




Conict on Hubs

Once NICs started to support full-duplex (FDx), hub-based systems

were affected by any NICs that were set to full-duplex.

Conict on Switches

Switches require setting of duplex mode on a per-port basis. The port

setting must match the settings of the device attached to the port.

In Duplex Conict on Switches - Diagram A, trafc will ow smoothly

between Station A and Station B because each station’s duplex setting

matches that of the corresponding switch port.

In Diagram B, trafc will ow correctly between Station A and itsswitch port. However, if Station A sends data to Station B, the duplex

conict between Station B and the switch can cause packet collisions

Station B does not detect collisions. Station B’s full-duplex setting wil

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

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 trafc. This corrupts any frames that

are passing through the hub, resulting in packet loss.

Conflict - FDx not allowed on hubDuplex Conflict on HubsDiagram B

� � �

�

�

� �




The illustration above is an example of this behavior on a commonswitch 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 conict

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 identied that a duplex conict was present .

Measuring Path Bandwidth

Unlike most other technologies that can measure trafc 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 anyIP 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 Mbp

(Ethernet 10 Mbps half-duplex less IP overhead). The slight variation

in bandwidth measurement are dependent on clock speed in the NIC

of the target device.

Auto-Negotiate

Supposedly the solution to the duplex conict, 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 denes 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 nd that duplex

negotiations fail.

Page 4

� �

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. Thi

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 tha

is neither half-duplex nor full-duplex. Although performance i

degraded, the possibility of a duplex conict 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

conict 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 sacriced performance to address

the inability to accurately negotiate duplex modes.




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

ndings to the user with clear diagnostic information.

The following is an example of AppareNet’s identication of a duplex

conict.

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 difcult to enforce in dynamic networking

environments. A related challenge is that several brands of networkadapters default to auto-negotiate at installation time, thus making

conicts more likely.

AppareNet is the perfect tool for taking control of duplex conicts

Regular testing of your IP network using AppareNet reveals

conicts and slowdowns on your network instantly. The test report

pinpoint exactly where network technicians need to apply xes 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 nal 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 contac

us at [email protected] or toll free at 1.800.508.5233

or visit our website at www.apparentnetworks.com.

Page 5

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.

whitepaper duplex aug2002

Documents