ethernet auto-negotiation

christianpho · ‎03-31-2008

Hi,

we have a network using principally Cisco network device (Switchs and routers).

Currently all duplex setting and speed setting is set administratively on each device at both end. All servers connections have also there speed and duplex settings at both end.

Now we have someone in our team want to change all setting for auto-negotiation for everything (servers, routers and switches), his arguments it's more easy to manage and sometime auto-negotiation can help us to diagnostic some network problems or cabling problems.

On my knowledge, and it is what I had recently read in my CCNP certification guide, it is always a good practice to administratively set duplex and speed for network devices like switches and router and also for connection for servers to make sure all of them are always connect at the speed and duplex setting we want for thoses connections.

Which one of these practice is better to use, considering everything and why ?

Thanks a lot !

Richard Burts · ‎03-31-2008

Christian

In my experience it is much more important to be consistent about what you do with speed and duplex and less important which way you set it.

In some times past, when the technology was not as stable and negotiation was not always reliable there were people who advised that you should hard code the speed and duplex. The certification guide may advise that (and certification guides frequently lag behind real world experience). In my experience with more modern networks many people prefer to set the interfaces to negotiate.

I do not believe that there is a "right" answer to the question about whether you should hard code speed and duplex or should choose negotiation. But which ever you choose you should be very consistent about implementing it.

HTH

Rick

HTH

Rick

lamav · ‎03-31-2008

Christopher:

It's true that you should be consistent.

But it does, in fact, matter how you set it.

Different vendors sometimes add their own proprietary features to the auto-negotiation protocol and that can cause synchronization problems. Sun microsystems is notorious for that.

Personally, I like to hard code.

Attached is a reference table of Cisco recommendations for speed and duplex settings in different scenarios. Take a look at it.

HTH

Joseph W. Doherty · ‎04-01-2008

"Which one of these practice is better to use, considering everything and why ?"

The most significant difference between them, with manual configuration you avoid issues of the hardware not working correctly, with this being offset by the fact you now must (manually?) maintain additional configurations.

With current gen equipment, I usually see more errors due to manual configurations vs. auto. The former especially during a rush failure recovery scenario, e.g. something as simple as repatching because a device failed.

On the Cisco site, the latest "best practice" recommendations appear to now endorse auto, reserving manual configuration for problem cases.

What's best for you is dependent on your environment, what actually works with the least amount of overhead. In your case, if auto is actually better in your environment, you should also consider the cost of making the change. Additionally, if you chose to leave the current implementation alone because of cost to migrate, but choose to start using auto for new configurations, you also need to consider the impact of having to maintain two different approaches.

lamav · ‎04-01-2008

"On the Cisco site, the latest "best practice" recommendations appear to now endorse auto, reserving manual configuration for problem cases."

Not quite accurate. Cisco has always "endorsed" autonegotiation and their switches have supported the 803.3u spec for years.

The problem Cisco brings to light -- and they're right -- are the inconsistencies with some venfor implementations of 802.3u.

From the Cisco website:

Recommendation

Whether to configure autonegotiation on 10/100 links or to hard code speed and duplex ultimately depends on the type of link partner or end device you have connected to a Catalyst switch port. Autonegotiation between end devices and Catalyst switches generally works well, and Catalyst switches are compliant with the IEEE 802.3u specification. However, problems can result when NIC or vendor switches do not conform exactly. Hardware incompatibility and other issues can also exist as a result of vendor-specific advanced features, such as auto-polarity or cabling integrity, that are not described in the IEEE 802.3u specification for 10/100 Mbps autonegotiation.

Anticipate that there will be some situations that require host, port speed, and duplex to be set. In general, follow these basic troubleshooting steps:

Make sure that either autonegotiation is configured on both sides of the link or hard coding is configured on both sides.

Check the CatOS release notes for common caveats.

Verify the version of NIC driver or operating system you are running, as the latest driver or patch is often required.

Victor

Joseph W. Doherty · ‎04-01-2008

"Not quite accurate. Cisco has always "endorsed" autonegotiation and their switches have supported the 803.3u spec for years."

Well yes, if the 803.3u spec was supported. However, I recall a lot of issues with older Cisco switches (or routers) that had pure 10 Mbps ports and other devices with 10/100. The autonegotiation, I believe, was a feature of the newer 100 Mbps, but many user NICs would support auto at 10, when Cisco 10 Mbps either didn't support 10 full or 10 auto.

Consider from http://www.cisco.com/en/US/tech/tk389/tk214/technologies_tech_note09186a0080094781.shtml#when

When to Use Ethernet 10/100 Mb Auto-Negotiation

Auto-negotiation is an optional function of the IEEE 802.3u Fast Ethernet standard that enables devices to automatically exchange information over a link about speed and duplex abilities.

.

Cisco recommends to leave auto-negotiation on for those devices compliant with 802.3u."

