Do you believe in the autonegotiation fairy?

Feel free to use autonegotiation on your switches and your NICs. For the most part, it works beautifully. But if you start seeing performance issues, while you might be thinking you have a bad NIC, autonegotiation might be the culprit.

A few months back, during The Tolly Group’s fourth-annual Switch Interoperability event we host with Network World, I couldn’t help but notice that all of the participating switch vendors passed our autonegotiation tests.

No big deal. The standard for autonegotiation is years old. Everyone does it, so it has to work, right? Well, it worked just fine on a switch-to-switch basis in our Switch Interop tests.

Like most people, I have come to accept and trust any switch’s autonegotiation capabilities at face value.

Recently, I had the misfortune of taking autonegotiation for granted. In a test at The Tolly Group lab facilities, I found out that not all autonegotiation algorithms are created equal. In this one instance, the lack of effective autonegotiation resulted in a 66% loss of throughput between a server and a client PC for no apparent reason.

We were performing a file transfer between an FTP server and an FTP client for a performance baseline, connecting the two machines via a Fast Ethernet hub. We achieved a file transfer throughput of 93M bit/sec. We took the same two FTP machines and plugged them into the switch under test (the vendor of which shall remain nameless) and ran the test again.

This time, throughput plunged to a meager 30M bit/sec. We couldn’t believe our eyes. To confirm there was nothing wrong with our test bed, we selected a different vendor’s switch and ran the same test again, changing no configurations, and we saw throughput restored to 93M bit/sec! Huh?

After countless hours trying to identify the reason for the extremely low throughput, we discovered an overabundance of frame checksum errors on the counters of the questionable switch. After a clearing of the counters and subsequent runs, it was clear that we had identified our issue. What could cause these errors? A colleague of mine recommended hard coding the speed and duplex. Much to my dismay, it solved our problems.

Autonegotiation had been the culprit! In our 3-minute throughput test, the autonegotiation between the switch and the client network interface card (NIC) renegotiated the data rate repeatedly switching between 100M bit/sec full duplex and 10M bit/sec full duplex – for no apparent reason.

How could this be? How could autonegotiation issues exist between a major switch and NIC products? This is not a new standard, it has been around for years. Does this mean I need to go out and have our IT department hard code speed and duplex settings for all machines in our company to guarantee maximum throughput? Or do I have to purchase all my gear from a single vendor? If this is the case – why do we have standards? Why claim to support a feature when it is broken?

Feel free to use autonegotiation on your switches and your NICs. For the most part, it works beautifully. But keep in mind if you start seeing performance issues, while you might be thinking you have a bad NIC, the fact is autonegotiation might be the culprit – especially if checksum errors abound.

It’s time the vendors throttle back on the new product conveyor and fix the fundamentals of existing products to give consumers reliable technology that works.

Tolly is a senior engineer with The Tolly Group, a strategic consulting and independent testing company in Manasquan, N.J. He can be reached at btolly@tolly.com. Kevin Tolly returns with the next column.