[c-nsp] Why hard-setting speed and duplex on Fast Ethernet is bad

[Adam Armstrong]

On 20/08/2010 15:28, Keegan Holley wrote:
> I disagree completely.  I have run into the behavior you mentioned and gone
> back to auto, however I've had more problems with auto than with statically
> setting duplex.  Devices rebooting and somehow coming to the wrong
> conclusion about speed and duplex (followed by the 4 hour witch hunt).
>   Devices simply not able to come to an agreement, etc... More often than not
> I've seen devices just work when hard coded, sometimes there is a third
> setting in the server to disable negotiation.  Also, if one device is
> negotiating and the other does not the first devices can look at the speed
> at which the frames are coming in and set it's speed accordingly.  To each
> his own though...

I'd be interested in specifics of which devices you have had "rebooting 
and somehow coming to the wrong conclusion about speed and duplex", when 
did this happen? What were the devices on both sides?

Collect together the data from all of these events, and I'm pretty sure 
you'll find that you're crippling a very valuble feature of modern 
network hardware to work around old and broken hardware.

This is a bad thing to do, though, it's quite common for such 
misconceptions to persist in our industry (people still still use 
classful addressing terminology (in a manner which was inaccurate even 
when classful addressig was relevant), SEO people still go on about 
requiring dedicate IP per site, etc, etc).

Though I suppose, it only serves to make those of us who take the time 
to learn about the issue and do things properly look better than those 
who fail to understand the issue and run off screaming about the autoneg 
boogeyman :)

(Yes, I am intending to insult those who still cling to forcing 
speed/duplex, as shame is a good motivator)

adam.