Comments on: Blessay: Autonegotiation on Ethernet – It Works, It Should Be Mandatory!

By: Gowthaamm

Gowthaamm — Mon, 09 Jan 2012 03:20:00 +0000

I have a question, That is the behaviour of auto negotiation when one patry is 100Mbps macx and other partnet is 10G. I mean to say the connectivity at one end is slow and other end is high.

By: Gowthaamm

Gowthaamm — Mon, 09 Jan 2012 03:18:00 +0000

By: Nyte_byte

Nyte_byte — Mon, 21 Nov 2011 12:02:00 +0000

Article is mostly true, but there are still exceptions, although very rare. I have one desktop computer that refuses to negotiate properly and only sets itself to 100M when it should auto-negotiate 1000M. Doesn’t matter which brand switch you use on the back end or which cables, it never gets it right. Hard setting it to 1000M works perfectly and there are never any problems. I suspect it’s just the crappy on-board Ethernet adapter at fault here.

By: DX Mage

DX Mage — Fri, 14 Oct 2011 20:02:00 +0000

Clearly gryfalcon doesn’t understand that Cisco and Intel are competitors that routinely sabotage things like this for each other as they continue to this day continue to interpret and implement “standards” differently.

By: DX Mage

DX Mage — Fri, 14 Oct 2011 19:56:00 +0000

Unfortunately while I would like to agree this simply isn’t true. Intel NICs default to 100/half with the Cisco switches we have on campus. They have to be set manually at 100/full or they will jsut run 100/half no matter what is done. There are some driver versions that will work with some systems depending on the NIC chip that is on the system board (FYI Intel) I have hit this combination once. So while yes it is supposed to work it doesn’t at least on our campus of 2000+ systems but as I don’t have control of the campus network there isn’t anything I can do to get it fixed.

By: Bernard

Bernard — Fri, 30 Sep 2011 20:00:00 +0000

My rule of thumb has always been to auto-negotiate at the
access layer of the network and hardcode your uplinks to the distribution and
core. I rather have all of my backbone configured and not automatically
adjusting. I normally hardcode my ESX
and standalone servers just to maintain the consistency and predictability that
I like in environments. As a consultant, I have seen many issues with clients
and auto-negotiation between switches and routers/firewalls.

By: Autonegotiation | V6 Networks

Autonegotiation | V6 Networks — Tue, 06 Sep 2011 18:23:18 +0000

[...] really good engineers disagreed with me. To prove my case, I decided to do some research. Reading this and this initially reinforced my view. Scrolling down and reading the comments left me with a sense [...]

By: Dasfafgasfa

Dasfafgasfa — Mon, 25 Jul 2011 06:05:00 +0000

Thank you for your answer! Let’s say that the cables were tested with a LAN tester and the results were fine, but if “Auto” is on I get sometimes 100Mbps. If I force the “Link Speed” to work at 1Gbps, then I get it immediately and always. In case that I leave the “Auto” option as on, if I will disable and enable it again, will it start communicating at 1Gbps or once again I might get 100Mbps?
My personal opinion is; if I need two NICs to communicate in specific transfer rate then I must indicate it. “Auto” option works in general, if production environment doesn’t experience any issues, but if it does then you have take control of it!
I would like to know your opinion because our production environment experiences right now speed issues, and before I force all NICs to work at 1Gbps, I have to be sure.

By: Etherealmind

Etherealmind — Sun, 24 Jul 2011 21:33:00 +0000

Most likely you have faulty or poor quality cabling that causes this. But FLP is only done at initialization, I believe, so I wouldn’t expect the speed to change unless the connection bounces for any reason.

By: Dasfafgasfa

Dasfafgasfa — Sun, 24 Jul 2011 13:08:00 +0000

I have a question regarding the “Auto Negotiation”; I have 2 NICs which communicate at 1Gbps but then after a power recycle they start at 100Mbps. I would like to know if 100Mbps network speed connection’s sequence will remain until the cable will be unplugged or while the existing session they will try to up the speed back again to 1Gbps? Thank you in advance.

By: gyrfalcon

gyrfalcon — Sun, 17 Jul 2011 03:25:00 +0000

“If I have auto on both ends sometimes (due to cable/switch problems etc) the duplex is re-negotiated and speed is lowered.”…

Would you rather have the speed lowered, or the connected devices go down? Auto-negotiation is not your problem. Disabling auto-negotiation on Ethernet is about as stupid as disabling it on 802.11 wireless where it reduces the speed with a loss of signal.

Originally auto-negotiation had some issues because you had vendors who couldn’t properly follow specifications. Maybe we should still be using WEP to secure wireless networks because some wireless drivers are not WPA2 compliant!!! fricken moronic logic….

By: gyrfalcon

gyrfalcon — Sat, 16 Jul 2011 11:07:00 +0000

“I have come across too many interfaces stuck in a half-100/full-10
state ….You are living in a theoretical world where you think
things work the way they should. This doesn’t happen in the real world
and I don’t want to be called up at 3am”

I work at a large telecommunications company and I have a lot of REAL WORLD experience. Manually setting duplex and speed causes far more problems than letting devices auto-negotiate by themselves. You obviously haven’t read all the papers Greg has linked to (especially the one from Sun).

I hope we don’t have to get into it at 3am in the morning when your stupid CPE equipment is UP/DOWN because of a speed/duplex issue.

By: gyrfalcon

gyrfalcon — Sat, 16 Jul 2011 10:51:00 +0000

“My experience for the last 10 years say to statically set it, even for
gig. There’s also fact that with it statically set, no time is wasted on
negotiation.”

I suppose you’re one of those fools who also doesn’t use DHCP because it takes time to lease an address… I wish I could punch you over the Internet.

By: Me

Me — Fri, 15 Jul 2011 17:53:00 +0000

