|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: Weird networking issue.
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:[email protected]] Sent: Wednesday, January 08, 2003 2:39 AM To: [email protected] Subject: RE: Weird networking issue. On Wed, 8 Jan 2003, Stephen J. Wilcox wrote: > So thats human error not a problem with using forced settings, eliminate 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: [email protected]
|