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