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

[P C]

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 <zivl at gilat.net> 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: cisco-nsp-bounces at puck.nether.net [mailto:
> cisco-nsp-bounces at puck.nether.net] On Behalf Of John Neiberger
> Sent: Friday, August 20, 2010 4:46 PM
> To: cisco-nsp at puck.nether.net
> 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  cisco-nsp at puck.nether.net
> 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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>