I think we all agree that autonegotiation is evil, and should be avoided whenever possible. When you are looking for the root cause of the errors on
I don't agree. I have seen more problems generated by incompetence in trying to fix duplex/speed, than I have seen problems generated by autoneg not working properly.
I am always amazed by the fact that very few people out there know that you have to lock duplex at BOTH ENDS of any given link for it to work properly.
Generally, in a LAN environment with good quality switches and good network cards, autoneg works just fine. Yes, with 10/100 meg fiber/converters converters you should definately lock duplex, but in most other cases I recommend to leave the duplex setting to auto.
I agree that with quality switches and network cards (ones supported by the manufacturer of the switch), you should be OK using autonegotiate in a desktop environment, but not in a sever environment or when interconnecting networking equipment. I've seen servers that initially autonegotiate fine, only to renegotiate later to a different speed or duplex setting; and in a production environment, that ends up costing money. The problems between Cisco and SUN have already been addressed in this thread. I have also seem problems between Cisco and Bay equipment. The bottom line is that if you need to take the guess work out of a connection, then lock up both ends.
Yes, cisco routers are notoriously bad at doing autoneg, but I blame that on cisco and not on autoneg. The el cheapo $50 desktop switches seem to hack autoneg just fine.
I think that this stems from the folks at Cisco believing that they can dictate the standard for the IEEE 802.3u autonegotiation protocol (aka, their faith that isl will become the trunking standard of the future). "MMS <firstam.com>" made the following annotations on 01/07/03 15:33:08 ------------------------------------------------------------------------------ "THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION. IF YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM." ==============================================================================
participants (1)
-
Braun, Mike