You are here: Home / Blessay / Blessay: Autonegotiation on Ethernet – it works, it should be mandatory!

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

12th March 2010 by 79 Comments

I found this quote recently:

“The switch is configured to autodetect the speed and duplex settings on an interface. However, there are several things that can cause the autonegotiation process to fail, resulting in either speed or duplex mismatches (and performance issues). The rule of thumb for key infrastructure is to manually hard-code the speed and duplex on each interface so there is no chance for error. “


THIS IS VERY VERY VERY WRONG

Let me say it again: This is mythinformation.

Cisco(1), Sun(2), Dell(3) and all major manufacturers RECOMMEND auto-negotiation.

How did the myth get started ?

Once upon a time ( or at least, around 1996/7 ) , there was no Ethernet autonegotiation standard, but everyone agreed this would be a good idea. At that time, Intel and 3Com were the biggest manufacturers of network adapters, and Cisco / 3Com / Nortel were the main switch vendors. So 3Com implemented their version and 3Com adapters worked on 3Com switches. Intel came up with their version and Intel adapters worked with Cisco switches. Nortel switches didn’t really work with anyone consistently. And the OEM equipment didn’t do much at all, it was hard setting or nothing.

This was a massive problem. In fact, I remember entire corporate networks had their network adapters swapped out of every computer. No-one really knew which adapters and switches could interoperate, and inter-switch connections were a real concern.

So we all just concluded that hard setting Ethernet speed and duplex was the best option.

Then the 802.3u standard was ratified in 1998 and new equipment from all the vendors started to come into the market after that time that was compliant with 802.3u and things got better. But we still had a lot of that older equipment around, and those network adapters were quite expensive back then.

So we all became used to hard setting Ethernet speed and duplex as the best option. But all of that problematic hardware should be gone by now, and we can consider changing the way we work.

Why doesn’t everyone know ?

I suspect that this is one of the basic topics that no one ever researches. Everyone just “knows” that you always hard set duplex and speed. These days it is pretty much a mantra, especially among telco operations and some server teams.

Because we all “know” it seems nobody has taken the time to fix it.

And because many people configure this by default, it forces everyone else to do the same.

Whats the problem ?

A major problem is that many people are also hard setting Gigabit Ethernet , and this is causing major problems. Gigabit Ethernet must have auto-negotation ENABLED to allow negotiation of master / slave PHY relationshitwhp for clocking at the physical layer. Without negotiation the line clock will not establish correctly and physical layers problems can result.

From Sun’s Best Practices on Ethernet Auto-negotiation (2):

Disabling autonegotiation can result in physical links issues going undetected. The Fast Link Pule process does some testing for the physical link properties as well as negotiation on several Ethernet properties.

  • Unable to detect bad cables
  • Unable to detect link failures
  • Unable to check link partners capabilities
  • Unable to move systems from one port to another or to another switch or router
  • Unable to determine performance issues on higher layer applications
  • Unable to implement Pause Frames (Flow Control)(4)

From the IEEE standard:

All 1000BASE-T PHYs shall provide support for Auto-Negotiation
(Clause 28) and shall be capable of operating as MASTER or SLAVE.
Auto-Negotiation is performed as part of the initial set-up of the link, and
allows the PHYs at each end to advertise their capabilities (speed, PHY
type, half or full duplex) and to automatically select the operating mode
for communication on the link. Auto-negotiation signaling is used for the
following two primary purposes for 1000BASE-T:

a) To negotiate that the PHY is capable of supporting 1000BASE-T half
duplex or full duplex transmission.

b) To determine the MASTER-SLAVE relationship between the PHYs at
each end of the link. 1000BASE-T MASTER PHY is clocked from a local source.
The SLAVE PHY uses loop timing where the clock is recovered from the received data stream. My emphasis

Future Considerations

There are new standards for 10 Gigabit but the new Converged Enhanced Ethernet (CEE) (Cisco is developed a superset called Data Centre Ethernet(c)) will require each side of GigE connection to negotiate capabilities relating to pause, capabilities, queues and a number of other critical features.

