Wondering if any of you folks experienced performance problems with auto-negotiation? Does auto-negotiation ALWAYS work, reliably? Are there cases when even though the link pairs are capable of high link speeds(e.g., 100 Mbps, Full duplex), the link is established at a lower speed (e.g., 10 Mbps)?
I have seen inconsistent results in my tests, with the same dataset. By locking down the NICs, and switch ports to 100 Mbps Full Duplex, I was able to get consistent(and good) performance results. Are there any downsides to doing this ?
1. are there any (free)tools to monitor the various link-speeds in any given link-pair?
2. are you aware of any serious downsides to disabling auto-negotiation, and locking down ports/NICs to 100 Mbps, Full Duplex ?
3. does broadcast/multicast vs. point-to-point traffic affect auto-negotiation in any way?
I'm not sure if I can answer all of your specific questions but I can sum it up for you...
Even Cisco strongly recommends against autonegotiation. If you look through all of the postings on this site, the most common theme is problems with that very feature. Never use it. Even two Cisco boxes together often come up with bad results between one another. Always set speed and duplex manually.
Secondly, I firmly beleive there is a benefit to auto-negotiation, and I use it wherever I can. As opposed to years past, autoneg is getting better. The newer products have a much easier time with it than the older products do. I've fixed alot of NIC problems by updating NIC drivers, and on larger systems (UNIX, Mainframe, etc), an Operating System upgrade made a big difference several times.
For what it's worth: My guidelines for using auto-negotiation are:
-On links between network equipment (switches, routers, hubs, etc), always fix the speed and duplex to desired setting. You don't want the interfaces to kick down to a lower speed without you knowing about it.
-On links with servers, try autoneg first. If it gives any problems, fix it to highest speed/duplex you can. Really try hard to get to 100/full.
-On links with common workstations (office areas, etc), try to use autonegotiation wherever possible. The reason I say this is that the PCs move around alot, and it stinks to have to be bugged by a deskside support technician or the help desk any time a workstation moves, or when a PC is upgraded.
-Document the port change with the date, who it was for and who made the change, especially with the common workstations. I put this in the SET PORT NAME field or DESCRIPTION field, so I can recall why I set the port.
My last piece of advice is to look at the SHOW PORT statistics to see if the port is happy where it's at. If the NIC doesn't like autonegotiation, you'll see CRC and FCS errors pop up pretty quickly, especially once you run a bit of traffic across the link. Just simply launching the browser and letting a busy page load (like MSN, CNN or ESPN) will be enough.
I've heard people bash autonegotiation alot. I admit, I hold it suspect pretty easily, but I find that it works for most of the common end workstations/servers here. We've got alot of different NICs, a mix PCs from 386's to Pentium 4's, Unix, Windows, VAX/Alpha, etc. Out of all my switched ports, probably 10% of them are *not* set to autoneg. Even then, nearly all of those are in the computer rooms.
I do agree that autonegotiation is the thing to be used preferably those days. But the problem we came along is that a fixed 100 Mb full duplex at both sides does not always work. Putting it to autnoegotiate works most of the time. This problem has been seen with different ethernet cards and even between switches. So, the question is if this is an issue with the CISCO itself? Has anyone else seen this problem: fisxed 100mb full duplex giving a lot of errors which are solved if autonegotiation is used?
I have experienced many of the same problems everyone else has listed here with PC's. Without setting the NIC to 100 full they do not reach their full potential. There is ONE exception to this story. While using a Macintosh I had to leave the switch set to auto to get the Mac and switch to negotiate to 100 full. If I forced the switch to 100 full, the Mac would only pass about 30KB/s where as when both are set to auto I can get it to pass over 8MB/s.
There were a couple comments earlier about Cisco themselves recommending to *not* using autonegotiation. Look at this snippet from their document entitled: Troubleshooting Cisco Catalyst Switches to Network Interface Card (NIC) Compatibility Issues
Recommended Port Configuration (Auto-Negotiation or Manual Configuration)
There are many opinions on the subject of auto-negotiation. Previously, many engineers were advising customers not to use auto-negotiation with any switch connected device. However, improvements in the interoperation of auto-negotiation and the maturity of the technology has recently changed the view of using auto-negotiation. In addition, performance issues due to duplex mismatches as a result of manually setting speed and duplex only on one link partner, have become more common. Due to these recent issues, using auto-negotiation is regarded as a valid practice.
The one exception I still know about is that they strongly recommend *not* using autonegotiation on the PIX Firewall, even if it is working properly. This agrees with my guideline above to not use autoneg between network devices themselves.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...