On Sat, 29 Oct 2005, Dag Nygren wrote:
DN> And here is a third one!
DN> I installed 10 -20 bigger Networker systems last year and saw
DN> about 50% of these failing to negotiate decently under auto-negostiate.
DN> Usually they ended up with one end 100/half and the other 100/full.
And both ends were configured to auto-negotiate?
DN> So IMHO it is really stupid to trust the auto-stuff. And most of the times
DN> you dont't even nitice the poor performance until installing Networker...
DN>
DN> And it is REALLY hard to convince the network-guys that Their Network
DN> has a flaw in it ;-)
True, since I'm the network guy as well, or at least one of them, at our
site. :)
Anyway, I feel like saying "You're probably all wrong, or you use crappy
switches, or fail to correctly set both ends to auto-negotiate or possibly
all of the above!". :) But I won't, since I'm such a nice guy.
Instead I'll include an URL on Cisco's website, that deals somewhat with
this topic:
http://www.cisco.com/en/US/tech/tk389/tk214/technologies_tech_note09186a0080094781.shtml
One interesting part is:
"When to Use Ethernet 10/100Mb Auto-Negotiation
Auto-negotiation is an optional function of the IEEE 802.3u Fast Ethernet
standard that enables devices to automatically exchange information over a
link about speed and duplex abilities.
Auto-negotiation is targeted at ports which are allocated to areas where
transient users or devices connect to a network. For example, many
companies provide shared offices or cubes for Account Managers and System
Engineers to use when they are in the office rather than on the road. Each
office or cube will have an Ethernet port permanently connected to the
office's network. Because it may not be possible to ensure that every user
has either a 10Mb, a 100Mb Ethernet, or a 10/100Mb card in their laptop,
the switch ports that handle these connections must be able to negotiate
their speed and duplex mode. The alternative would be to provide both a
10Mb and a 100Mb port in each office or cube and label them accordingly.
One of the most common causes of performance issues on 10/100Mb Ethernet
links is when one port on the link is operating at half-duplex while the
other port is operating at full-duplex. This occasionally happens when one
or both ports on a link are reset and the auto-negotiation process doesn't
result in both link partners having the same configuration. It also
happens when users reconfigure one side of a link and forget to
reconfigure the other side. Both sides of a link should have
auto-negotiation on, or both sides should have it off. Our current
recommendation is to leave auto-negotiation on for those devices compliant
with 802.3u.
Many performance-related support calls will be avoided by correctly
configuring auto-negotiation. Many Catalyst Ethernet switching modules
support 10/100Mb and half- or full-duplex. Exceptions include the Ethernet
Group switch modules. The show port capabilities {mod_num} |
{mod_num/port_num} command will show you if the module you are working on
supports 10/100Mb and half- or full-duplex. This document uses two
WS-X5530 Supervisor Engine IIIs, each with two optional uplink
10/100BaseTX Ethernet ports installed."
I would also like to recommend this document:
http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00800a7af0.shtml
And yes, I have seen several cases of where other network administrators
have claimed what has already been claimed about the suspected negative
effects of enabling auto negotiation. All of those cases ended up to be
related to the following errors:
* One end was configured for auto negotiation, or the two ends of the link
didn't match the speed/duplex setting.
* Some 3com cards were per default set, in windows, to use "hardware
default" instead of auto negotiate, which for some reason wasn't the
"hardware default" setting.
However, considering the number of reports, its also probable that some
low-end switches and/or NIC's haren't 100% compliant with the 802.3u
standard. But if one runs backups, I guess one wouldn't use that range of
equipment anyway? :) I can't think of an adapter based on Intel, 3com or
broadcom chipsets that has had any problem with this in at least five
years.
I understand that this thread has become somewhat offtopic, and
furthermore, I don't think I have much more to say about this issue, so
this will probably be my last post in this thread. But it would be
interesting for me to know as a network administrator what specific NICs
and switches are having problems with auto negotiation. Who knows, I might
bump into those combinations one day. Email me off-list.
//Oscar
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu
if you have any problems
wit this list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
