RE: Weird networking issue.

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


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

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 <>" made the following
annotations on 01/07/03 15:33:08