A common issue was not having both sides of the link support 802.3u. I recall host 10/100 NICs, if left in auto, would even error disable some of the earlier 10 Mbps ports on Cisco 5x00s.

These fastEthernet equipment transition issues, I believe led to the often seen manual configuration of port settings.

lamav · ‎04-01-2008

Joseph:

Where the heck have you been???

I posted some questions on here and you totally dissed me...I was waiting for you to chime in with some help.,..

what was up with that??

Joseph W. Doherty · ‎04-01-2008

Victor,

If they are the questions you posted I recall reading, quite simple, didn't have a good answer for them.

When it comes to being "dissed", in your second post for "LAN, Switching and Routing: SLB Help Needed", I fell under "Anyone?", ouch! ;)

jimmyc_2 · ‎04-01-2008

At our shop we are exclusively Cisco and Windows, and we still have to hard set some interfaces. We found that consistency didn't matter as much as keeping the users happy. If what you have works, let it rest. Don't expend energy to standardize, since you'll find more issues than you already have. We learned this lesson the hard way. regards,

andrew.butterworth · ‎04-01-2008

I have hit issues in the past where the performance is worse if the ports are hard-coded. This seems to have been down to NIC driver implementations - i.e. the driver was hard-coded however the NIC itself was overiding driver settings and auto-negotiating. This issue was almost impossible to diagnose as the vendors NIC software applet reported 100Mbps & Full Duplex, however physically the NIC was operating at 100/Half due to negotiation being disabled on the switch.

I have also seen hardware (recently) where the NIC speed & duplex is not manually configurable so it must be Auto; hard-coding just isn't an option (Nortel CS1000....).

In my experience I would leave devices at Auto - maybe 5-or more years ago I would have hard-coded things but not now. Even router to switch links I would leave at Auto as I have seen more issues with hard-coding speed & duplex than I have with leaving them to negotiate.

Andy

Danilo Dy · ‎04-01-2008

Hi,

In the past, if I can remember I think it was during the introduction of 10/100Mbps NIC, there's a problem setting the interface to autonegotiate. I found that although most vendor support autonegotiation, there was no standard for autonegotiation. There were cases that devices from the same vendor autonegotiate setting fails after sometime. This is why most people in the past hardcode the interface speed and duplex for performance and to minimize administration overhead because most of the network failure is cause of autonegotiation. Well, I'm one of them and still use this practice as of today (at least for 10Mbps and 100Mbps) for static devices (i.e. between network, server, security devices).

With the introduction of 1000Mbps, it is adviceable to set the NIC to autonegotiation. This is because "The IEEE Gigabit Ethernet Specification does not allow hard-setting a NIC at 1000Mbps. The NIC speed will be auto-negotiated". This is true for some vendor, i.e. HP Unix, Packeteer. Also, although most of Cisco devices GE interfaces can be hardcoded, there are some excemption like WS-C2960G-48TC-L 4GE Interfaces, it cannot be hardcoded.

whether you use autonegotate or hardcoding, it all depends to your cabling. To avoid problem, make sure you have the correct type of cable and better quality. This makes the difference between performance and network failure.

Regards,

Dandy

craig.lassen · ‎08-31-2010

I also fall in the camp that auto-negotiation is now a much better choice especially since we can all count on a reliable implementation of auto-negotiation in almost all devices and drivers. Here is why:

I have seen many times during the past 20 years the situation when a device is hard-set (usually because of standardize practices within an organization) and accidently gets plugged into a switch that for one reason or another is set for auto-negotiation. This happens most often when a small portable switch, that is not configurable, and therefore always internally set to use auto-negotiation (millions of them out there) is accidently installed somewhere in the network, usually for a temporary reason and is then forgotten. It also happens when someone who is not adequately trained or is under extreme time pressure does not set all the ports of a configurable-switch to full-duplex when the switch is first installed (most switches come defaulted as auto-negotiation) and later someone uses one of the remaining unconfigured ports for something else.

Whenever a device is hard set for full-duplex and is plugged into a switch that is set for auto-negotiation (this includes all non-configurable switches) the switch will drop to half-duplex because it never receives any negotiation information back from the attached device. This causes very serious throughput issues and often leads to a logarithmic increased in collisions as the bandwidth through the device increases. The unfortunate part is that in many cases there is little or no logging or alerting information to help identify the problem when the switch is in half-duplex mode and the device is still in full-duplex mode. The best way to tell is to use the “show interface” command and see if there are any input or output errors, but often the only evidence is horrible performance and significant dropped icmp and udp especially during high transmission throughput.

As has already been mentioned in this thread, it is often not possible to insist that all third party vendors configure their equipment the way you would like for your organization. This is because those organizations (often bigger) already have requirements in place to hard configure their equipment because historically it was better to hard set when auto-negotiation was still unreliable. This, of course, opens up the door to having multiple different port configurations on your switches. In the end, it is just not possible (especially in larger organizations) to standardize all switch ports. Bottom line - no matter what you do, document, document, document!!!