If you haven’t already, you should consider changing your standards to use auto-negotiation everywhere because it is a prerequisite in the new technology.

I make an especial plea to Service Providers to change their standard practice to using Autonegotiation on Ethernet. We have to move with times and mode

Operational Benefits

But most of all, setup auto-negotiation so I don’t have to think about configuring ports for each server. I am going nuts here with my staff having to manually configure every fricking port whenever a server moves around. It a ridiculous waste of resources.

Plus it makes you more successful, since hard setting means that more mistakes will be made.

Comments invited, I would love to discuss this more. Tell all your friends!

Reference

(1)Cisco recommends to leave auto-negotiation on for those devices compliant with 802.3u.This would be every device since 1999 or so.

(2) – Sun Ethernet Autonegotiation Best Practices

Wikipedia The debatable portions of the autonegotiation specifications were eliminated by the 1998 release of 802.3. This was later followed by the release of IEEE 802.3ab in 1999. The new standard specified that gigabit Ethernet over copper wiring requires autonegotiation. Currently, all network equipment manufacturersóincluding Cisco[1]órecommend to use autonegotiation on all access ports. On rare occasions where autonegotiation may fail [2], it may still be necessary to force settings.

Cisco When configuring an interface speed and duplex mode, note these guidelines:

ïIf both ends of the line support autonegotiation, we highly recommend the default setting of auto negotiation.

(3) Dell – Gigabit Ethernet Auto-Negotiation

(4) Peter Lapukhov of Internetwork Expert posted a good article about why 802.3X pause frame should be disabled here

Filed Under: Blessay, Blog, Design Tagged With: ,
About Greg Ferro

Greg Ferro is a Network Engineer/Architect, mostly focussed on Data Centre, Security Infrastructure, and recently Virtualization. He has over 20 years in IT, in wide range of employers working as a freelance consultant including Finance, Service Providers and Online Companies. He is CCIE#6920 and has a few ideas about the world, but not enough to really count.

