Did anyone happen to see the recent article by blogger Joel Spolsky which in passing seems to advise disabling auto-negotiation in "mission critical" environments?
formatting link
Paragraphs 7-9 contain the part I'm curious about.
I infer from the article that Joel's company disables auto- negotiation as a matter of policy on all Ethernet equipment in their data center. Is that a common practice? Would you recommend it? (I know that there were compatibility problems with different implementations when auto-negotiation was first introduced, but I assume we're talking about "modern" equipment ;-)
BTW, the conclusion of the "Ethernet Autonegotiation Best Practices" document from SUN Microsystems is a recommendation to leave auto- negotiation enabled, but I'm not sure they are addressing the same "mission critical" installation issue Joel Spolsky is talking about. (See
formatting link
I also wonder about the analysis that auto-negotiation was the cause of the failure. There aren't any details in the article, but the link in question was up for some time and then failed. If it was working properly for a time, presumably auto-negotiation also worked when the link came up. How could auto-negotiation have caused it to fail later? (I'm not saying it couldn't. I just wonder how it could have.)
In the case where both ends are under the same administrator, and locked in a wiring closet it might make sense. For ports that go to user machines where ordinary users can move plugs around, I would say no.
I'm not sure I'd even do it in the first case Glen mentioned, but my feelings there aren't strong.
If the article were written oh 5-10 years ago I might have grudgingly agreed with it because much kit didn't do autoneg right, but "today" unless someone is buying some really lame kit, autoneg should "just work."
It is also the default on everything (?) which means if you did hardcode, and forgot to configure it that way on a new peice of kit, or someone resets that kit to factory defaults, you are in a realm of Sorrow and Woe.
A bit long in the tooth now, since it talks about 100BT but it still applies:
How 100Base-T Autoneg is supposed to work:
When both sides of the link are set to autoneg, they will "negotiate" the duplex setting and select full-duplex if both sides can do full-duplex.
If one side is hardcoded and not using autoneg, the autoneg process will "fail" and the side trying to autoneg is required by spec to use half-duplex mode.
If one side is using half-duplex, and the other is using full-duplex, sorrow and woe is the usual result.
So, the following table shows what will happen given various settings on each side:
Auto Half Full
Auto Happiness Lucky Sorrow
Half Lucky Happiness Sorrow
Full Sorrow Sorrow Happiness
Happiness means that there is a good shot of everything going well. Lucky means that things will likely go well, but not because you did anything correctly :) Sorrow means that there _will_ be a duplex mis-match.
When there is a duplex mismatch, on the side running half-duplex you will see various errors and probably a number of _LATE_ collisions ("normal" collisions don't count here). On the side running full-duplex you will see things like FCS errors. Note that those errors are not necessarily conclusive, they are simply indicators.
Further, it is important to keep in mind that a "clean" ping (or the like - eg "linkloop" or default netperf TCP_RR) test result is inconclusive here - a duplex mismatch causes lost traffic _only_ when both sides of the link try to speak at the same time. A typical ping test, being synchronous, one at a time request/response, never tries to have both sides talking at the same time.
Finally, when/if you migrate to 1000Base-T, everything has to be set to auto-neg anyway.
I probably wouldn't either, but I could see it as a possibility. It would also have to be only me doing the administrating so that I wouldn't consider anyone else messing things up. Mission critical means lots of documentation, though. Good locks to keep others away from things they shouldn't touch...
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.