So thats human error not a problem with using forced settings, eliminate

In the real world, auto-negotiation on fiber vs. auto-negotiation on copper have been two different animals. Most of the compatibility issues result from 10/100 auto-negotiation on copper as this was the first major deployment of the technique in Ethernet devices. Most devices engineered recently should auto-negotiate properly. In the early to mid 90's this was only true within the product line of a single vendor. Many of the products Cisco sells were engineered by different companies and often have problems auto-negotiating to other "Cisco gear" made by other companies. Also remember that many of the products that Cisco still sells have roots back 5 or more years. There is a good chance that any 3600 copper interface could have the same issues that its cousins did in 1997. The question of hard-setting speed/duplex on these types of interfaces is about as murky an issue as spanning-tree. You solve some problems and create others. I suppose the primary goal is to eliminate support calls and outages within your own environment. In my experience, connections which as static (servers, routers, etc...) should be hard coded on both sides as incorrect negotiations can and do occur. It is also frustrating to discover that your primary file server has been running at half duplex for a week. It may also be interesting to know that IEEE 802.3-2002 says that auto-negotiation is optional (in section 28.1.2.) It may also be interesting to know that if a device does support auto negotiation it must allow manually overriding of the function (IE.. an unconfigurable device is not allowed to auto-negotiate.) -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] Sent: Wednesday, January 08, 2003 2:39 AM To: nanog@merit.edu Subject: RE: Weird networking issue. On Wed, 8 Jan 2003, Stephen J. Wilcox wrote: the

human error and I think you'll see forced always works, autoneg sometimes works. (For future reference dont employ incompetent people to run your networks folks!)

Problem with autoneg is that you always have to have manageble equipment and you always have to check both ends after changing anything. In an ISP environment that is generally not a problem luckily, apart from the equipment you connect to on the customer side, some customers insist on using cheapo stuff. Autoneg does add good things, especially on GigE. Autoneg on a GigE yields the most desireable effect of "link loss return", ie if you lose fiber link one way the link goes down at both ends.

Have you looked at what autoneg is.. its horrible, a hack to help out the above incompetent engineers who dont know how to force duplex.

Hmm, I might draw the same conclusion regarding automatic gear boxes on cars but I think I should not considering the situation in the US regarding that perticular issue :) Personally I think the idea with autoneg is really a good thing, why shouldnt two units advertise their capabilities and then act accordingly to what they both can do? We do the same on SMTP (EHLO) and so on. -- Mikael Abrahamsson email: swmike@swm.pp.se