Autonegotiation

autonegotiation vs hard-set 100/full

I can only guess that you 'see it all the time' in certain specific classes of device. Namely, those with older or dodgy NICs. I've seen it too, on (for instance) older JetDirect cards or Sun workstations. So yes, for certain kinds of old NIC, it is wise to hard-set speed/duplex on both NIC and switch port.

But I have done a *lot* of testing of this, using Cisco 650x, 400x, 450x, 29xx, 35xx switches. I had to do all this testing because we had a guy like you, who just would not believe that autoneg works properly in this day and age. I had a whole test matrix; different OS's, different NICs, different switches, all combinations of settings at switch and endpoint. I used Iperf to do the testing.

Conclusion: any NIC I could find that had been built after the year 2000, worked just fine and got the best transfer speeds with both switch and endpoint on auto/auto. (Speeds equal to, or marginally faster than hard-setting 100/full at both ends). Some older 3c509 cards had intermittent problems.

We had been running in a 'hard-set every switch port and every endpoint' way for about a year and a half. The real problem under that strategy was: these days almost everything defaults to autoneg, so every user and helpdesk person had to remember to verify that setting everytime they bring up a new box or experience a suspected network slowdown. That doesn't seem like much, but it builds up as time goes by. Since the 'default autoneg' clients would be guaranteed half duplex, it resulted in a lot of 'slow net' tickets. In some cases, merely updating a network driver would reset the NIC back to autoneg!

After all my test results finally convinced the diehard guy, we went through the pain of changing everything (except a few older devices) back to auto/auto at both device and switch, and defaulting all ports to auto/auto except for those older devices. Over the next 8 months we tracked a 70% decline in 'slow net' tickets and a 40% decline in the amount of time it took to resolve the 'slow net' tickets we did still get. All of this in a development-heavy environment where many of our users needed to download large builds every workday, and hated even a few extra seconds waiting for the download to occur.

So yes, I can definitely say 'been there, done that'. Obviously my environment and yours are not the same - you may have some special circumstance which is skewing your experience from the norm. But almost every time I see someone make this claim, it turns out that they are going on old, pre-millenium knowledge that's out of date today.

Links:

• Recommending autoneg
  • Cisco: Configuring and Troubleshooting Ethernet 10/100/1000Mb Half/Full Duplex Auto-Negotiation
  • Cisco: Troubleshooting Cisco Catalyst Switches to NIC Compatibility Issues
  • Wikipedia: Duplex_mismatch
  • ISAserver.org: More Information About NIC Autoconfiguration: Gigabit NICs
  • Sun: Ethernet Autonegotiation Best Practices "Locked-down port policies (forcing speed, duplex, and link capabilities with autonegotiation disabled) are outdated."
• Recommending manual speed/duplex settings
  • University of Illinois: Ethernet auto-sensing and auto-negotiating (excellent history, but note the date of the paper: Oct 2000)
  • ISA Server Product Team: ISA Server Troubleshooting; Layer 1 (he suggests that autonegotiation "represents an unnecessary delay in the network setup process", but Cisco shows that autoneg occurs in microseconds, so I suggest he is misinformed)