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

Sun Aug 22 02:37:27 EDT 2010

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.
************************************************************************************