I always auto-negotiate on anything deployed in the last 5 years for two reasons:
1) I've seen more undetected "errors" from mis-configured manual speed/duplex on a link, than problems prevents by hard-coding devices. 2) As a praticle matter, most new deployment seem to be gigabit and copper gigabit standard does not permit behavior #2 (or not using auto-neg). I do agree, it would be nice to be able to "participate in auto-negotiation, but only offer the configured settings" as a configuration option. On Sun, Aug 22, 2010 at 12:37 AM, Ziv Leyes <[email protected]> wrote: > Funny, that is, but the "YMMV" here is the most proper way to point this. > I've had experience with so many different problems between devices that I > try first to leave it as is (autoneg) but on the first time one of the > devices causes a problem I hardcode it. > I've seen problems when connecting customers back end with a Telindus 1030 > router to a cisco 1841 router where in some cases the auto negotiation went > fine, and sometimes it didn't, and some cases hardcoded caused CRC errors, > so I had to evaluate every single case, and we're talking about the same > both make and models on similar environments, so what would you suggest me > to do? > What I just did was to see if the auto worked, and then tried the manual, > but IF the manual caused problems then I had to make the guys at the E1 > circuit carrier make some adaptations in the shaping of the line. > Every time I had to connect a new customer all we had to do is plug and > pray... > See, sometimes is not only up to IEEE 802.3 stuff, but also on how every > device handles the stuff. > > > -----Original Message----- > From: [email protected] [mailto: > [email protected]] On Behalf Of John Neiberger > Sent: Friday, August 20, 2010 4:46 PM > To: [email protected] > Subject: [c-nsp] Why hard-setting speed and duplex on Fast Ethernet is bad > > 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/ > > > > > ************************************************************************************ > This footnote confirms that this email message has been scanned by > PineApp Mail-SeCure for the presence of malicious code, vandals & computer > viruses. > > ************************************************************************************ > > > > > > > > ************************************************************************************ > This footnote confirms that this email message has been scanned by > PineApp Mail-SeCure for the presence of malicious code, vandals & computer > viruses. > > ************************************************************************************ > > > > > _______________________________________________ > 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/
