3 ms·

My favorite thing like this for a purely technical topic was a project where there was a mandatory requirement to NOT support ethernet auto-negotiation. Why? T

by Duff 15y ago

My favorite thing like this for a purely technical topic was a project where there was a mandatory requirement to NOT support ethernet auto-negotiation. Why? The company had a long-standing policy of manually setting speed and duplex to ensure that there were no duplex mismatches. The was a team of 6-7 people who would audit servers and check switchports, and they produced a report was issued every week, and reviewed by the CIO and other luminaries. People would be shamed for errant configurations, as only the auto-negotiation team could configure NICs. The director who controlled the auto-negotiate squad was politically powerful, and got all sorts of power out of it -- including banning GigE. As late as 2010, this org was deploying dozens of 100MB NICs to ESX hosts to get sufficient bandwidth. They also purchased 100MB NICs for desktops.

rhizome 15y ago
I don't know if you were around 10 years ago, but there used to be real problems between certain network cards and switches that prevented autoneg from being 100% reliable. For any company of a certain age I would not be surprised to see a policy like the one you describe.
- phuff 15y ago
  For a long time that was my first question anytime there was a network problem that wasn't a simple solve on the client. Step 1: Disable/Enable interface Step 2: Call NOC: "Can you tell me what this port is autonegotiated to?"
- quanticle 15y ago
  The surprising thing isn't the policy. The surprising thing is the persistence of the policy even after it's no longer beneficial in any way. It's been more than a decade since Ethernet auto-negotiation became reliable. During that decade, that company has paid for a team to go around and do manually what could have been done by an automated process for a trillionth of the cost. That's a staggering amount of waste.
  - rhizome 15y ago
    The policy has to be proven to no longer be beneficial, and I'm pretty sure every major OS has had a way to remotely set the card to a fixed configuration or autoneg since around then, but that's a separate issue.
    - WettowelReactor 15y ago
      Thats why policies, like contracts, should never be evergreen. Policies simply amount to internal contracts and any company that does not regularly review and refresh them is doomed to this kind of waste.
      - contextfree 15y ago
        But who will regularly review the policy on reviewing the policy on regular review of policies?
      - rhizome 15y ago
        Have you ever worked at a company big enough to have IT policies like this?
        WettowelReactor 15y ago
        like the parent or evergreen? No I have never worked anywhere that promoted such abject waste through "adherence to policy" but I likely would not have chosen to work at such a place to begin with.
- Duff 15y ago
  Absolutely... IIRC, the IEEE standard was ambiguous, and each vendor implemented things differently. I think the standard was "fixed" in 1999... This situation happened in 2009! But the technical problem wasn't the problem -- the issue was that they created an inquisition that had outlived its purpose.
- wnight 15y ago
  And horseless carriages used to be less reliable than horses. The problem is the longstanding nature of the policy. They were paying a team of 6+ techs, surely they could afford a process-review/technical updating meeting once a year? And surely there's a better way, such as standardizing on a brand of NICs and of switches, and being done with it. If you can't push an update to the machines to prevent this anyways. Besides, it shouldn't cause cascading failure so the worst case scenario is a tech call, the same as for an unplugged cable.
tlipcon 15y ago
Several comments here indicate that this practice is outdated. I disagree strongly. Even in 2011 autoneg is flaky on many switches - in a recent shipment of ~100 machines, ~5 of them autonegotiated to 100mbit instead of gigabit. And these are name-brand machines with name-brand switches. Forcing duplex and speed with ethtool is still relevant.
- chrisbolt 15y ago
  It sounds like you have either crap NICs or crap cables.

by Duff 15y ago

rhizome 15y ago

I don't know if you were around 10 years ago, but there used to be real problems between certain network cards and switches that prevented autoneg from being 100% reliable. For any company of a certain age I would not be surprised to see a policy like the one you describe.

phuff 15y ago
For a long time that was my first question anytime there was a network problem that wasn't a simple solve on the client. Step 1: Disable/Enable interface Step 2: Call NOC: "Can you tell me what this port is autonegotiated to?"
quanticle 15y ago
The surprising thing isn't the policy. The surprising thing is the persistence of the policy even after it's no longer beneficial in any way. It's been more than a decade since Ethernet auto-negotiation became reliable. During that decade, that company has paid for a team to go around and do manually what could have been done by an automated process for a trillionth of the cost. That's a staggering amount of waste.
- rhizome 15y ago
  The policy has to be proven to no longer be beneficial, and I'm pretty sure every major OS has had a way to remotely set the card to a fixed configuration or autoneg since around then, but that's a separate issue.
  - WettowelReactor 15y ago
    Thats why policies, like contracts, should never be evergreen. Policies simply amount to internal contracts and any company that does not regularly review and refresh them is doomed to this kind of waste.
    - contextfree 15y ago
      But who will regularly review the policy on reviewing the policy on regular review of policies?
    - rhizome 15y ago
      Have you ever worked at a company big enough to have IT policies like this?
      - WettowelReactor 15y ago
        like the parent or evergreen? No I have never worked anywhere that promoted such abject waste through "adherence to policy" but I likely would not have chosen to work at such a place to begin with.
Duff 15y ago
Absolutely... IIRC, the IEEE standard was ambiguous, and each vendor implemented things differently. I think the standard was "fixed" in 1999... This situation happened in 2009! But the technical problem wasn't the problem -- the issue was that they created an inquisition that had outlived its purpose.
wnight 15y ago
And horseless carriages used to be less reliable than horses. The problem is the longstanding nature of the policy. They were paying a team of 6+ techs, surely they could afford a process-review/technical updating meeting once a year? And surely there's a better way, such as standardizing on a brand of NICs and of switches, and being done with it. If you can't push an update to the machines to prevent this anyways. Besides, it shouldn't cause cascading failure so the worst case scenario is a tech call, the same as for an unplugged cable.

tlipcon 15y ago

Several comments here indicate that this practice is outdated. I disagree strongly. Even in 2011 autoneg is flaky on many switches - in a recent shipment of ~100 machines, ~5 of them autonegotiated to 100mbit instead of gigabit. And these are name-brand machines with name-brand switches. Forcing duplex and speed with ethtool is still relevant.

chrisbolt 15y ago
It sounds like you have either crap NICs or crap cables.