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