AutoNegotiation

Inside the enterprise, if you don't consider autonegotiation to be a best practice, perhaps it's time you reconsidered that idea.

Back in the mid 1990s, there were numerous problems with autonegotiation.  Those problems came about because of poorly written NIC drivers, ambiguous portions of the standard (802.3u), and vendor specific implementations.  The ambiguous portions of the standard were rectified in 1998, but there was still a significant amount of NIC drivers that didn't get updated.  There was also a problem of legacy equipment which didn't get updated and hung around for years.  This problem of poor interoperability was solved by hard coding both ends of an Ethernet link.  Hard coding was an acceptable solution.  Luckily, those times are well behind us, and it's time to reconsider the best current practices.

802.3ab, which defines gigabit Ethernet, required autonegotiation for some implementations.  It is required for 1000BaseT operation because 1000BaseT negotiates more than just speed and duplex.  Speed, duplex, master/slave clocking, and flow control are all negotiated with 802.3ab.  If you decide to violate the standard and hard code the speed and duplex to 1000/full, you can still run into performance issues because of a clocking problem.  For those that aren't familiar, clocking is analogous to a drum beat to get both parties marching in sync.  The master is decided by a priority & dispute mechanism.  Devices which have multiple ports have a higher priority than single port devices, and the highest priority wins.  In the event of a tie, a random seed breaks the tie.  The master uses his local clock, while the slave recovers the time from the received signal.

As we look at the next generation interfaces, DCE (Data Center Ethernet), CEE (Converged Enhanced Ethernet), and P802.3ba (40/100 GigE) you can be sure we're going to see more mandatory use of autonegotiation.

For the past few years I have been managing two data centers where a large number of servers are regularly moved, added and removed.  Between the two data centers, consisting of approximately 7000 Ethernet ports, I have encountered one instance of autonegotiation failing when both sides were set to auto/auto.  That one instance was 4 years ago, between a Nokia IP740 and a Cisco 2950G switch.

Over the past 10 years, the maturity of the currently available drivers and clearly defined standards has proven autonegotiation to be a reliable performer.  If you still choose to hard code, as the list of settings that require manipulation grows with time, so will the likelihood that configuration mistakes (causing performance issues) will outnumber autonegotiation issues.