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

[Keegan Holley]

I don't disagree with that point.  I guess the times where I've see a
behavior 1 device and a behavior 2 device have been few and far between
though.  YMMV though.

On 8/20/10 10:35 AM, "John Neiberger" <jneiberger at gmail.com> wrote:

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

Keegan Holley ▪ Jr. Network Architect  ▪ SunGard Availability Services ▪ 401
North Broad St. Philadelphia, PA 19108 ▪ (215) 446-1242 ▪
keegan.holley at sungard.com Keeping People and Information Connected® ▪
http://www.availability.sungard.com/
 
P Think before you print
CONFIDENTIALITY:  This e-mail (including any attachments) may contain
confidential, proprietary and privileged information, and unauthorized
disclosure or use is prohibited.  If you received this e-mail in error,
please notify the sender and delete this e-mail from your system.