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. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
