Re: "Forcing" gigabit link operation

"Rick Jones" <rick.jones2@xxxxxx> wrote in message news:_nGTf.4995$yI2.3571@xxxxxxxxxxxxxxxxxxx
IIRC strictly speaking, autoneg is simply about duplex settings, and
the speed stuff was part of the "autosensing" part of the specs, but
then I don't really do Ethernet to pay my mortgage, so I'm sure I have
some parts wrong.

I've seen a few devices even "autosense" the speed incorrectly.

Long ago, and far away, when autoneg was "optional" there were:

a) some devices that supported FD, but didn't do autoneg

and perhaps more to the point

b) combinations of switches and NICs that would not autoneg with one
another. And either an inability or unwillingness among either the
switch vendor, NIC vendor or end-user to fix or replace the kit
that didn't quite work right.

Unfortunately, this is still the case today with some vendors. It's getting rarer, but it's still common enough to drive admins nuts. And some vendors are _still_ making equipment that doesn't do auto at all.

Also, most of that older equipment still doesn't work right, even with the latest software, so every datacenter will have switch/NIC combos that just won't autoneg right no matter how hard you try. Forcing a few ports here and there while leaving the rest at auto is difficult to maintain; it's easier to force everything.

and

c) people (network administrators among them) who didn't fully
understand how autoneg was supposed to work and ass-u-me-d that
they could leave one side at auto and hardcode the other to "force"
the mode they wanted. That it happened to "work" when the "forced"
side was half-duplex was most unfortunate, but required as part of
the spec since autoneg was indeed optional.

Those have left a nearly indelible mark on many network administrators
who at the time decided that life was implest if they hardcoded
everything. And that gets repeated all the time. One of the finest
examples of "You never get a second chance to make a first impression"
I've come across in a while.

Very true. I think there's also a bit of:

d) people don't like leaving performance to chance when their job is on the line; why leave something as "auto" and pray that it works when you can force a setting and be sure it works?

I've no idea if it might have been helpful or even possible for the
spec to say something like "If an autoneg capable device is
administratively forced to a non-autoneg setting and sees an autoneg
request from the link-peer, that device is required to report an error
condition and not enter an operational state.

I'd prefer the standard require that if a device is forced to a particular setting, it responded to auto-neg requests with the forced setting only instead of being silent. That'd clean up 99% of the issues I've seen.

I'd like it even better if auto-neg hadn't been optional, which would have forced the issue earlier and made it more likely the kinks would have been worked out long before products hit mass deployment.

I'd have been happiest if half-duplex had simply been disallowed starting with FastE, but I know the economic reality of switching at the time wouldn't have made that possible. Still, it'd have removed the need for auto-neg entirely: 10 meg is HDX, 100+ meg is FDX, end of story.

I just got back from a customer site where they have 80,000 switch ports all forced to 100/full; my product (which will be attached to roughly half of those ports, randomly distributed) does auto only. They went nuts when they realized the implications...

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

*** Free account sponsored by SecureIX.com ***
*** Encrypt your Internet usage with a free VPN account from http://www.SecureIX.com ***
.

Relevant Pages

  • SUMMARY: gigabit - fix spd/dpx on the switch ? or autoneg ?
    ... an option to FIX to 1000/Full when the gigabit standard doesnt support being ... which subsequently appears like this on the switch ... 1000/FUll actually does what the e1000g configuration is doing .. ... If you look at the output from the box that has autoneg set on the ...
    (SunManagers)
  • Re: issues with Intel Pro/1000 and 1000baseTX
    ... It's connected to a HP Procurve 1700-24 switch which supports 1000baseTX ... have a much older end user system which uses the same card (but earlier ... runs Windows XP and is plugged in to port 23. ... try autoneg on both ends. ...
    (freebsd-questions)
  • Re: issues with Intel Pro/1000 and 1000baseTX
    ... It's connected to a HP Procurve 1700-24 switch which supports 1000baseTX ... have a much older end user system which uses the same card (but earlier ... runs Windows XP and is plugged in to port 23. ... try autoneg on both ends. ...
    (freebsd-stable)
  • Re: issues with Intel Pro/1000 and 1000baseTX
    ... It's connected to a HP Procurve 1700-24 switch which supports 1000baseTX ... have a much older end user system which uses the same card (but earlier ... Try forcing on both ends (I assume the Procurve will allow you to do that). ... try autoneg on both ends. ...
    (freebsd-stable)
  • Re: issues with Intel Pro/1000 and 1000baseTX
    ... It's connected to a HP Procurve 1700-24 switch which supports 1000baseTX ... have a much older end user system which uses the same card (but earlier ... Try forcing on both ends (I assume the Procurve will allow you to do that). ... try autoneg on both ends. ...
    (freebsd-questions)