Hi, I totally disagree with Auto-Negotiation (except 1Gigabit). In an optimal world the drivers are well developed, and write down in event logs problems in negotiation. This DOES NOT HAPPEN(Linux, Windows and Unix). If I have auto on both ends sometimes (due to cable/switch problems etc) the duplex is re-negotiated and speed is lowered. Apparently for server Admins/DBA’s everything is ok (but performance is lower in querys etc) the debug takes longer, more time to understand a duplex prob is needed. So in my organization the best practice is to force in both ends (except speed). Every server as Teaming, so in case of failure in one eth it switches to the other.

By: Matt Buford

Matt Buford — Wed, 08 Jun 2011 11:16:58 +0000

In 15 years of network engineering at ISPs and datacenter environments, I’ve seen exactly ONE case of autonegotiation failing. I’ve seen hundreds of cases of duplex mismatches due to one side being forced.

Back in 1998 or so, I had a Cisco 7000 router and 6500 switches. I can’t remember the line card models any more, but I tested with multiple 100M ports on the router and multiple ports on multiple 6500 switches, and autoneg always failed (leaving full on one side and half on the other). This is the only case I have ever seen of this.

The 2 biggest problems with forcing it are a) people think they can force it on one side, and b) cables get moved. Remember, the leading cause of network issues is operator error. Disabling autoneg means you rely on the operators.

I have a script that emails me on late collisions seen on my access switches facing thousands of servers. In 100% of cases, this is caused by sysadmin error of thinking that they can force it because they “heard it was the best practice”. They typically have no idea that forcing only one side GUARANTEES problems. When I see late collisions, I just open a ticket and say the server is incorrectly configured, and when they change it back to autoneg it works perfectly every time.

I won’t allow anyone on our network to disable autoneg unless they can clearly show me that it is failing (via duplex status/errors from both sides). Cases of people claiming to have actually found issues never include errors/duplex status. It’s always an anecdotal “my web site was slow so I forced duplex and now it seems faster”.

By: kirkdavis.co.uk » Blog Archive » To auto-negotiate or not?

kirkdavis.co.uk » Blog Archive » To auto-negotiate or not? — Thu, 02 Jun 2011 20:28:06 +0000

[...] research and found the following interesting articles which seemed to back up what he was saying: http://etherealmind.com/ethernet-autonegotiation-works-why-how-standard-should-be-set/ [...]

By: Peter Joseph

Peter Joseph — Thu, 10 Mar 2011 18:04:03 +0000

I keep challenging the “old hands” at my organization to actually show me some kit that doesn’t auto-negotiate properly. They never can show me any hardware, but they can always provide plenty of stories of “the old days” when some piece of hardware didn’t negotiate properly. This is my 10th year in networking full time and I’m yet to see a problem CAUSED by auto-neg. I see many more problems caused by hard setting ports.

By: Autonegotiation ó Pattincon Blog

Autonegotiation ó Pattincon Blog — Tue, 01 Feb 2011 20:41:37 +0000

By: Rob

Rob — Fri, 17 Dec 2010 12:01:29 +0000

I have worked in a number of large organisations and for the last 7/8 years I have challenged the server/workstation teams to switch all their connectivity to auto-neg across the board. I have promised a serious night out for anyone that hits an autoneg problem and have not (yet) had to back up this promise. In fact we have come across Solaris and HP bugs in that time where hard-coded FDX interfaces have failed back to half duplex after a link-loss event (switch reboot etc).

Autoneg just works, and should I ever come across an issue, I would raise this with the manufacturer, not cover it up by kludging the config.

An excellent article and good to know others are attempting to put an end to what is 99% mythology

By: Guillaume Filion

Guillaume Filion — Tue, 23 Nov 2010 16:45:11 +0000

Thanks for the clarification. At first I thought that all devices (routers & switches) needed to have auto neg deactivated.

I finally only disabled auto neg for the two polycom devices and the rest of the network is set to auto.

By: Greg Ferro

Greg Ferro — Mon, 22 Nov 2010 11:25:45 +0000

Yes, I’ve heard this from other people. It’s seems the Polycom ethernet chips are not fully standards compliant and cannot negotiate correctly.

Thats would be a Polycom fault, not a failure of the ethernet autoneg process.

Not also that one, very limited number of edge devices, does not disprove the fact the autoneg should be the default choice.

By: Guillaume Filion

Guillaume Filion — Wed, 17 Nov 2010 20:57:38 +0000

We’re using videoconferencing hardware from polycom (H.323) and we sometimes get dropped frames. A network admin from another institution told me that forcing the speed and duplex to 100 FD solved this problem for him. I started forcing 100 FD on the polycom, then the switch, then my router, then I realized that my ISP uses auto negotiation…

Anyone else heard about auto negotiation leading to dropped frames with H.323?

By: Ethernet Over Copper

Ethernet Over Copper — Tue, 26 Oct 2010 20:03:01 +0000

I totally agree that this should be mandatory.

By: ESXi 4.1 pNics Hard Coded to 1000 Full | 2vcps and a Truck

ESXi 4.1 pNics Hard Coded to 1000 Full | 2vcps and a Truck — Sat, 02 Oct 2010 16:49:00 +0000

[...] wise Cisco engineer many years ago that GigE and Auto/Auto is the way to go. You can also check the Internet for articles and best practices around using auto-configure with gigabit ethernet. Even the VMware “Health [...]

By: Show 20 ñ Impromptu Crowdsourcing – Gestalt IT

Show 20 ñ Impromptu Crowdsourcing – Gestalt IT — Tue, 14 Sep 2010 16:03:05 +0000

[...] who dare to manually set speed and duplex in anything other than the most dire of circumstances. †Greg had explained himself on this point in a blog post earlier this [...]