He is a host on the Packet Pushers Podcast, blogger at EtherealMind.com and on Twitter @etherealmind and Google Plus

  • http://aconaway.com Aaron Conaway

    I think age is the big thing with autonegotiate. I’ve seen NICs on servers (usually IBM) with manufacture dates of 2002 fail miserably at autonegotiating (10/half to 100/full makes for a wonderful medium). With the economy dying a horrible death, I’m picturing a lot of old servers getting put back into service or being used for another few years to save a dollar.

    As you said, a 1G NIC needs auto, so time will heal all wounds.

  • http://www.cciepursuit.com cciepursuit

    Great article. I did not know how GigE uses auto-negotiation. Cool information.

    There are 2 reasons that my company still requires hard setting speed and duplex on server ports (user ports are all auto/auto):

    1) $$$. Switches with GigE ports cost more, therefore our port charge for 1000Mbps is higher than the cost for 100Mbps. Nearly all servers now have GigE capable NICs. If we didn’t hard set our ports then the vast majority of our servers would auto-negotiate to GigE. I personally don’t care, but the bean counters do care.

    2) If the auto-negotiation process fails, it will set the duplex to half. This problem is usually caused when one side is hard set and the other is using auto-negotiation. In our case, our billing requirements usually results in this issue. We hard set our port to 100/Full and the server uses auto/auto. Everything looks good until we get the frantic call from the server owner cursing out the network. A quick ‘show interface gx/x counter error’ will usually show collisions. Then we begin the awkward and painful dance of “I know that you don’t have your server NIC set to 100/Full but we’re going to argue about this for an hour until I set my side to auto/auto to prove you wrong.”

    Because of issue 1, we run into a lot of issue 2. It is the bane of my existence that I don’t have access to the NIC settings on servers. It would make a good 20% of my troubleshooting go 90% quicker. I could then quickly check for the big three server problems: incorrect speed/duplex settings, incorrect subnet mask, and incorrect gateway.

    Anyhoo…great article. I agree that auto-negotiation should be used if possible.

    • http://etherealmind.com Greg Ferro

      What are you going to do when the new Gigabit becomes the standard ? CEE and DCE is coming, and will probably filter down from the Cisco Nexus to Catalyst 6500, 4500etc and you will need autoneg then. I can’t see the neg part being optional.

    • ian

      [q]If we didnít hard set our ports then the vast majority of our servers would auto-negotiate to GigE[/q]

      Depending on the equipment you’re using, you can set the maximum speed that’s being advertised in the autonegotiation process. In most, if not all, recent cisco switches you can do this using the following command:

      someswitch(config-if)#speed auto ?
      speed list separated by spaces (up to 8 values total)

      setting ‘speed auto 10 100′ will allow the switchport to negotiate to both 10 and 100 Mbit, but nut 1Gbit.

  • http://last40days.wordpress.com ahenning

    I have to agree with the author, I’ve had issues where switch trunk links (3500-2900) were set both sides to 100/full. Show interface output displays 100/full no errors/collisions, but throughput is exactly 10/half with throughput test. Make both auto/auto and thoughput goes up to 100/full.

  • http://bitacora.nevot.org nevot

    Hi,
    In eleven years administering networks I’ve seen autonegotiation fail again and again. I won’t let my network under auto-negotiation under no circunstances.

    • http://etherealmind.com Greg Ferro

      You might have poor cabling then. If you don’t have quality cabling then autoneg can be a problem. And if you have poor cabling, then autoneg is the least of your problems.

      • Anonymous

        I disagree. All our installations are CAT-6 verified and certified. Try to connect a Nokia Firewall to a cisco 2950 with autoneg and you will soon run into trouble. Problems also detected with Avaya Gateways. If you work also with embedded equipment (such as building alarms, air conditioning controls, etc) connected to your network, you will see also problems.

        My criteria is: access ports for users, autoneg. Access ports for servers and other equipments, forced 100-full. In gigabit networks I run autoneg.

        • http://etherealmind.com Greg Ferro

          No, the problem is the Nokia firewall. They are infamous for being stupendously awful at doing this. A notable exception to the rule.

          You are actually following my recommendation. Use autoneg where you can, and hard set where you must. Embedded equipment typically use really old and cheap chipsets so I would expect them to be a problem.

          I would bet from your description that more than 90% of your ports are auto ?

        • http://www.packetwrangler.com/ Jay Moran

          Exactly. Haven’t finished reading the comments. But after a couple of years of analysis we determined the failures of 802.3u were due to high bit rate transfers. If the port was extremely loaded with 80-90Mbps of traffic for a sustained period of time, one side (host or switch) would decide that they should fall back to 100-Half instead of their originally negotiated 100-Full. Our data center cabling is all Cat-5e or Cat-6 and each run is certified as well.

          This was with various flavors of Foundry switches from the late 90′s to really just a a couple of years ago. We’ve maintained the same standard in the data center for any Fast Ethernet attached host. If Gigabit though it has always been autoneg since after the first few months more than a decade ago when we assisted Foundry and Cisco both in fixing their autoneg code since it often failed for no good reason.

          And yes, for employee/office crap, we’ve always relied on 802.3u and never really had widespread problems.

  • shef

    I saw problems problems with new avaya ip pbx box and new 2960.

    • http://etherealmind.com Greg Ferro

      One problem in how many ports in your network ?

      You need to be careful not to let that overwhelm your perception of the problem. yes ?

  • http://bitacora.nevot.org nevot

    Nokia Firewall, Avaya PBX, toshiba tecra s3… in fact, I only trust in autosensing when same manufacturer equipment is in both ends (and not much trusting because, as you said, cabling is not always as we expect).

    yes 90% of the network is autosensing, because 90% of the network is users. But the point is not how much % is in autosensing. Not quantity, but quality. Just as I pointed: for infrastructure, forced. For end users, autosensing. Having problems on one end point affects only one user. Having problems on one server port or one trunk affects lots of users.

    worst case: i’ve seen problems connecting a PC to a Juniper firewall, just because they both have auto-mdix interfaces. Yeah, I know, it’s not part of this standard, but no link between this devices, with a perfect cable. disconnecting and connecting several times until one of them knows the correct mdix. Just disabling auto-mdix on the pc solved the problem. My poor conception of this being ‘auto’ is based on many problems found again and again. This pain will sure be less and less with time.

    One note: Have you reviewed LLDP? one of its characteristics is having information between switches and end equipment (such as avaya ip phones) about, among other things, speed and duplex configured. LLDP fits media selection not only on phy layer but network layer. I think LLDP its also a must in future for all network equipment. Why did anybody designing LLDP (or CDP, or NDP or any of the variants that converged on LLDP) think about the necessity of advertising media capabilities available and used on a upper protocol if autoneg is so wonderful? Sure (I think) because they have seen people running in trouble again and again.

  • http://blog.nullrouter.com nullrouter

    Good article on autonegotiation

    I absolutely agree with using the inherent autonegotiation on 1000baseT links.

    However, with Cisco optic links, I’ve had to rely on the ‘speed nonegotiate’, which disables the link negotiation, on gig optic ports to get them to come up. I also seem to recall Cisco publishing a bug on optic ports without this command being enabled.

    I work in a carrier IP/MPLS/MAN environment, where we manage connections between our Cisco switches and client equipment of various types. We hard code anything less than 1000baseT, as most clients are running Fast Ethernet ports on their equipment still. I’ve seen autonegotiation fail, and devices come up in half duplex after a power hit at a client site, causing us to get unnecessary packet loss/throughput faults.

    Personally from experience, I would recommend only running autonegotiation on anything less than 1000BaseT, where you have administrative control on both ends of the link.

  • Dan

    Hi

    I don’t agree with this article, mainly because my experience, even recently on hp desktops connected into either 3560 or 3750 switches has been painful when using auto-negotiate on either fast or gig ethernet. Basically either duplex or speed is nearly always incorrectly set. So now I don’t eeven bother relying on auto-negotiate, I just manually set the speed and duplex.

    • Jim

      The acid test – get the same problems booting BSDs/Solaries/Linux kernels?

      -if yes, suspect hardware or physical layer
      -if no, contact Microsoft/HP/whoever for your support

      We’ve never had a auto-neg fail under a non-Microsoft OS on a desktop or workstation machines. Even the so-called “WHQL” drivers give regular trouble with auto-neg, especially to Cisco kit.
      (my angle – as a software-to-OS-to-hardware compatability clearing/proving house, we link up and tear down workstations at the rate of 600+ a day, for around two week cycles, 52 weeks a year, across 3 continents)

  • http://www.blindhog.net Josh Horton

    Greg,

    I recently ran into an issue where this article was a HUGE help. Thanks.

    I had a vendor’s router connected to a customer’s switch. Both were hard coded 100/full but for some reason, the connection was horrible. The strange thing is that only the vendor’s router displayed any errors. Anyways…

    After setting both sides to auto the problem was solved. Had I not read this article, I would have stared at the problem for a month or so saying, ” Well, both sides are hard-coded… I don’t know what to tell you. Your router must be junk … ”

    I guess old habits die hard. Thanks again!

    Josh

  • Pingback: These days, I just hard-code for job security. « Quality of Service

  • http://www.osnms.com zakki a

    Greg,
    Great article. In term of standard, yes auto negotiation the first we have to try. but auto negotiation failure is not a myth. it is true.

  • Scott

    I work at a major vendor of server application software that pretty much requires GigE throughputs, and while I agree with you in theroy, the practical is that it doesn’t work that way in the real world. There are two hardware vendors that make 90% or better of server NICs and only a handful of vendors who make 90% or better of the switches out there. The combinations of several of these simply do not work when set to full Auto on both sides. If there was better enforcement of the IEEE standards, we could all play in your ideal world. But the truth is that many of these vendors in question need serious help. I don’t know how they can get away with charging server NIC prices in NICs that have the same bugs (or worse) than simple desktop NICs.

  • Dmitri

    Flow control on GigE ports on 3550 sucks. It starts sending pause frames *way* before a link starts approaching full capacity. Not sure about other equipment, but the said experience with 3550 did not make me happy (and aware).

  • Dennis

    Why do I want to hard set EVERY 10/100 port in the network?

    1) Last week, Cisco 2950 switch and Cisco 2800 router both powered up after an outage. Cisco did not successfully autonegotiate with Cisco switch. Worked well enough that no one noticed til trading started over that link.

    2) Panasonic Toughbooks, circa 2004/5, and Cisco 4500 10/100 port. Don’t remember the ethernet chipset vendor for the Panasonics offhand. Would not ever, under any circumstances, negotiate properly. We had over 100 of those laptops in our company. PITA!

    As you say, Gig is a different animal, but hard setting speed/duplex is a good practice, learned by many of us in the school of hard knocks.

    m00tpoint

  • Tim

    If only the world was that perfect Greg

    I’ve had LOADS of problems with autoneg.
    I’ve NEVER had a problem where both ends are properly nailed.

    No-brainer IMHO, why take the chance? Especially if you don’t have access to both ends to check that it auto’d correctly _this_ time. (Just ‘cos it got it right last time doesn’t mean that it will again)

    I concede Gig is very different and shouldn’t be tared with the same brush.

    Tim

    Tim

    • http://etherealmind.com Greg Ferro

      I have had all sorts of problems, but ultimately, auto-neg is the best default condition. I move to hard-config when there is a problem. That is my recommendation to everyone.

  • Pushkar Bhatkoti

    good research. The point is if any vendor doesn’t follow the standard it’s not your fault. Your concept still works e.g. leave auto-neg on.

    well written.

    -Pushkar Bhatkoti

  • Pingback: David Sudjiman » Blog Archive » Thou Shalt Use Auto-Negotiation!

  • joe

    I come from the telco world and school of hard knocks. Yes, if the pairing of equipment requires auto, or if we are talking Gigabit ether, then you must auto.

    Denis hits the nail on the head, you have an unplanned reboot, then the sucker goes to some crappy setting, and no one notices until the business day hits. The throughput sucks, and the issue can be transient in nature. Once you figure out auto bit you in the ass one more time, management says “Damn it, turn off auto”. As as management usually has a few more gray hairs, they still remember the bad old days.

    So in the real world, non-gigabit will be explicitly set if you want to keep your job.

    A red herring, some folks will say you can’t manage all the settings with out provisioning errors. That is a gap in your server management process, not a a byproduct of explicit settings. Are your configuration files in /etc set to “auto”? I don’t think so.

  • Pingback: Autonegotiate – The debate continues « Bridging the gap between CCIE RS and SP

  • http://n/a pete bateman

    I would suggest that your experience is all quite recent. In the early days of full duplex Ethernet and Fast-Ethernet interoperability between various manufacturers implementations of the standard was pretty bad. I.E a 3com Nic to 3com switch might be fine. Plug a Nortel router into your switch and it would all go south. I have personally seen this many times. Us old hands got bitten by this so often that we always recommend nailing the port config down on interlinks and servers. i.e. if a desktop coems up wrong its a minor issue, if you server suddenly decides its going to be half-duplex you are in deep whatsits. I have seen this happen. More recently you are right, it generally just works, but don’t tell everyone that its infallable,cos it ain’t.

    • http://etherealmind.com Greg Ferro

      By Crom, you missed the point completely. The first paragraph clearly says it was a problem (when I was a younger engineer) then I say it isn’t a problem any more.

      The most likely cause of the duplex mismatch today is faulty cable. Not a hardware problem with Nortel, 3Com or anyone else. And I explain the negotiation process so that you can understand why.

      Of course, you are smarter than Cisco, Sun, Dell and many other people because you don’t believe or even mention the evidence presented here.

      I don’t have a very high opinion of your company and you are confirming that very concept. Please pay attention and read the article before you criticise.

      • James

        I don’t think that reply required the sarcastic response you gave just because someone disagreed with your opinion. I have come across too many interfaces stuck in a half-100/full-10 state that I always hard code the speed (GigE is an exception). Cisco to Cisco is generally fine, but problems happen with interop between vendors.

        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 in the morning when I am getting packet loss across a link – something I could of avoided by hard coding. Before you ask, I install Cat-6 as standard which has all been verified before being used!

        James

        • gyrfalcon

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

  • http://www.firstdigest.com Calin

    It’s nice to see people getting involved and discussing pro and cons of using either one way or another. I have read your thoughts and I agree that network engineer should push autonegotiation in the network, where it’s possible, but let’s not forget that in many cases “paper talk” and how the things behave in the real environments it’s different.
    I always receive instructions from the server team when adding a new device, to configure the port on xxx speed and full duplex. In some cases I wanted to test what’s going on and I let the ports on auto and did just fine, but sometimes it’s not working at all. It’s true also that I don’t know how new or old is the device at the other end of the cable.
    I agree 99% with this article, just the following phrase give me a dark view of a network: “If you havenít already, you should con≠sider chan≠ging your stand≠ards to use auto-??negotiation every≠where because it is a pre≠requis≠ite in the new technology.” I imagine a new network engineer that goes there and issue a interface range command on all switches and apply auto negotiation without being aware of the problems that might appear. He will be “crucified” for making an interruption on the services due to auto negotiation failure.
    After all, when nothing is working, you can also blame the networking

  • Pingback: Cisco tips: Track down communication issues – Part 1 | FirstDigest

  • realworld

    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.

    • gyrfalcon

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

  • Nick H

    I’m willing to call autonegotiate a myth, not because there aren’t devices out there that won’t autonegotiate, but because it rarely seems to be the cause of problems anymore.

    I worked for a large educational resnet back in the day (as early as 2002), and we never saw autonegotiate problems with the 4000+ diverse devices we dealt with each year.

    It takes two hands and both feet to count all the times I’ve had a vendor want to pin down a port for troubleshooting purposes, but can’t recall a single time autonegotiate was the cause of a problem.

    • Rob

      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

    • Facebook

      I’ve been working in networking since 1989 (ARCNet, Token ring and “thick ethernet” in those days: all coax/twinax based) and when we came to the time that not only ethernet was the “de-facto standard” but you also got “extreme” speeds with fastethernet: yeah – I did see auto-neg erros on a regular basis: but in recent years (let’s say: in this millenium) you won’t see any problems (except the above mentioned EEE issue with Intel 82579 NIC’s): so it is just what you define as “old days” and “recent years”: you see 2002 probably as “old days” – I think of “1995″ as old-days (for ethernet on UTP that is: for networking in general it can be longer ago)

  • Pingback: Gigabit auto negotiation « Chuck's Blog

  • Pingback: Setting VMNics to AutoNegotiate in ESX 4. | It's Just Another Layer

  • Pingback: Show 20 – Impromptu Crowdsourcing ó Packet Pushers

  • Pingback: Packet Pushers – Show 20 – Impromptu Crowdsourcing ñ My Etherealmind

  • Pingback: Show 20 ñ Impromptu Crowdsourcing – Gestalt IT

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

  • http://www.hatterasnetworks.com/default.aspx?pagename=advances Ethernet Over Copper

    I totally agree that this should be mandatory.

  • http://guillaume.filion.org/ Guillaume Filion

    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?

    • http://etherealmind.com Greg Ferro

      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.

      • http://guillaume.filion.org/ Guillaume Filion

        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.

  • Pingback: Autonegotiation ó Pattincon Blog

  • Peter Joseph

    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.

    • doghead

      People who’ve gotten lucky with autonegotiation think it always works. People who’ve been unfortunate enough to see how badly things can go when it fails understand that it doesn’t–at least not often enough to be reliable.

      In production environments, nailing speed and duplex are genuinely best practice.

      Oh, and for all of you that don’t believe this: the last time I saw autonegotiation fail was two weeks ago, on a gigabit link between an ASA 5525-X and a 2948G-GE-TX switch. Turns out it’s due to a bug in the ASA–a brand new one shipped from Cisco in November 2012. Cisco’s suggested workaround? DISABLE AUTONEGOTIATION.

      Look, this is not a myth. It’s a fact. Autonegotiation is wonderful when it works, and as a network administration I genuinely do wish it would work all the time. But it doesn’t, and it can start failing at any time due to changes in vendor code–and that’s why nailing speed and duplex continues to be a best practice.

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

  • Matt Buford

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

  • Me

    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.

    • gyrfalcon

      “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….

      • DX Mage

        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.

        • Facebook

          Seems like a very stupid answer. They are not sabotaging things like this. They sometimes make mistakes (or often: depends how you look at it). The Intel 82579LM had a problem implementing EEE – but they didn’t do that to sabotage things as they only sabotaged themselves.
          People who don’t use auto-neg after,lets say, year 2000 because it gives operational problems should check their cabling.

  • Dasfafgasfa

    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.

    • http://etherealmind.com Etherealmind

      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.

      • Dasfafgasfa

        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.     

  • Pingback: Autonegotiation | V6 Networks

  • Bernard

    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.

  • DX Mage

    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.

  • Nyte_byte

    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.

  • Gowthaamm

    hi

  • Gowthaamm

    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.

    • http://etherealmind.com Etherealmind

      That’s not auto-negotiation. That’s a speed mismatch. 10GB interfaces can’t normally do 100Mbps.

  • Oliverg94

    not tech savy but on xbox media centre it mismatches and i need to change my duplex speed… but my atheros 9285 doesn’t even allow me to… 

  • Skar78

    I dont feel any shame to add  a comment 3 years later.

    Auto Negotiating epic fail between my smart tv and my switch, and my TV is not smart enough to allow me to set it manually

    • http://etherealmind.com Etherealmind

      Most likely a faulty cable or cheap network hardware. Or both. It’s not Ethernet that’s broken, it’s your setup.

  • Andrew Houldcroft

    I have my own standard and it is based on experience.

    If both ends are capable of 1Gbps or more then use auto negotiation at both ends.

    If one or more end is limited to 100 Mbps Full duplex or less then fix both ends at the best combined setting but it must be the same setting and must be fixed at both ends.

    Simple and effective.

  • Guest

    High- can agree more then this… Unless you still have a 10Mbit ethernet using coax or AUI connector your should auto-negotiate. And on the higher speeds (1Gb/10Gb) it can be even mandatory: you can only configure lower speeds fixed but if you want to run your 10Gb switch on 10Gb you need to negotiate the speed
    Only reason to disable it in recent years was when you had a switch capable of supporting EEE (energy efficient ethernet) in combination with some Intel 1G NICs. Due to driver code error in the Intel NIC link was negotiating to 0bps and you had to disable EEE via NIC properties. But if you were using PXE boot for OS deployment via WinPE the link would go down as soon as WinPE came active using the Intel driver and you coudln’t disable EEE under WinPE (not even via registry setting or so). As workaround you had to disable both EEE and AutoNegotiate on the switch. But with NIC driver 14 or higher from Intel it all works fine.

  • Tony Clegg

    In my experience, forcing speed and duplex settings gives a substantial performance boost over the auto negotiation method. I have seen this time and time again over the years.

    The problem, I believe, is that todays network engineers don’t want to take the time to design such a system because it takes administrative overhead to keep up with the right matches of speed and duplex for the appropriate infrastructure design. They are not willing to implement such a system to gain 2 or 3 times the speed in their network. Network engineers have unintentionally lowered the throughput standards in corporate networks by using Auto Negotiation in order to ease the work load of the network engineer and now the new engineers don’t even realize that they can gain that performance boost.

    Most Cisco switches have a default setting of 100/Half and if the desktop, laptop, or server NIC is using Auto, then you get 100/half, which is auto negotiated at the desktop, laptop, or server NIC on both sides (reducing speed even further!).

    Please understand, I am not talking about Auto Negotiation errors here. I’m talking about the poor performance of Auto Negotiation without any errors.

    All network engineers who believe in the Auto Negotiation method need to do a performance based speed test of a few Gigabytes to determine how much time it takes data to flow from one host (through your network) to another host using Auto Negotiation on all hosts and switches and then do the same test using forced speed and duplex on all hosts and switches. You’ll see for yourself how you’ve been neglecting your users of their much needed performance boost.

    Just try running your backup during the day with this “Auto Negotiation” setting. Your network will slow to a crawl.

    Please everyone, run some performance based tests and then post those results.

    • http://etherealmind.com Etherealmind

      Tony

      You would be completely and utterly wrong. Nothing in your comments is correct and how you can possibly make statements like that is beyond my comprehension.

      I’d say that your experience is completely off case and misguided. Read the material I’ve provided and see if you can understand why you wrong.

      greg

  • Michael James

    Autonegotiation is failing between VMware ESXi hosts and Cisco 5596 switches, using HP BL460c G7 blades with 10GbE CNAs and Fabric Extender modules. When one or the other bounces, the nics on the ESXi host don’t always come back up correctly. That being said, if you go to the comand line on the ESXi Host and do a esxcfg-nics -a vmnic0 then it renegotiates and comes up just fine. But that has to be done separately from the standard autonegotiation on boot up or reconnect. So does it work or not? I say not so much.

    • http://etherealmind.com Etherealmind

      Check your cables aren’t faulty. Then raise a case with the vendors. There is no auto-neg in 10GBase that I know of so it’s probably a bug or faulty hardware.

  • doghead

    I just ran into an autonegotiation problem on a brand new, just-shipped-from-Cisco ASA 5525-X as of November 2012. This was due to the following Cisco bug

    —————————————————
    CSCua22249

    Bug Details
    ASA5500-X – Auto negotiate may result in 100 full

    Symptom:
    Auto-negotiation on a Gig interface of ASA5500-X results in Full/100M, even when it’s connected to a Giga port and set to auto on both sides.

    Conditions:
    - This only occurs on ASA5500-X models, not on old ASA5500 models.
    -This only occurs for the first auto-negotiation on a port after the ASA5500-X boots up. After that, when the port is “shutdown/no shutdown”, the issue won’t happen again.

    Workaround:
    Explicitly configure duplex/speed on the port
    —————————————————

    And this autonegotiation bug wasn’t fixed until ASA version 8.6.1(5), whose release notes peg it at 09/18/2012. And Cisco circumscribed the problem too much–it affects not just ASAs talking to each other but ASAs talking to other devices as well, as I discovered for myself when an ASA 5525-X negotiated incorrectly with a 2948G-GE-TX switch.

    Look, I get that some of you have been lucky in dealing with devices that didn’t fail to autonegotiate correctly (or, more likely, you just didn’t notice when they did fail). Nonetheless, this is not a “myth”–it’s a fact. Autonegotiation does fail, and when it fails it’s catastrophic (despite supposedly negotiating a 100/full connection, the ASA unit in question had a packet loss rate of around 40%). It’s better now than it used to be ten years ago, but it still fails. And it can *start* failing weeks, months or years after you’ve convinced yourself it won’t fail, thanks to bugs like the one above (not a legacy bug in this case, but one introduced into recent code).
    If you want to rely on autonegotiation and hope you won’t get bitten by bugs like this, fine, that’s your choice–but don’t act as though it’s a “myth” that autonegotiation fails. There are very good reasons for turning autonegotiation off in production environments.

    • http://etherealmind.com Greg Ferro

      So one, single, once-in-five-years event means that you will cripple the entire company to manual configuration ? You must really hate yourself to spend your entire life configuring Ethernet ports.

      I’ve got better things to do than configure Ethernet ports, I’m working on the next generation of technology.

      Man up. Get over it. A faulty product from a vendor is a faulty product, not a failing of the technology.