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

[John Neiberger]

As I mentioned, if you are connecting two "behavior #1" devices
together or connection two "behavior #2" devices together, manually
setting speed and duplex will work. If it worked for you, now you know
why it worked. If you try to connect a "#1" to a "#2", you will get a
duplex mismatch.

There are times when you need to manually configure these settings,
but it helps to know why things are working the way they are. It took
me a long time to figure this out. I eventually got the answer by
talking to a guy who writes NIC drivers.

On Fri, Aug 20, 2010 at 8:28 AM, Keegan Holley
<keegan.holley at sungard.com> 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...
> 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/
>>
>>
>
>
>
>