Why You Don't Want to Force Link Modes

So, I got a message today, not uncommon, indicating that some poor guy is dealing with an IT organization that still requires link parameters to be forced to 100 Full.

It hardly seems reasonable that in today's day and age, folks wouldn't be using auto-negotiated link parameters, yet, there it is!

This blog entry is dedicated to those IT organizations stuck in the early 90's, still requiring their users to force link mode.

1. Back Story

Once upon a time, 100 Mbps full duplex 100Base-T was new. And in the early days, there was not universal adoption of a standard (in the very early days there wasn't a standard at all!) for autonegotiation of link speed and mode.

The IEEE 802.3 group (the folks that oversee the Ethernet standards) rectified this with a standard called "IEEE 802.3u", which provided the rules for auto-negotiation.

Most of the world, and pretty much all of the equipment manufacturers, adopted this standard in short order, and there was much joy and happiness.

2. Except....

That some IT organizations had older equipment, and had compatibility concerns. So, they insisted that that their users "force" the link parameters. This allowed everyone to take advantage of full-duplex operation in those organizations.

3. The Conflict

The problem with this situation is that disabling auto-negotiation on the switches in the machine room meant that the default auto-negotiation which all hardware shipped with enabled by default didn't work properly. With the back-end not doing 802.3u, the front end can't decide, and defaults to a "safe" mode of 100 Mbps half.

Of course, this safe mode causes all kinds of problems on its own, if the back-end is presuming full duplex is OK. (This will manifest as errors and collisions on the link, in bad cases it can make the link entirely unusable.)

4. IEEE Steps In

So, for the next round of standards for ethernet, the Gigabit standards, the IEEE required the use of auto-negotiation to select link speed and duplex. Its possible to control what is advertised/supported by a partner, but you must not disable auto-negotiation itself. The upshot of this is gigabit equipment is going to have difficulty with those backwards IT organizations that still require forced modes.

5. The Problem Today

The problem today is that some IT organizations have carried this practice on for years, leading to excessive support headaches, etc. They have avoided the one-time cost of transitioning to auto-negotiation, but they do so at the continued cost of support headaches resulting from this decision.

Added up over time, I expect that the support costs for dealing with problems from mismatched duplex settings due to one end having auto-negotiation administratively disabled probably totals in the millions of dollars. I'll leave the math to the bean counters, but its not trivial. (One of the problems is that each time a new OS or a new piece of equipment is added, someone has to figure out how to change the defaults. I've probably spent over a dozen hours helping people with this problem myself over the years -- which is silly because IMO nobody should have this problem, at least not outside of possible testing scenarios.

As another example of what can happen ... recognize that it is not always possible for end equipment to support full-duplex. All hubs, by definition, cannot support full duplex operation. So, what happens in your organization when some bloke wants to add a hub to get an extra Ethernet port? Does everyone in your IT department know about this limitation? (How many hours have been spent tracking down this particular problem, I wonder?) If auto-negotiation is used, it won't matter.. everything Just Works, regardless of whether the end user inserts a hub or a switch.

(Hubs are also extremely useful for performing network debugging, because it provides a point at which bits can be examined on the wire using tcpdump or snoop or similar tools. Obviously, this mode of debug is not available when organizations force the switch to use full-duplex operation.)

6. What You Can Do

If you're in an IT organization that boycotts 802.3u, consider strongly whether this practice is worth continuing. (I'd argue it isn't, at least if your organization ever grows.) New ports should be allocated without this requirement, old ports should be converted as they are able to be, if the organization can't convert them all at once.

In the era of 1G and 10G (notably 10G not only requires auto-negotiation, but also does away with half-duplex operation!), its past time that IT organizations caught up into the current millenium with their management strategies.

Feel free to repost this where your IT head of department will see it.

Comments

Popular posts from this blog

An important milestone

GNU grep - A Cautionary Tale About GPLv3

The Hand May Be Forced