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

[Keegan Holley]

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...

On Fri, Aug 20, 2010 at 9:46 AM, John Neiberger <jneiberger at gmail.com>wrote:

> Someone in the other thread mentioned that they were surprised to see
> that so many people were against manually configuring speed and
> duplex, so I thought I would explain why this is a bad idea most of
> the time.
>
> The Fast Ethernet standard does not mention how devices are supposed
> to behave when manually configured. It only deals with Nway
> autonegotiation. The problem is that there are two possible behaviors
> when settings are manually configured:
>
> #1:  Participate in Nway, but only offer the configured settings
> #2:  Disable Nway entirely and run at the configured settings
>
> Cisco's older switches, like the XL series, used behavior #1, as do
> most PC/Server NICs that I've run across for that past eight years or
> so. Beginning around the time the 2950s came out, Cisco decided to
> switch to behavior #2. If you connect two devices that use behavior
> #1, you'll be fine. If you connect two devices that use behavior #2,
> you'll be fine. But what happens if you connect a "#1" device to a
> "#2" device? You get a duplex mismatch! The device that still
> participates in Nway is going to expect to see an autonegotiating link
> partner. When it doesn't detect one, it follows the standard and
> assumes it is connected to a hub or some device that can't do full
> duplex and it falls back to half duplex, often without telling you.
> This creates input errors on the full duplex side and late collisions
> on the half duplex side. If you have hard-set your speed and duplex on
> a Cisco switch and you're seeing a lot of input errors, you likely
> have a duplex mismatch because of this problem. Setting BOTH sides to
> auto usually resolves this issue.
>
> Auto is the only reliable way to go these days unless you know ahead
> of time which of the two behaviors your devices are choosing. If you
> don't know, autonegotiation is the most likely way to get a good
> connection at 100/full.
>
> I hope that helps clear some of that up.
>
> -John
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>